I've decided to put this in its own topic and sticky it, because people keep hijacking threads with this question, or opening new threads. Feel free to ask questions specifically about why here. It'll save us answering the same questions to everyone else! If it gets rediculously long i'll sumarize the points in this first post (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 ATD123456 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!
On a minor point of pedantry, IIRC I think the AT command here would be ATDT123456 (or perhaps just ATD if you don't need to specify Tone Dialing).
Why can't we use the 1.5 ril library in 1.6/2.0? Has the interface changed? What about a wrapper library that would have 1.6/2.0 interface but would translate that into calls into the 1.5 ril lib? Chris
contact this team, they are creating the programs to unlock and flash samsung pfones. z3x-team - Latest news
Chrmhoffman: We tried that, but the calls must have changed. That means its probably not going to be easy to write a wrapper to 'pretend' to support the other services. Its one possible route, but none of us feel like taking it because its alot more effort than its worth. vitali: Unlocking has nothing to do with this. Neither does flashing.
I was about to suggest the "wrap and simulate/delegate" approach. I suppose we can check what has changed by inspecting the rild related interfaces and checking for differences... The code for the different versions of the rild server and related libraries (not the Samsung specific plugin, of course) seems to be publicly available here: android.git.kernel.org Git - platform/hardware/ril.git/tags Also there seems to be a good explanation of how it works (I don't know yet which version it's about) here: Android - Radio Layer Interface
I've had a little look at the changes in android.git.kernel.org Git - platform/hardware/ril.git/summary from cupcake to donut and most of it seems to have been adding support for cdma. Apart from that some requests were deprecated and replaced by others to make them more general. Notably RIL_REQUEST_GET_IMEI was replaced by RIL_REQUEST_DEVICE_IDENTITY, for instance. Then the responses were changed in several cases, and, very important, because this precludes any kind of binary compatibility among 1.5 and 1.6 ril libraries, request numbers got... renumbered! (in order to make the numbers gapless, the comment says, so they could be used as an index into some "non-sparse" table). I guess a proxy library could be written doing the renumbering of requests and the adaption of responses. The library initialization would load the original Samsung one and then forward and adapt the requests and responses. New requests (at least the new ones that are required) would need to be emulated by using the old ones available. The 1.5 includes and tables should get the identifiers renamed (RIL -> OLDRIL or something like that) so that the library would be able to include both sets of headers and do sensible things. Of course, writing this kind of thing is an endeavour for a rather systematic person with a lot of available time... and effort that could be used for more important things if Samsung did what they should: just provide updated images (ril library and everything else) with/adapted for Donut. On the other hand, rild seems mostly untouched between cupake and donut. I think the thing about it listening to more sockets or something like that must be wrong.
Which hardware does it have for phone functions? Having that info and an integration manual, to get a working rild is not so hard. I even was thinking to enable libril AT debug mode, try to recompile it and replace it, just to "adb logcat" all the AT commands and have a reference to do a ril replacement... Anyway, if they forked rild or libril from the repository and added more patches, it could be more difficult to debug it or get more info... Another way could be to integrate the libreference-ril lib and just continue building it using the standard, but if it's implementing a "secure" mode to block these attempts, then it could be really difficult... Anyone else have been playing with this?
One question that came to my mind following the Sprint announcement of Samsung Moment going to 2.0: if Samsung updates to 2.0 and the following Android Releases (2.1, 2.2 or whatever) use the same kernel, does that mean it could be possible to port easily from 2.0 to 2.2 (for example) without waiting for Samsung to release it? I mean, if the problem is the actual rild is only valid for 1.5 and the big change came with 1.6 but now it is more or less the same for 2.0, then we would have a valid rild to use with newer versions, wouldn't we?
How does the rild communicate with hardware? Does it call special kernel functions or does it somehow write into baseband "memory addresses" or? Just curious. I know that we dont know how Samsung really does this, but how are others doing it? Chris
As far as I know (I might be wrong), 1.5 and 1.6 version rild works in the same way. It doesn't communicate with hardware... at least directly. It loads a vendor-specific dynamic library whose name is configured in a configuration value. Then it takes "requests" from a socket, and pushes them to the vendor library. When "responses" come back, they are pushed back to the socket connection that originated the request. It seems that it doesn't depend on the request/response format or types; it just shuffles them around from the applications connecting to the sockets to the vendor library. It's the responsibility of the application and the vendor library to interpret them. The vendor library is a kind of "plugin" that may be configured. Google's reference implementation opens a serial port device and sends AT commands over it when reacting to application requests. I don't know whether other vendors use the reference implementation. The thing is that the plugin-based architecture lets the vendor choose in which way to communicate with the radio hardware. Samsung decided not to use the reference architecture, it seems, but they implemented their own way to talk to the radio hardware/processor/whatever. You can't simply use the 1.5 version of the vendor library with an 1.6 system, since they changed the message formats and numbering scheme. As the Samsung library was compiled against the 1.5 headers, it expects 1.5 messages with 1.5 numbers, and won't react properly to 1.6 messages. It doesn't matter much which is the mechanism that Samsung uses for communicating with the radio HW. It's encapsulated in the vendor library, and you would have to rewrite its whole functionality in order to write your own. Sources for 1.5 and 1.6 are available, so we could study the differences and we should be able (at least theoretically) to map new requests to old ones and old responses to new ones, thus doing the translation between the application (1.6) format and the legacy vendor library (1.5) format. This could be done by writing a (1.6) "vendor" library that acted as a wrapper of the Samsung one, performing the translation, but it's no trivial work.
Thanks for your explanations. I was just curious how the unknown part might work... I wonder how much work that wrapper library really is. If I knew that Samsung is really not going to do it... BTW: eclair source is not even properly released. There's an eclair branch since Nov 13. but its not yet the main dev head of the android source, so maybe we should really be patient and give Samsung more time? The Galaxy is not a THAT bad device and competitors are not really there yet either (apart from Motorola Droid)
Part of the changes between 1.5 and 1.6 are just syntax (some constants have changed their names). Biggest changes are related to CDMA support and some about data connections... not quite difficult if you have a complete 1.5 implementation What has came to my mind reading your posts is that if Samsung releases one device with eclair, maybe we could get rild from it. But for doing that, it's important to know which hardware is included KR
DroidHead RT @sprint: Clarification on Android updates for the Hero & Samsung Moment. Will be updating straight to Android 2.1, not 2.0, in 1H2010. samsung moment is getting 2.1 first half ps : I know I'm posting everywhere but I'm excited. maybe Drakaz can use this if samsung don't release an update...
Is it really necessary to get a new rild for 1.6/2.0? Could anyone tell me why it's not possible to build cupcake or donut and use the old phone/rild stuff? I assume that even if there is a way to get a new rild, we still wont benefit from it, since the hardware is still the same. It's not like we're getting LTE all of a sudden
Hi, It's easy... Just as an example (these are not real calls but you'll get the idea): Android 1.5 ril has a method called "radioOff" which turns off the telephony part of the phone. When any part of Android (let's say a widget) wants to shut down the telephony, it calls "radioOff" and everything is OK. Android 1.6/2.0 ril has renamed that method and now it's called "setRadioOff". When any part of Android wants to shut down the telephony, it calls "setRadioOff" and everything is OK. But, if you replace the new ril for the old one, the widget will call to "setRadioOff" and that method will not exist because it's "radioOff". Imagine this with different parts of the library, and that's the whole problem.
rild itself is not a problem, since the source for both cupcake and donut versions is available. But the binary plugin that it loads in order to talk to hardware is Samsung's own, and there's no source available, so it's not possible to rebuild it. The format of the data interchanged between applications and the plugin was changed from cupcake to donut. So the binary plugin for cupcake won't understand the messages from the donut application layer (it will expect the old format and choke on the new one). rild itself doesn't matter in this case, since it doesn't look too much into the data, I think. It just passes it around.
skandalfo: well said. You're right. I personally don't feel like trying to write a wrapper, especially if 2.0 is only 2 or 3 months away (rumours!) Some other comments related to other peoples posts: The comms from the vendor lib to the phone is not done over a serial device and using AT commands. So its not possible to simply log them and hack up a rild. That was the original plan. There IS a serial device that accepts AT commands but they are very limited. Most likely just used to enter various modes on the secure interface on boot. Seperatly we have looked at the baseband to see if it might be possible to flash a radio from another device using the same hardware. We have the fpl and spl in one of the updates, so it is possible to try it, and then revert back. I strongly suspect that it wont work at all, even if it doesnt brick the radio Even if it does boot it will mis read the simsecure and calibration data and not get reception. I can patch the radio to read its information from another nvm folder, but its a might nasty hack!
Samsung I7500 mustymod ROM (Android 2.0) - Android @ MoDaCo Working devices: - GSM (call, text, data, no CDMA support) - Base devices (touchscreen, sound, sd-card & usb) Devices will be implemented: - WIFI (work in progress) - Sensors (accelerometer, light, compass) - Camera
Wow that came out of the blue! Hoping it's legitimate but I'll wait until everything is working before trying it. Anyone else tried it yet?
Nice!! This is highly unexpected for sure So this means that the secured baseband is bypassed/ cracked/ whatever?
This is a good surprise ! I looked into the rom, and it's just the 2.0 AOSP with the libsec-ril from 1.5 stock rom... i don't know how the guy can use it in 2.0, perhaps he find a way to mod the framework telephony to use it ? He have access to some source code from samsung ? Perhaps we just missed little something... curious to know what !
