How does Modem code talk to Android code

Question

I would like to know high level idea of how Android Modem code will call/pass message to Android application layer. Say we take SMS for example. If network sends SMS and Modem (say Qualcomm C code parses it) how is it transmitted to Android Application layer?

Is there always a JNI call happening? as interface between modem and Android? Can you please share the information with us. Thanks

Solution 1

In almost all android source base as found in the AOSP/CAF/CM source (Android Open Source Project, CodeAurora Forum, Cyanogenmod respectively), will have C code called the rild, (Radio Interface Layer Daemon). This is commonly found within the /hardware/ril of the source tree.

This daemon runs from the moment Android boots up, and creates a socket called /dev/socket/rild and /dev/socket/rild-debug. There will be a proprietary library coming from Qualcomm, HTC, that gets dynamically loaded at run time upon boot. It is that proprietary library that in turn, communicates to the radio firmware. And the rild's hooks for the call-backs into the proprietary library is established there and then.

At the rild layer, via the aforementioned socket, is how the Android layer (found in the source tree, frameworks/base/telephony/com/android/internal/telephony/RIL.java) communicates.

On the Java side, it opens the socket for reading/writing, along with establishing intents and setting up delegates for broadcasting/receiving events via this socket.

For example, an incoming call, the proprietary library, invokes a callback hook as set up by rild. The rild writes standard generic AT Hayes modem commands to the socket, on the Java side, it reads and interprets the modem commands, and from there, the PhoneManager broadcasts CALL_STATE_RINGING, in which Phone application (found in the source packages/apps/Phone) has registered a receiver and kickstarts the User interface, and that is how you get to answer the call.

Another example, making an outgoing call, you dial a number on Android, the intent gets created and which in turn the PhoneManager (This is the root of it all, here, cannot remember top of my head, think its in frameworks/base/core/java somewhere in the source tree) receives the intent, convert it into either a sequence of AT Hayes modem commands, write it out to the socket, the rild then invokes a callback to the proprietary library, the proprietary library in turn delegates to the radio firmware.

Final example, sending text messages, from the Messaging (found in packages/apps/Mms source tree) application, the text you type, gets shoved into an intent, the PhoneManager receives the intent, converts the text into GSM-encoded using 7-bit GSM letters (IIRC), gets written out to the socket, the rild in turn invokes a callback to the proprietary library, the proprietary library in turn delegates to the radio firmware and the text has now left the domain of the handset and is in the airwaves somewhere... :) Along with sending a broadcast message within Android itself, provided that READ_PHONE_STATE permission is used and specified in the AndroidManifest.xml.

Likewise conversely, when receiving a text message, it is in the reverse, radio firmware receives some bytes, the proprietary library invokes the callback to the rild, and thus writes out the bytes to the socket. On the Java side, it reads from it, and decodes the sequence of bytes, converts it to text as we know of, fires a broadcast with a message received notification. The Messaging application in turn, has registered receivers for the said broadcast, and sends an intent to the notification bar to say something like "New message received from +xxxxxx"

The intents are found in frameworks/base/telephony/java/com/android/internal/telephony/TelephonyIntents.java

That is the gist of how the telephony system works, the real beauty is, that it uses generic AT Hayes modem commands thusly simplifying and hiding the real proprietary mechanisms.

As for the likes of Qualcomm, HTC, forget about it in thinking they'd ever open source the library in question because the radio telephony layer is embedded within the S-o-C (System on a Chip) circuitry!

Which is also, as a side note, why its risky to flash radio firmware, some handsets provide the capability to do it, flash the wrong firmware (such as an incompatible or not suitable for handset), kiss the handset good-bye and use that as a door stopper or paper-weight! :)

It should be noted, that there is zero JNI mechanisms involved.

This is from my understanding of how it works, from what I can tell is this, the radio firmware is loaded into a memory address somewhere where the linux kernel has reserved the address space and does not touch it, something like back in the old PC days when DOS booted up, there was reserved addresses used by the BIOS, I think, its similar here, the addresses marked as reserved are occupied by the firmware, in which the proprietary radio library talks to it - and since the library is running in the address space owned by the kernel, a lá owned by root with root privileges, it can "talk" to it, if you think of using the old BASIC dialect of peek and poke, I'd guess you would not be far off the mark there, by writing a certain sequence of bytes to that address, the radio firmware acts on it, almost like having a interrupt vector table... this am guessing here how it works exactly. :)

Solution 2

