the-rild of Android phone system
Rild is a local service initiated by the Init process, and the local service does not use a means of communication such as binder, but instead uses the socket communication method. RIL (Radio Interface Layer)
Android gives a RIL implementation framework. Because Android developers use a different modem, various instruction formats, initialization sequence may be different, GSM and CDMA are more differentiated, so in order to eliminate these differences, Android designers will Ril do an abstraction, using a virtual phone concept. This virtual phone object is Gsmphone (Cdmaphone), the Phon object provides a functional protocol, and requires the underlying support environment has a unified description, the implementation of this bottom-level description is to rely on Ril to complete the adaptation.
Andoid divides the RIL layer into two code spaces: Rild Management framework, at-related xxxril.so dynamic link libraries. The advantage of Ril standalone into a dynamic link library is that the Android system adapts to different modems, and different mode can have an independent RIL corresponding to it. At this level, Rild is more of a regulatory framework.
The RIL is the specific at command synthesizer and the answer resolver. From the most basic function, RIL establishes a listening socket, waits for the client to connect, then reads the Ril-java from the connection and translates it into the AT command to send to the modem. and waits for the modem to respond, then passes the result through the socket interface to the Ril-java layer. is the basic framework of ril-d:
The following data Flow Delivery description chart Describes the 5 steps of a Ril-java layer issuing a call order.
There are two types of responses in the process of the at communication: one is the response after the request, and the other is the notification class, that is, unsolicited, for example, SMS notification is reached, we call the class notification as URC. In Rild, URC and general response are handled separately, conceptually URC by [email protected], and response is handled by Handlefinalresponse.
1 Event Loop
The true essence of rild management in the Ril.cpp,ril_event.cpp, in the process of research, you can see the designers in the abstraction of the effort, design is very beautiful. The basic task of event loop is to wait on the event port (serial port, Socket), and once the data arrives, it is processed according to the registered event callback function. Now let's see how the RIL designers set up a management framework to accomplish these tasks.
1.1 Event Object
Event Object composition: (Fd,index,persist,func,param)
Fd |
The event-related device handle. For example, for serial data events, FD is the device handle of the relevant serial port |
Index |
|
Persist |
If it is persisted, it is not removed from the watch_list. |
Func |
Callback event handler function |
Param |
Callback-Time parameters |
To manage events uniformly, Android uses three queues: Watch_list,timer_list,pending_list, and uses a device handle pool Readfds.
Readfds: Linux Fd_set,readfds holds all the device file handles in Rild in order to use the Select function to listen for a unified completion event.
Watch_list: Monitoring time queue. The events that need to be detected are placed in the queue.
Timer_list:timer queue
Pending_list: The event queue to be processed, the event has been triggered, and the event to be processed by the callback is required.
Event Queue Queue operations: Ril_event_add,ril_event_del, Ril_timer_add
In the add operation, there are two actions:
(1) Add to Watch_list
(2) Add a handle to the Readfds event handle pool.
1.2 Ril_event_loop ()
We know that for Linux devices, we can use the Select function to wait on the FDS, as long as the device recorded in the FDS has data to come, select will set the corresponding flag and return. Readfds records all event-related device handles. The handle in Readfds is added in Addevent. All event interception is based on the Linux select Readfds.
Ril_event_loop uses Select to wait on Readfds (fd_set), when the Select Device has data, Ril_event_loop returns from Select, and the corresponding event in Watch_list is placed into the Pend_ List, if the event is persistent, it is not removed from watch_list. The ril_event_loop then iterates through the Pengding_list processing event and initiates an event callback function.
1.3 Several important event
The above analyses the frame of the ril-d, what is the event that runs on the frame
(1) s_listen_event-(s_fdlisten,listencallback)
Listencallback processing function,
Receive client connections: S_fdcommand=accepte (..)
Add S_commands_event ()
Re-establish s_listen_event, wait for next connection
(2) s_command_event (S_fdcommand,processcommandscallback)
Read Streamrecord from the Fdcommand socket connection
Working with Processcommandbufer data
S_listen_event handles the client connection on a large feature (connect from the Ril-java layer) and establishes s_commands_event to handle the Ril command sent from the socket connection. Processcommandbufer actually contains the downstream process of the RIL directive.
1.4 Downward command translation and its organization @processcommandbuffer
Ril_java passed command format: Parcel <request,token,content>, consisting of the command number, token, content. Ril_java arrives at Ril_c to build the local requestinfo and will be translated into a specific at command. Since the arguments for each at command are different, there are different conversion functions for different at directives, where the Android design makes an abstraction here, does a distribution framework, and obtains the processing function of the command by using the command number, utilizing the Scommand array.
scomand[]={
<ril_request_xxx,dispatchxxx,reponsexxx>
<...>
}
Scomand exist in the ril_command.h.
&scomand[]=
<
{Ril_request_get_imei, dispatchvoid, responsestring},
{ril_request_dial, dispatchdial, responsevoid},
{....}
>
Dispatchxxx functions are generally placed in the REFERENCE-RIL.C, reference-ril.c This is the one we need to change according to the different modem files.
1.5 Send_at_command Frame
Send_at_command is synchronous, and after the command is sent, Send_at_command will wait at S_commandcond until there is sp_response->finalresponse.
2 read [email protected]
The problem with the Read loop is to resolve the response from the modem. If you encounter URC, the Ril_java is escalated through handleunsolicited. If it is an answer to the command, the Handlefinalresponse notifies send_at_command that the result is answered.
An abstract array @ril.cpp is also used for urc,rild.
Static Unsolresponseinfo s_unsolresponses[] = {
#include "Ril_unsol_commands.h"
};
and use Ril_onunsolicitedresponse to send URC to the upper layer.
3 ril-d overall data flow and its control flow
The Rild of Android Core analysis------Telephone system