Android core analysis (17)-telephone system rild

Android phone system-rild

Rild is a local service started by the INIT process. This local service does not use communication methods such as binder, but uses Socket communication. RIL (radio interface layer)

Android provides a RIL implementation framework. Because the modem used by Android Developers is different, the various command formats and initialization sequences may be different, and the difference between GSM and CDMA is even greater. to eliminate these differences, android designers abstract RIL and use the concept of a virtual phone. The virtual phone object is the GSM phone (cdmaphone). The functional protocols provided by the phon object and the underlying supporting environment must have a uniform description, the implementation of this underlying description relies on RIL for adaptation.

Andoid divides the RIL layer into two code spaces: The rild management framework and the at-related xxxril. So Dynamic Link Library. The advantage of separating RIL into a dynamic link library is that the Android system adapts to different modem, and there can be an independent RIL corresponding to different modes. From this perspective, rild is more of a management framework.

RIL is the specific at command synthesizer and response parser. In terms of the most basic functions, rIL establishes a listening socket, waits for the client connection, and then reads RIL-Java from the connection into the passed command and converts it into the AT command and sends it to the modem. Wait for the modem to respond, and then pass the result back to the RIL-Java layer through the socket. Is the basic framework of RIL-D:

The following data flow transfer description chart describes the 5 steps for the RIL-JAVA layer to issue a telephone instruction.

 

There are two types of responses in the at communication process: one is to give a response after a request, and the other is a notification, that is, the response is not sent by yourself, for example, the SMS notification reaches, we call this type of notifications URC. In rild, URC and general response are processed separately. In concept, URC is processed by the handleUnsolicited@Atchannel.c, while response is processed by handlefinalresponse.

1 event Loop

The true essence of rild management is in RIL. cpp, ril_event.cpp. During the study, we can see the designer's efforts in abstraction, and the design is very elegant. The basic task of event loop is to wait on the event port (serial port, socket). Once data arrives, it is processed according to the registered Event Callback Function. Now let's look at how RIL designers set up a management framework to complete these tasks?

1.1 event object

Composition of event objects: (FD, index, persist, func, Param)

FD	Event-related device handle. For example, for a serial data event, FD is the device handle of the relevant serial port.
Index
Persist	If it is maintained, it is not deleted from watch_list.
Func	Callback event processing function
Param	Callback Parameters

To manage events in a unified manner, Android uses three Queues: watch_list, timer_list, and pending_list, and uses a device handle pool readfds.

Readfds: fd_set of Linux. readfds stores all the device file handles in rild, so that the select function can be used to uniformly listen events.

Watch_list: monitoring time queue. All events to be detected are put in this queue.

Timer_list: timer queue

Pending_list: the queue of events to be processed. events that have been triggered and need to be called back.

Operations on the event queue: ril_event_add, ril_event_del, ril_timer_add

In the add operation, there are two actions:

(1) Add to watch_list

(2) Add the 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 FDS. As long as the device recorded in FDS has data, the Select function sets the corresponding flag and returns the result. Readfds records all event-related device handles. In readfds, the handle is added in addevent. All event listening is based on select readfds in Linux.

Ril_event_loop uses select to wait on readfds (fd_set). When the select device has data, ril_event_loop returns from select and places the corresponding event in watch_list to pend_list, if the event is persistent, It is not deleted from watch_list. Then ril_event_loop traverses pengding_list to process Event Events and initiate an Event Callback Function.

1.3 important events

The above analysis shows the RIL-D Framework. What are the running events on this framework?

(1) s_listen_event-(s_fdlisten, listencallback)

Listencallback processing function,

Receive client connection: s_fdcommand = accepte (..)

Add s_commands_event ( )

Re-establish s_listen_event and wait for the next connection

(2) s_command_event (s_fdcommand, processcommandscallback)

Read streamrecord from the fdcommand socket connection

Use processcommandbufer to process data

S_listen_event processes client connections (connect initiated by the RIL-Java layer) with large functions, and establishes s_commands_event to process RIL commands sent from socket connections. Processcommandbufer actually contains the downlink process of the RIL command.

1.4 downstream Command Translation and its organization @ processcommandbuffer

Command Format passed by ril_java: parcel , Which consists of the command number, Token, and content. When ril_java reaches ril_c, it is converted to build local requestinfo and translated into specific AT commands. Because the parameters of each at command are different, there are different conversion functions for different AT commands. In this android design, an abstraction is provided here and a distribution framework is developed, use the command number and the scommand array to obtain the processing function of the command.

Scomand [] = {

<...>

}

Scomand exists in 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 what we need to modify according to different modem files.

1.5 send_at_command framework

Send_at_command is synchronous. After the command is sent, send_at_command will wait in s_commandcond until sp_response-> finalresponse exists.

2 read loop@Atchannel.c

Read loop resolves the problem by parsing the response sent from the modem. Ril_java reported by handleunsolicited in case of URC. If it is a command response, handlefinalresponse is used to notify send_at_command of the response result.

 

For URC, rild also uses an abstract array @ RIL. cpp.

Static unsolresponseinfo s_unsolresponses [] = {

# Include "ril_unsol_commands.h"

};

And use ril_onunsolicitedresponse to send the URC to the upstream layer.

3 RIL-D overall data flow and Control Flow