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
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. :)
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.
Related
My problem is as follows:
I would like to make an application to list the sms conversation using C# and AT Command ... (not Android)
The Android/iOS smartphone will be connected by USB cable.
is it possible ?
any ways to help me
Provided the phone implements a serial USB interface that speaks AT commands (Communication Device Class (CDC) Abstract Control Model (ACM)), then yes this is possible.
The command to read SMS messages is AT+CMGR and it is standardized in the 3GPP specification 27.005. For reading1 SMS messages there no special handling other than the normal AT command response parsing (never use sleep/delay/etc).
The sms commands operates in one of two modes, Text mode (optional) or PDU mode (mandatory). Text mode is simpler but does not provide all the meta information that PDU mode does. Depending on the phone or what you want to display and parse you might be required to use PDU mode.
Parsing the hexadecimal binary response you get in PDU mode is very far from trivial, and you most certainly want to use a library for this rather than trying to write parse code yourself (at least when your experience is starting on not knowing about the relevant commands and not having read V.250, 27.007 and 27.005 before).
1For sending you must wait for `"\r\n> " before sending the payload, see the first part of this answer.
Issues with Android-2-Arduino communication made it clear to me I have no clue which parts of the chain are (directly) affected by the baud rate. Could you please confirm/correct following assumptions?
The 'baud rate' value is not related to anything on the Android side. Therefore it is not a bug when an Android USB/Serial library only sends the baud rate value (9600, 125000, etc.) to the other side via controlTransfer, not storing it anywhere, not setting it somehow to the Android device itself.
When calling usbConn.controlTransfer with 'baud rate' parameter on Android, this command is NOT redundant to me calling Serial.init(baudRate) in the Arduino code. Both these calls are intended for different HW/parts. Both of those parts reside on Arduino. (Both, obviously, must be called with identical value.)
I'm working on android kernel (jelly bean).
I've focused on the /net/mac80211/scan.c module and on the scan behavior, to understand how the PS_mode exactly works. Anyway I can't find any syscall calling the ieee80211_scan_work function (where the ieee80211_start_scan() func is called) of the kernel on a higher level.
I'm wondering if this function is even called by the API, does anyone know it, and if it does, which syscall is rised?
See my response here to get a general overview of mac80211:
How to learn the structure of Linux wireless drivers (mac80211)?
The interface from userspace isn't based on syscalls but uses the netlink API.
Scanning is done by sending a NL80211_CMD_TRIGGER_SCAN command. After you get a NL80211_CMD_NEW_SCAN_RESULTS event that scanning was finished, you issue a NL80211_CMD_GET_SCAN to get the scan results.
To see examples of this look at wpa_supplicant code.
You can't see anyone calling ieee80211_scan_work because it's a workqueue handler. If you're not familiar with workqueue you can pick up a kernel book which explain them.
This work gets initialized in ieee80211_alloc_hw() as the handler of local->scan_work.
The code which "gets this running" is in ieee80211_start_sw_scan() which actually queues scan_work. Note that scan_work is only used in SW scan which means that mac80211 manages the scan (i.e. it keeps a timer to switch channels and calls the lower HW driver to set the HW to the specific channel). This is used only depending on your HW capabilities. For some hardwares the scan is done completely by the HW driver or even in firmware.
If your HW driver implements a HW scan it will implement the hw_scan mac80211 callback.
I am fairly new to Android Development and i have recently been exploring Usb Host.
Would anyone be able to tell me how to use Bulk Transfer so that i can see what an external camera sees but instead show it on my tablet?
Camera : Canon Powershot A1300
Tablet : Iconia A200
I have looked around stack overflow and some other forums but have not yet been able to find a good explanation on how to use Bulk Transfer or what constants to use as parameters for retrieving certain data.
I am able to see the endpoints and set up a connection with the external camera but I do not know where to go from here.
Any help is deeply appreciated.
The USB Host APIs in Android are fairly thin, by which I mean once you have gone beyond enumerating the interfaces/endpoints and creating a connection it doesn't do much more to assist you. You are then in the realm of communicating with raw USB data transfers, the format of which depend on the device class your camera represents. Your request is somewhat a can of worms, so I will do my best to provide helpful resources.
Unfortunately, storage and media devices are not the simplest device classes to interpret, so it may be difficult if you are just getting your feet wet on USB in general. The best advice I can give is to take a look at the device class specs for the interface class your camera reports (most are either Mass Storage or MTP), which can be found here: http://www.usb.org/developers/devclass_docs
The spec document will enumerate the commands you need to use to communicate with the device. I would also recommend checking out USB In a Nutshell, which does a great job of pointing out how USB requests are constructed in general, which can help you map what you see in a the spec docs to the parameters found in the methods of UsbDeviceConnection: http://www.beyondlogic.org/usbnutshell/usb1.shtml
There will likely be a handful of control commands you need to send to "endpoint 0" initially to set up the camera, and then the remaining transfers will likely take place over the bulk endpoints.
In Android terms, control requests can only be sent synchronously using UsbDeviceConnection.controlTransfer(), meaning this method blocks until the transfer is complete. The parameters that fill in this method are found in the spec docs for your device class.
Requests on bulk endpoints can be sent synchronously via UsbDeviceConnection.bulkTransfer() OR asynchronously using a UsbRequest instance. With UsbRequest you can queue a transfer and then later check back (via UsbDeviceConnection.requestWait()) for the results.
I have some examples on my Github page in using the host APIs to do some basic interrupt and control transfers to get information like device descriptors. Perhaps some of that will be helpful to you as well: https://github.com/devunwired/accessory-samples
With regards to your question about the USB example code:
The request made in this code is just a generic "Get Configuration Descriptor" request that all USB devices must respond to (it's a core command, not class-specific). In fact, its the request where the Android APIs get the information you can query for interfaces and endpoints. The field values come from the Core USB Specification (this command specifically is defined at section 9.4.3 and 9.6.3 in the 3.0 spec): http://www.usb.org/developers/docs/ or a more helpful description you can find from USB in a Nutshell, which has a little more discussion: http://www.beyondlogic.org/usbnutshell/usb5.shtml#ConfigurationDescriptors
The length is somewhat arbitrary, this tells the driver how many bytes to read or write. Most USB host drivers will first query the device descriptor, which includes a field telling the host the Max Packet Size the device supports, and then will use that size as the length for future requests. A full-featured driver would probably make this command and then check the length bytes first (the wTotalLength field of the descriptor) to see if the buffer was large enough, and modify/resend if not. In the example, I just chose 64 for simplicity because that is the "maximum" Max Packet Size the protocol defines as supportable.
Again, then making requests of the specific data your device has to offer, those commands will be found in the specific class document, not the core specification.
For some work I'm doing, I want to have an emulated GSM modem which will communicate with an Android-x86 virtual machine over a Unix socket. The VM should see the emulator as a real modem and use it to send SMS (as the first pass of functionality).
So far, I've put something together which handles some AT commands and just replies "OK" to all the rest. For some commands, like "AT+CRSM", I just have a table of responses gathered from running the official Android emulator and looking at the radio log. For others, I maintain some state and construct answers; those commands include:
CFUN?
CPIN?
CGREG?
CGREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CGSN
CIMI
CSQ
Android will boot, and send commands to my emulated modem, which answers, however it doesn't seem to be fully functional. Android doesn't detect any radio signal strength, for instance, just showing an "x" in the signal bar.
Does anyone know of a similar project, or just what AT commands are absolutely necessary to get some basic functionality?
Well, I'll answer another of my own questions, it's easier that way.
I ended up implementing an emulator which maintains a little bit of state, such as whether or not unsolicited CREG and CGREG messages are enabled, the network registration status & network name format (for the COPS command), and a message reference counter for SMS.
It supports the following commands:
CFUN?
CPIN?
CGREG?
CREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CMGS=
CGSN
CIMI
CSQ
All other messages just get an "OK" response.
With the stock AOSP Android source running in an emulator with the "-radio unix:/tmp/phone" switch, I can send SMS messages and decode the binary PDUs into real messages. I will continue to add functionality so SMS messages can be injected back to Android, and hopefully open-source the code at some point.