Why cant we port android 1.6 or 2.0 to the galaxy? google released the source code

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

 

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.

 

Has anyone asked Samsung nicely? We're doing them a favor.

 

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.

 

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 !

 

Some further info here from someone testing the ROM Google Translate