Continuing from the explanation by t0mm13b, When we talk about a smartphone, think of 3 layer operations wrt to SMS/Calls.

RIL (User level) <-> AP <-> CP

AP : Application Processor(Where your Android OS runs. Think of games, songs, videos, camera etc running on this processor)

CP : Cellular Processor (Which actually deals with Air-interface for incoming/outgoing calls/sms, interacts with Network Tower etc ..)

Now let say some data is received at CP side (It could be internet data/sms/call). Now there are certain logical channels between AP and CP. So CP will push the data received to a corresponding channel based on type of data. This data will be received by AP. AP will send this data back to RIL/App. RIL will decode this data (specially call/sms data). Based on that gives notification to User about SMS/Call.

Comments

[Janus Troelsen]

so if you swap the rild for Osmocom OpenBSC, you have an open phone?

[t0mm13b]

@JanusTroelsen That would be doubtful, depending on the radio's firmware chipset within the handset and that may have more features specific in which a proprietary library would be required to handle that.

[gonzobrains]

How are hooks into the rild layer made without the use of JNI?

[t0mm13b]

@gonzobrains sockets! read the 5th and 6th paragraph above :) socket named rild which is created by the ril daemon, the java side opens that for read/write...

[gonzobrains]

@t0mm13b Is there any way for third-party apps to hook into these interfaces for monitoring purposes? Considering this could be a security issue, would it be possible if one were to build their own ROM image from source in order to do this? I need to be able to monitor hardware events for not only the modem, but for other peripherals like the camera, radio, etc. Thanks!

[t0mm13b]

@gonzobrains in theory, you could replace or modify the rild daemon to log the Hayes AT&T commands... it is in there by modifying the code, one could intercept the command sequence for initiating a call etc in such a way the java/android side does not see it... this definitely requires a customized ROM from scratch. A MITM thing if you get me... its not easy - could end up breaking the entire rild's core purpose of receiving/making calls/sms....

[B770]

if the call is placed and the callee accepted the call how is the voice input routet through the phone? Is the input from the microphone also transmitted via ´rild´ and sockets?

[t0mm13b]

@B770 That is handled transparently by telephony chipset, Android at the high-level handles the routing provided the conditions are met, i.e. if headset plugged in, re-route, else, normal (business as usual through mouthpiece/earpiece), else if bt headset activated, re-route else normal. So no, the input from microphone is not transmitted via rild/sockets.

[B770]

sorry I don't get it. So let's say I am on the phone without any headset. The voice that came from the microphone is sent to which part? Is this vendor specific?

[t0mm13b]

Which part do you not get? voice sent to earpiece/mouthpiece, that is default and if there's audio re-route in place, android will handle that!

[B770]

OK so the audio re-rout is the interresing part. Do you know how andoid will handle that? Is it handled in a seperate chipset? So there aren't any chances to change the buffer that contains the voice input?

[t0mm13b]

The audio component in the telephony chip, that cannot be changed - have a funny feeling from your quizzing that you're trying to find a way to alter the voice pattern? There's a libaudio that is open alright - in hardware/libaudio, that is one facet, the other is buried deep in the framework/base/media from what I recall.. top off my head...

[t0mm13b]

Just be aware, the lower level stuff underneath what I have described in my answer is off-limits and closed source - so no telling there how exactly. Also, there's GSM, CDMA which are kind-of distinctive frequencies for telephony which uses their own vendor specific libraries as is by Samsung, Motorola, HTC, you name it. There is no open-source telephony mechanism known in that aspect of Android - does not exist.

[B770]

Yes, it would be interresting to play a pre-recorded file. So one option would be to change the buffer that is written from the mic.

[t0mm13b]

Sorry, cannot be done! Nobody knows, I don't either, and faking, audio input stream to make a original male voice from NYC to a London female voice is impossible to achieve in this regard from this viewpoint of Android, along with varying makes/models of close-source telephony stuff - its a bit of mystery really unless you happen to work intimately with such manufacturers and have that inside knowledge...

[B770]

Ok, there is one question left. Is there any official statement that audio routing is done by the vendor?

[t0mm13b]

Look in android source to see how the audio routing is done, vendors are free to change the routing as they see fit themselves.

[jiggunjer]

Are you sure the (e.g. Qualcomm) telephony library is on the SoC? I thought that was what the baseband/radio partition on the eMMC was for.

[Jason Krs]

I assume people who create Call Manager app write code that directly interacts with ril.java ... Let's say I'm in Android Studio, is it possible to attack it directly to create my own Call Manager app ?