Android RIL architecture learning Summary

 

1. Android RIL concept (from http://newfaction.net/2011/03/08/android-ril-structure-learning-summary.html)

Android RIL is an abstraction layer based on the Telephony Service and Raido hardware layer. By studying the RIL code, we can see that the rild library of Android is between the Hal interface and basebandmodem, it also provides functions for voice, data, text messages, SIM card management, and STK applications. The idea is similar to that of Microsoft's RIL, it also calls the active request operations such as dial commonly used in the standard gsm27.007 as a request, with a total of 75 requests. The other types of GSM modules actively report such information as signal strength and base station information, it is called Unsolicited Response. There are 17 in total. The development mode is similar to that of Microsoft RIL. You need to develop different GSM drivers for different GSM modules. The public part of Google is ready for you, you need to customize specific parts by yourself. This can greatly improve the development efficiency. Below is RIL
Interaction Diagram

2. Local Code:

 

The local code supported by rIL includes the RIL library and daemon:

Hardware/RIL/include

Hardware/RIL/libril

Hardware/RIL/rild

The compiling result of hardware/RIL/reference-RIL is

/System/bin/rild: Daemon

/System/lib/libril. So: RIL Library

/System/lib/libreference-ril.so: RIL Reference Library 3. rilinitialization

Android initializes the Telephony stack andthe vendor RIL at startup as described in the sequence below:

(1). RIL daemon reads rild. Lib path andrild. libargs System Properties to determine the vendor RIL library to use andany initialization arguments to provide to the vendor RIL

(2). RIL daemon loads the vendor rillibrary and callril_init to initialize the RIL and obtain a reference to rilfunctions

(3). RIL daemon CILS ril_register on theandroid telephony stack, providing a reference to the vendor RIL Functions

See the RIL daemon source code at // device/commands/rild. C for details.

4. rild Execution Process

Rild is a daemon in which the macro ril_shlib is defined. The execution process is as follows:

Obtain parameters-> open the function library-> Create an event loop (thread)-> execute ril_init-> ril_register.

Int main (INT argc, char ** argv) {/* Get the parameter and parse */dlhandle = dlopen (rillibpath, rtld_now);/* Start the thread, enter the event loop */ril_starteventloop (); rilinit = (const ril_radiofunctions * (*) (const struct ril_env *, Int, char **) dlsym (dlhandle, "ril_init "); /* processing parameter */funcs = rilinit (& s_rilenv, argc, rilargv); ril_register (funcs); done: While (1) {sleep (0x00ffffff );}}

5. RIL Interaction

RIL has two types of execution flow storage:

(1) solicited commands: Based on RIL Lib, such as dial andhangup.

(2) Unsolicited Responses: Based on baseband, such as call_state_changed and new_sms.

5.1 solicited

The following two sections of code are request interfaces:

Void onrequest (INT request_id, void * data, size_t datalen, ril_token t );

Void onrequestcomplete (ril_token T, ril_error E, void * response, size_t responselen); The following diagramillustrates A solicited call in Android.

5.2 unsolicited

The following code is a non-request interface:

Void onunsolicitedresponse (intunsolresponse, void * data, size_t datalen); The following dimo-strates anunsolicited call in Android.

6. ril_init

When using the custom RIL Lib, because rild obtains a set of function pointers through the ril_init symbol and establishes a connection with it, the ril_init function must be implemented. The ril_init function is defined as follows:

Ril_radiofunctions * ril_init (ril_env * ENV, int argc, char ** argv); ril_init shocould return a ril_radiofunctions structurecontaining the handles to the radio functions:

type structure {       int RIL_version;       RIL_RequestFunc onRequest;       RIL_RadioStateRequest onStateRequest;            RIL_Supports supports;       RIL_Cancel onCancel;       RIL_GetVersion getVersion;}

Ril_radiofunctions; 7. Analyze the initialization process.

The main entry is the main function in rild. C. It mainly completes three tasks:

(1) Enable the event mechanism in libril. So. In ril_starteventloop, it is the core message loop driven by multiple I/O.

(2) initialize librefrence_ril.so, that is, the communication with the hardware or analog hardware modem (hereinafter referred to as the hardware), which is completed through the ril_init function.

(3). Use ril_init to obtain a group of function pointers ril_radiofunctions, register ril_register, and open the socket channel that accepts upper-layer commands.

8. RIL communicates with the upper layer in two ways:

(1) One is to send and receive messages through socket,

In C, this socket can find its creation code in RIL. cpp:

S_fdlisten = android_get_control_socket (socket_name_ril); in Java, in RIL. Java: S = new localsocket (); L = new localsocketaddress (socket_name_ril, localsocketaddress. namespace. Reserved );

S. connect (l); (2) Another method is to directly access the shared memory in the kernel through TCP/IP for RPC calling. This method is mainly used in data mode, because every activity of Android may need to receive and send data through a network connection at any time, a real-time access method must be provided to improve the communication efficiency.

References:

Http://www.netmite.com/android/mydroid/development/pdk/docs/telephony.html

========================================================== ======================

Introduction to some code of Android 2.2 RIL hardware

In the android source code, the hardware/RIL directory contains the underlying source code of rilhardware. The reference section of this directory tree is as follows:

|-Cleanspec. mk

|-Include

| '-Telephony

|-RIL. h

| '-Ril_cdma _sms.h

|-Libril

|-Android. mk

|-Module_license_apache2

|-Notice

|-RIL. cpp

|-Ril_commands.h

|-Ril_event.cpp

|-Ril_event.h

| '-Ril_unsol_commands.h

|-Reference-CDMA-SMS

|-Android. mk

|-Reference-cdma-sms.c

| '-Reference-cdma-sms.h

|-Reference-RIL

|-Android. mk

|-Module_license_apache2

|-Notice

|-At_tok.c

|-At_tok.h

|-Atchannel. c

|-Atchannel. h

|-Misc. c

|-Misc. h

| '-Reference-ril.c

'-Rild

|-Android. mk

|-Module_license_apache2

|-Notice

|-Radiooptions. c

|-Rild. c

'-Rild. C ~

I. Directory Hardware/RIL/include

 

Contains two header files: RIL. H and ril_cdma _sms.h, in which RIL. h defines 76 macros of the following types: ril_request_xxx, which represents the commands that the customer process can send to Android telephony, including SIM card-related functions, making phone calls, and sending text messages, network signal query. Ril_cdma _sms.h is the definition of some macros and struct used for cdma sms extension.

Ii. Directory Hardware/RIL/libril

The code in this directory is responsible for interacting with upper-layer customer processes. After receiving the client process command, call the corresponding function for processing, and then return the command response result to the client process. After receiving an event from the network side, it is also sent to the customer process.

1. File ril_commands.h: lists the commands that telephony can receive, the corresponding processing functions of each command, and the processing functions of the command response. For example:

{Ril_request_get_sim_status, dispatchvoid, responsesimstatus },

{Ril_request_enter_sim_pin, dispatchstrings, responseints },

{Ril_request_enter_sim_puk, dispatchstrings, responseints },

{Ril_request_enter_sim_pin2, dispatchstrings, responseints },

{Ril_request_enter_sim_puk2, dispatchstrings, responseints },

{Ril_request_change_sim_pin, dispatchstrings, responseints },

... 2. File ril_unsol_commands.h: lists the types of events that telephony can receive. processing functions for each event, such:

{Ril_unsol_response_radio_state_changed, responsevoid, wake_partial },

{Ril_unsol_response_call_state_changed, responsevoid, wake_partial },

{Ril_unsol_response_network_state_changed, responsevoid, wake_partial },

{Ril_unsol_response_new_sms, responsestring, wake_partial },

{Ril_unsol_response_new_sms_status_report, responsestring, wake_partial },

{Ril_unsol_response_new_sms_on_sim, responseints, wake_partial },

... 3. File ril_event.h/CPP: processing functions related to the event source (port, modem, etc. Ril_event_loop monitors all registered event sources. When an event source has data, the callback function of the corresponding event source is triggered (firepending-> ev-> func ()).

4. The file RIL. cpp has the following functions:

1) ril_register function: Open the listening port and receive command requests from the client process (s_fdlisten = android_get_control_socket (socket_name_ril);). When a connection is established with a client process, the listencallback function is called; create a separate thread to monitor and process all event sources (through ril_event_loop)

2) listencallback function: This function is called when a connection is established with the client process. This function then calls processcommandscallback to process command requests from customer processes.

3) processcommandscallback function: process command requests from customer processes. For each command, ril_commands.h specifies the corresponding order processing function (dispatchxxx), processcommandscallback will call this command processing function for processing.

