• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root is Drakaz giving up?

"drakaz
Samsung use fu** way communicate with baseband. Galaxy will never eat a donut with me. Samsung, please provide an update to donut !"
wrote that in twitter about a minute ago :( Iwas about buy my galaxy 2-3 days. if he drops who is gonna bake us Donut :(

hes trying but is having problems due to the naff way in which samsung write their code
he said this pretty much last week on a thread here

its pretty difficult and may not be possible untill samsung make it themselves (unless they cant)
 
Upvote 0
thedeli,
in all earnesty: Are you basing your purchase on whether or not this one person will 'go away' or not?
If so, then you should definitely not buy the phone.

Just sayin'. :eek:

What you should do, if you have already made the purchase, is what the rest of us do: hope like h*ll that Samsung will get their act together. To be fair, the last K4 release turned out to be not all bad, so far. :rolleyes:
 
Upvote 0
in turkiye we buy our phones from dealers :) not from operators. so I did not buy it yet but I was hoping that Drakaz will cook donut if samsung doesn't. if ı buy galaxy and samsung won't give us donut or eclair galaxy will be just a phone to me. because I was wanting android for its updates like iPhone. it won't be like Winmo. I'm not sure yet but I want a updatable pda :)
 
Upvote 0
I'm hoping that the Galaxy being sold by O2 and Bell Canada (just launched 3 days ago) will be the thing that makes Samsung support the phone with updates. They will certainly sell enough phones to justify it now.

The phone is $99 at Bell Canada with a 3-year contract. I don't think the average smartphone user will be happy if they are stuck with 1.5 three long years from now.
 
Upvote 0
To clarify.... (for the short answer just read the bold part!)

Porting other versions of android (1.6, 2.0 etc) requires alot of work. This boils down to the following, and if just one thing can't be done you cant port it..

- Port kernel, and memory mapping (doable)
- Port drivers (dificult, but doable. For any devie drivers that we can't fix we can search for other phones which run 1.6 or 2.0, and use the same hardware, AND post their source. It just means we may be slightly behind other menufacturers, but not that much. Eg hero source will be of great help. Anyway mostly doable, worst case one or two things may not work, eg bluetooth or wifi.

- Find a rild that works (PROBLEM!)

So whats rild?

_most_ (all other?) android phones use standard AT commands over a com port to the modem (the GSM/UMTS phone part). Similar to how every modem you buy for your computer recognises the exact same AT commands no matter which model/brand you buy. Its the same reason dial up networking works so easily in windows.

rild is a process which converts calls from processes on android into the equivalent AT command. Eg the dialler may call 'dial_number(123456)'. Rilld will accept this on a socket and send AT123456 to the modem to dial the number.

rild listens on a bunch of sockets when it starts, and each handles some kind of service. The 1.6 or 2.0 rilds listen on MORE sockets because they support more services. For that reason using the 1.5 rild on 1.6 or 2.0 isnt going to be possible. Android errors because it can't find the services it expects.

Short answer 1.5 rild is NOT compatabile with android 1.6 or 2.0

Since all modems use the same AT commands, the solution would be to use the ion (google dev phone) rild. We can patch a couple of strings very easily if there are small command spelling changes.

Problem.. Samsung use some secur ril interface. We have no idea how its secured or how it works. That means we need an equivalent secure ril OR the source code for samsung's rild. Its unlikely they'll hand that over because its probably the same interface they use in their other phones.

Bottom line.. without rild, we can port android 2 but the phone functions just wont work, so whats the point!
 
Upvote 0
That means we need an equivalent secure ril OR the source code for samsung's rild. Its unlikely they'll hand that over because its probably the same interface they use in their other phones.

So if some of the other phones gets upgraded to 1.6 or 2.0 it's likely that we can use its rild? I mean, then we wouldn't need a source, provided it uses exactly the same protocol between the daemon and the modem as Galaxy. (and I use the word "we" very..... incorrectly. :) )

Anyway, very good and clear explanation. Thanks. I think it would be a good idea to be put in the FAQ (or at least the short bit, with a link to your post).
 
Upvote 0
Normally yes we could use one from another phone. But we already have one from the ion build.

