Android call setting source code analysis from top to bottom (top)

Android call setting is an application that is used to set content related to simcard, such as network and PIN, which is an AP layer. Here we will select one of the items to read from the source code until the underlying layer, and look at the approximate structure and process.

Select setting-> call setting-> additional call setting-> caller ID in the main menu of Android. A dialog box is displayed, this item is used to set whether to display the recipient's phone number when calling in the phone book. Here we will take this setting as an example to read it step by step.

 

AP layer:

The call setting code and resources are stored in the/packages/apps/Phone directory. In fact, the setting AP-related resources of Android are stored in/packages/apps/setting. But in/packages/apps/Settings/res/xml/settings. xml:

<PreferenceScreen
Android: key ="Call_settings"Android: title ="@ String/call_settings_title"Android: summary ="@ String/call_settings_summary">

<Intent android: action =" Android. intent. action. MAIN"Android: targetPackage =" Com. android. phone"
Android: targetClass =" Com. android. phone. CallFeaturesSetting"/> </PreferenceScreen>
From this point, we can know that the call setting package of android points to the phone and that the entrance is the CallFeaturesSetting class. In/packages/apps/Phone/res/call_featrue_setting.xml, the call setting interface layout is as follows: <PreferenceScreen android: key = "button_more_expand_key"
Android: title = "@ string/labelMore"
Android: persistent = "false">...

 

<ListPreference android: key = "button_clir_key".../> the button_clir_key is the corresponding caller ID button. It can be seen from this that it is a ListPreference. A list box is displayed when you click it. The content layout is defined here. The related xml files are all under/packages/apps/Phone/res. Next, the AP code is in/packages/apps/Phone/src. The preceding entry is CallFeaturesSetting: public class CallFeaturesSetting extends PreferenceActivity {

...

Private PreferenceScreen mSubMenuFDNSettings;

Private ListPreference mButtonCLIR;

Private CheckBoxPreference mButtonCW;

...

Protected
Void onCreate (...) {

...

PreferenceScreen prefSet = getPreferenceScreen ();

MButtonCLIR = (ListPreference) prefSet. findPreference (BUTTON_CLIR_KEY );

...

The defined mButtonCLIR is the variable corresponding to the caller ID. Initialize in onCreate and use findPreference to find the corresponding resource in XML.

Then the response code for this button is:

Public
Boolean onPreferenceChange (Preference
Preference, Object objValue ){

If (preference = mButtonCLIR ){

HandleCLIRClickRequest (mButtonCLIR. findIndexOfValue (String)
ObjValue ));

...

}

Private
Void handleCLIRClickRequest (int I ){

...

MPhone. setOutgoingCallerIdDisplay (I, Message. obtain (mSetOptionComplete, EVENT_CLIR_EXECUTED ));

}

 

We can see that mPhone. setOutgoingCallerIdDisplay is called to complete the real setting. This mPhone is

Com. android. internal. telephony. Phone. The call of mPhone enters the framework layer.

 

Framework layer:

The related code is in/frameworks/base/telephony/java. Start with Phone. This is an interface.

Com. android. internal. telephony. gsm. GSMPhone:

 

Public void setOutgoingCallerIdDisplay (int commandInterfaceCLIRMode, Message onComplete ){
MCM. setCLIR (commandInterfaceCLIRMode,
H. obtainMessage (EVENT_SET_CLIR_COMPLETE, commandInterfaceCLIRMode, 0, onComplete ));
}

 

Here we call mCM. setCLIR. MCM is a CommandsInterface, which is actually implemented in the RIL. java file. Now in the framework

What is truly practical. It is also in com. android. internal. telephony. gsm, in the RIL class:

Public void setCLIR (int clirMode, Message result)

{
RILRequest rr = RILRequest. obtain (RIL_REQUEST_SET_CLIR, result );
Rr. mp. writeInt (1 );
Rr. mp. writeInt (clirMode );

...
Send (rr );
}

 

By the way, RIL communicates with the underlying layer using socket. Therefore, send (rr) sends RIL_REQUEST_SET_CLIR to the underlying layer, and the underlying layer has a daemon

Process to receive information about the framework layer and send the results. Continue to check the send code:

 

Private void send (RILRequest rr)
{
Message msg;
Msg = mSender. obtainMessage (EVENT_SEND, rr );
AcquireWakeLock ();
Msg. sendToTarget ();
}

 

Is to send an EVENT_SEND message to the system. The location where the handle message is located is still in the same file. The RIL. RILSender class

HandleMessage:

 

Public void handleMessage (Message msg)

{

RILRequest rr = (RILRequest) (msg. obj );

Switch (msg. what ){
Case EVENT_SEND:

LocalSocket s;
S = mSocket;

...
Byte [] data;
Data = rr. mp. marshall ();
Rr. mp. recycle ();
Rr. mp = null;
// Parcel length in big endian
DataLength [0] = dataLength [1] = 0;
DataLength [2] = (byte) (data. length> 8) & 0xff );
DataLength [3] = (byte) (data. length) & 0xff );
S. getOutputStream (). write (dataLength );
S. getOutputStream (). write (data );

...

 

Here mSocket is the socket that communicates with the underlying layer. If you are interested, you can check the relevant code.

Here, the framework layer has come to an end, and the bottom layer is the C part. In the next article.