4) dispatch functions: This function receives the corresponding parameters of commands from the customer Process and calls onrequest for processing.

5) ril_onunsolicitedresponse function: encapsulate events from the network side (by calling responsexxx) and send the events to the customer process.

6) ril_onrequestcomplete function: encapsulate the final response structure of the command (by calling responsexxx) and send it to the customer process.

7) response series functions: a corresponding response function is defined for each command to process the final response of the command; for each network-side event, it also specifies a corresponding response function to handle this event. The response function can be called by onunsolicitedresponse or onrequestcomplete.

Iii. Directory Hardware/RIL/reference-RIL

The code in this directory is mainly responsible for interacting with the modem.

1, file reference-ril.c:

The core functions of this file are onrequest and onunsolicited.

1) onrequest function: in this function, each ril_request_xxx request is converted to the corresponding atcommand, sent to the modem, and then sleep. After receiving the final response from this at Command, the thread is awakened and the response is sent to the client process (ril_onrequestcomplete-> sendresponse ).

2) onunsolicited function: This function handles various events received by the modem from the network, such as network signal changes, incoming calls, and text messages. Then pass the time to the client process (ril_onunsolicitedresponse-> sendresponse ).

2. File atchannel. C:

Reads and writes data to the modem. The write data (mainly at Command) function runs in the main thread, and the read data function runs in a separate read thread.

Function at_send_command_full_nolock: runs in the main thread. Write an AT command to the modem and enter the sleep state (using pthread_cond_wait or similar functions) until the modem read thread wakes it up. After waking up, this function obtains the final response of the AT command and returns it. The readerloop function runs in a separate read thread and reads data from the modem. Data read can be divided into three types: Incoming events on the network side, partial responses from the modem to the current at Command, and full responses from the modem to the current at command. For the third type of data (
All the responses of the command), The read thread wakes up (pthread_cond_signal) the main thread in the sleep state.

3. The file at_tok.c provides the at response parsing function.

4. Misc. C is a string matching function.

Iv. Directory Hardware/RIL/rild

The code in this directory is mainly used to generate executable files of rild and radiooptions.

1. radiooptions. c generates an executable radiooptions file. The radooptions program only transmits the command line parameter to socket {rild-Debug} for processing, so as to communicate with rild, you can configure modem parameters during debugging.

2. rild. C. Generate the rild executable file. For details about the rild process, see the androidril architecture learning summary.

========================================================== ==========

Introduction to some code of Android 2.2 RIL Java

In Android, telephony-related Java code is mainly in the following directories:

1. Frameworks/base/telephony/Java/Android/Telephony

2. Frameworks/base/telephony/Java/COM/Android/Internal/Telephony

3. Frameworks/base/services/Java/COM/Android/Server/telephonyregistry. Java

4. packages/apps/phone. The code in directory 1 provides a public interface for Android telephony, which can be used by any third-party application with permissions, such as telephonymanager. The code in directories 2 and 3 provides a series of internal interfaces, which are currently unavailable to third-party applications. Currently, it seems that only packages/apps/phone can be used. Directory 4 is a special application, or is understood as a platform internal process. Other applications call the services of this process in intent mode.

Telephonymanager

Telephonymanager mainly uses two services to access Telephony:

1. itelephony provides interfaces for operations and interactions with telephony, which are implemented by phoneinterfacemanager. Java in packages/apps/phone.

2. itelephonyregistry, which provides interfaces for registering telephony events. Implemented by frameworks/base/services/Java/COM/Android/Server/telephonyregistry. java.

Interface commandsinterface

Interface commandsinterface describes all telephone operation interfaces, such as commands, query statuses, and telephone event listening.

Class basecommands is a direct derived class of commandsinterface, which implements handling of telephone events (sending a message to the corresponding handler ).

The class RIL is derived from basecommands. RIL is responsible for implementing the interface methods in commandsinterface. RIL communicates with the rild daemon through socket. For each command interface method, such as acceptcall or status query, convert it to the corresponding ril_request_xxx and send it to rild. The thread rilreceiver listens to the socket. when data is reported, it reads and processes the data. There are two types of data read,

1. After reading the relevant data, ril_unsol_xxx and rIL sends a message to the corresponding handler (see the processunsolicited function)

2. asynchronous response of the command. (For details, see processsolicited)

Interface phone

Interface phone describes all the telephone operation interfaces. Phonebase is derived directly from phone. The other two classes, cdmaphone and gsmphone, are derived from phonebase and represent CDMA and GSM Operations respectively.

Phoneproxy is also derived directly from phone. You can use phoneproxy when you do not need to distinguish between cdmaphone and GSM phone.

The abstract class call represents a call, which has two Derived classes: cdmacall and gsmcall.

Interface phonenotifier

Interface phonenotifier

Defaultphonenotifier is derived from phonenotifier. In its method implementation, call service itelephonyregistry to publish a telephone event.

Service itelephonyregistey is implemented by frameworks/base/services/Java/COM/Android/Server/telephonyregistry. java. This class triggers the corresponding broadcast receiver by broadcasting intent.

When a phoneapp is created, sphonenotifier = new defaultphonenotifier ();... Scommandsinterface = new RIL (context, networkmode, cdmasubscription );

Then, create the corresponding phone based on whether the current phone is CDMA or GSM, for example, sproxyphone = newphoneproxy (New gsmphone (context, scommandsinterface, sphonenotifier ));

Next we will study the process of making a phone call.

1. twelvekeydialer. Java, onkeyup ()

2. twelvekeydialer. Java, placecall ()

3. outgoingcallbroadcaster. Java, oncreate ()

Sendorderedbroadcast (broadcastintent, permission,

New outgoingcallreceiver (), null, activity. result_ OK, number, null );

4. outgoingcallbroadcaster. Java, outgoingcallreceiver

Doreceive-> context. startactivity (newintent );

5. incallscreen. Java, oncreate/onnewintent

6. incallscreen. Java, placecall

7. phoneutils. Java, placecall

8. gsmphone. Java, dial

9. gsmcalltracker. Java, dial

10. RIL. Java, dial

Rilrequest RR = rilrequest. Obtain (ril_request_dial, result );

...

Send (RR );

The following describes an incoming call process:

1. When creating a gsmphone, MCT = newgsmcalltracker (this );

2. When creating gsmcalltracker:

Cm. registerforcallstatechanged (this, event_call_state_change, null);->

Mcallstateregistrants. Add (R );

3. The rilcycler thread in RIL first reads data from rild: processresponse-> processunsolicited

4. Corresponding to incoming call, rIL receives the ril_unsol_response_call_state_changed message and triggers all records in mcallstateregistrants.

5. gsmcalltracker processes event_call_state_change and calls pollcallswhensafe.

6. Function pllcallswhensafe processing:

Lastrelevantpoll = obtainmessage (event_poll_calls_result );

Cm. getcurrentcils (lastrelevantpoll );

7. RIL: getcurrentcils

Rilrequest RR = rilrequest. Obtain (ril_request_get_current_cils, result );

...

Send (RR );

8. Then, rIL calls processsolicited to process the returned results of ril_request_get_current_cils.

9. The gsmcalltracker's handlemessage is triggered. process the event event_poll_calls_result and call the function.

Handlepollcils

10. handlpollcils call

Phone. policynewringconnection (newringing );

11. Create callnotifier in phoneapp

12. callnotifier registration:

Registerfornewringconnection-> mnewringingconnectionregistrants. addunique (H, what, OBJ );

For more information about hardware, see android2.2 RIL hardware.

========================================================== ====================

Android phone app default startup comprehension and analysis of Java endpoints

The default process of the Android phone app is com. Android. Phone. This process has a feature. When you kill it, it will be created again. Many people may not find out why its running mode is different from that of other apps? I will not elaborate on my personal understanding below:

1. First, phoneapp.apk is stored in the system/APP Directory, which determines that phoneapp.apk has the ability to exceed other data/APP permissions. Obviously, it has system-level attributes.

2. The androidmanifest. xml contains the following descriptions:

<Application Android: Name = "phoneapp"

Android: Persistent = "true"

Android: Label = "@ string/dialericonlabel"

Android: icon = "@ drawable/ic_launcher_phone"> Android: Persistent = "true" determines that it must be run only. The official description of this attribute is as follows:

Android: Persistent

Whether or not the application shocould remain running at all times-"true" if it shocould, and "false" if not. the default valueis "false ". applications shocould not normally set this flag; persistence mode is intended only for certain system applications.

The preceding two parts determine com. Android. Phone. This process stores a value in the system.

What is the default Java portal for an app that is started by default and does not call activity? What class package is called?

The Android app processes are all fork, and the fork app process directly enters its own event loop. Take the General app startup process for analysis:

1. First click an application Venus that has not been started, and then it will fork out a process and enter its own event loop.

2. The first thing to do after entering the event loop is not to handle the Click Event Response, but to check whether the app has the default entry for the application. In the example above: Android: name = "phoneapp" is the application's entry class package name. If yes, check whether the class inherits from the application. If there is no entry, go to step 3.

3. Respond to the click event, and activitymanager searches for the mainactivity entry corresponding to the application and creates the class.

Summary: Java portal of phoneapp

Based on the phoneapp. Java class content

package com.android.phone; import *****； /** * Top-level Application class for the Phone app. */public class PhoneApp extends Application implements AccelerometerListener.OrientationListener {    /* package */ static final String LOG_TAG = "PhoneApp";     private static PhoneApp sMe;     public PhoneApp() {        sMe = this;    }     static PhoneApp getInstance() {        return sMe;    } ｝

From the code above, the phoneapp inherited from the application serves as the entry to the phone process.

Public phoneapp (){

SME = this;

} This method indicates that the class inherited from the application must be available to external instances. In fact, if this entry exists during the startup process, the class must be instance first. Android provides this interface to ensure that some applications need resident memory. These applications may need to provide some providers, services, and so on, but these functions must exist before the activity. Therefore, this entry is provided so that Java applications have an entry similar to the main function, perform initialization.