BUT the crucial thing here is samsung use some secure ril layer. Its probably totally custom to them. No one has shared rild source code as yet and its unlikely any manfuacturer will. We specifically need samsungs rild source code tho because of this secure ril, and because they probably use the same stuff in their non android phones they probably wont be disclosing it.
 
Upvote 0
OK. All that said, now I have no doubt that our Galaxies will eventually run Eclair (maybe not tomorrow, but in a few months). Even if Samsung abandon its current Android phones they're bound to release a new phone that runs 2.0 some time next year, and then we'll hopefully have the right ril.

I just want to understand this a little bit better so I did a little bit of reading. So, as radio interface library (RIL) is composed of the daemon (rild) and the vendor specific RIL (libril-vendor.so), I guess the latter one is the one that gives us trouble, because it is proprietary and without source.

You say that 1.6 and 2.0 RIL listens on more ports that on 1.5. Then the trouble is that 1.6 or 2.0 daemon doesn't know how to talk to the old libril-vendor.so (which would be taken form current 1.5), so in fact the only thing we need is the correct libril-vendor.so which could be (hopefully) taken from any Samsung device that will run 2.0 in the future. Did I get that even halfway right?

Thanks.
 
Upvote 0
If migrating galaxy to 1.6 or 2.0, why not port the stuff that we want from 1.6/2.0 to 1.5? Surely it should be easier to port, say, the settings portion as a separate application (and I guess you'd need root), no?

By that logic, I could port all my Windows 7 applications to run in DOS and get all my Xbox 360 games to run on an original Xbox.

Porting -forwards- is theoretically relatively simple I guess - most OSes are backwards compatible to a greater or lesser extent; porting -backwards- could well be a complete application rewrite, assuming that it's even possible to implement the same features under the older OS. So then you're back to the application developers, who have stopped developing the older versions, hence the problem in the first place.

Even if theoretically we could get back-ported applications, you'd forever get moany arses on Internet forums going "the new version of $foo has this feature, why doesn't the old one have it, wah wah wah etc." It'd be a never-ending cycle.

The closest you're going to get to ported applications is the ones we have already; ie, the last 1.5 compatible build before the devs move on. Bear in mind that your 1.5 applications aren't all magically going to stop working when 1.6 / 2.0 is mainstream, all that it means is that you won't get any future development.
 
Upvote 0
Bear in mind that your 1.5 applications aren't all magically going to stop working when 1.6 / 2.0 is mainstream, all that it means is that you won't get any future development.

The problem are not 1.5 applications, but 1.6 applications that are not backward compatible to 1.5 (which is only few months older than 1.6).


Imagine that Microsoft brought Windows Office that works only on Windows7, although Windows7 came out only few months after Vista. Double impossible.

I understand you wouldn't be able to port multitouch browser to 1.5 if your melfaz drivers are singletouch, but still you should be running that browser with reduced functionality. We are far from that, google to blame mainly.
 
Upvote 0
By that logic, I could port all my Windows 7 applications to run in DOS and get all my Xbox 360 games to run on an original Xbox.

True. With this, though, we have access to Android's source code (ah, how I love open source), this makes it easier. There are 2 options for a new version, the first is when something in the public interface has changed (i.e. a return type of a method is different --- either object or value), or you've added features.

If the changes are all adding features, then the version numbering then becomes a marker to say the feature set that these things are able to work on.

If, however, the changes are to do with the public interface, then I'm sure that they're not going to have removed the functionality without providing a replacement. The task then becomes, figuring out which calls still work, which don't and then how to use the API to emulate the ones that don't.

The main problem is time, if someone were to go to the effort of porting this stuff, you'd be months behind Samsung. So, if and when they release the updates all that effort would be effectively wasted.

The problem are not 1.5 applications, but 1.6 applications that are not backward compatible to 1.5 (which is only few months older than 1.6).

Mostly this comes down the poor programming on the application's side. They should be able to isolate the parts that require the functionality of the higher SDKs. I was looking at AndNav2, and (unsurprisingly) it didn't work because it required 1.6's text to speech. If the developer had coded it so that it disabled that feature and informed the user, then it wouldn't have been a problem.
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones