Android 4.4 Kitkat Phone workflow analysis (6) _ InCallActivity display update process

 
Pre-Article: Analysis of Working Process of Android 4.4 Kitkat Phone (1) _ overview and learning plan

Android 4.4 Kitkat Phone workflow analysis (ii) _ UI Structure Analysis

Android 4.4 Kitkat Phone workflow analysis (iii) _ MO (Power removal) Process Analysis

Analysis of Android 4.4 Kitkat Phone workflow (iv) _ RILJ Workflow

Android 4.4 Kitkat Phone workflow analysis (v) _ MT (incoming call) Process Analysis

In the previous five articles, the MO/MT process of Android 4.4 is integrated, including simple ui structure analysis and rilj workflow analysis. This article and subsequent articles on Phone mainly supplement and explain the previous Main Line of MO/MT to improve the entire MO/MT process. During the analysis of the entire MO/MT process, many details were omitted. After figuring out the beginning and end of the entire MO/MT process, I found some doubts, therefore, we plan to analyze some missing details. The reason for initiating this article is very simple. I want to know how InCallActivity is displayed and updated. After analysis, I found that the interface update of Android 4.4 is also initiated from the Modem status change, the display page is not updated directly as before. Intuitively, when a user presses the dial-up key, the page that is calling is immediately displayed, that is, InCallActivity. In Android 4.2, this interface is called InCallScreen. As mentioned in the previous article, InCallScreen is displayed through upper-layer calls. In Android 4.4, the InCallActivity display is determined by the Call status. The Call status can be divided into five types: ACTIVE, HOLDING, DIALING, ALERTING, INCOMING, WAITINGWhen the MO process is initiated and the other party is not connected, the Call status is DIALING. How is the DIALING status reflected on the interface? How does InCallActivity know the status of the current Call? If you have read the MT process, you must know that the MT process actually includes a change in the Call status and transmits the Call status from the bottom to the upper layer. The DIALING status also comes from the bottom layer, therefore, the entire process is similar to MT and divided into three parts: Telephony framework, TeleService, and InCallUI, for example:


Through the preceding analysis, we know that all status changes are initiated by the underlying Modem and the related status information is fed back to the RILJ at the Framework layer. The upper layer interacts with Modem through the AT command. For more information about AT, see here and here. This article mainly introduces the display update of InCallActivity, why do we mention the AT command? This should start with the source. After the user initiates the MO process, the Modem is notified to perform the Dial operation. The Modem status changes accordingly and the status change information is notified to the upper layer, therefore, some system radio logs are involved. You can see the following information about the important logs that initiate the dial-up operation:

01-01 18:11:47. 039 1061 1061 d rilj: RIL (1): [0147]> DIAL ...... 01-01 18:11:47 is omitted. 044 682 692 D use-Rlog/RLOG-AT: AT> ATD13800138000; 01-01 18:11:47. 044 682 696 I use-Rlog/RLOG-RIL: RIL_URC2_PROXY wakeup01-01 18:11:47. 044 682 692 D use-Rlog/RLOG-AT: ATD13800138000 ;...... 01-01 18:11:47 is omitted. 047 682 707 D use-Rlog/RLOG-AT: OK01-01 18:11:47. 047 682 707 D use-Rlog/RLOG-AT: AT <OK01-01 18:11:47. 047 682 707 D use-Rlog/RLOG-AT: ril_1__reader_2: OK01-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: 01-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: + CIEV: 5,101-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: 01-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: + ECPI: 1,130, 13800138000,129, 01-01 18:11:47. 047 682 707 D use-Rlog/RLOG-AT: ril_1__reader_2 Enter processLine01-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: AT <+ CIEV: 5,101-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: RIL_URC_READER: + CIEV: 5,101-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: RIL_URC_READER Enter processLine01-01 18:11:47. 047 682 707 I use-Rlog/RLOG-AT: AT read start01-01 18:11:47. 047 682 705 D use-Rlog/RLOG-RIL: Nw URC: + CIEV: 5,101-01 18:11:47. 047 682 705 E use-Rlog/RLOG-RIL: Unhandled unsolicited result code: + CIEV: 5,101-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: AT <+ ECPI: 1,130, 13800138000,129, 01-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: RIL_URC_READER: + ECPI: 1,130, 13800138000,129, 01-01 18:11:47. 047 682 692 D use-Rlog/RLOG-AT: response encoded ed on ril_1__reader_2, tid: 308646929601-01 18:11:47. 047 682 705 D use-Rlog/RLOG-AT: RIL_URC_READER Enter processLine01-01 18:11:47. 047 682 705 D use-Rlog/RLOG-RIL: Nw URC: + ECPI: 1,130, 13800138000,129 ,...... 01-01 18:11:47 is omitted. 048 1061 1274 d rilj: RIL (1): [0147] <DIAL 01-01 18:11:47. 048 1061 1274 v rilj: RIL (1): [unsl ril] <UNSOL_CALL_PROGRESS_INFO {1,130, 0, 0, 0, 0, 13800138000,129 ,}

Here is a simple analysis of important log information:

RIL(1) :[0147]> DIAL

This indicates that the DIAL request is initiated, and then the ATD is executed, that is, the AT dialing command:

01-01 18:11:47.044   682   692 D use-Rlog/RLOG-AT: AT> ATD13800138000;

We have discussed in the article "workflow analysis of Android 4.4 Kitkat Phone (iv) _ RILJ workflow analysis". You can view the matching of AT commands Based on the serial number, the meanings of ">" and "<" in Log are also mentioned, that is, ">" indicates request, and "<" indicates response, the preceding two logs can be interpreted as two request requests initiated by RILJ. According to the serial number 0147 of the first at command, we can find the corresponding response below:

01-01 18:11:47.048  1061  1274 D RILJ    :  RIL(1) :[0147]< DIAL 

This indicates that the request and response of the entire dialing have been completed, during which the Modem actively returns the following information:

01-01 18:11:47.047   682   705 D use-Rlog/RLOG-AT: AT< +ECPI: 1,130,0,0,0,0,13800138000,129,

This AT command + ECPI is added by MTK and cannot be found in the standard AT command. The specific meaning is as follows: ECPI is the abbreviation of Call Progress Information, which is used to enable/disable Call Progress Information. + ECPI: , , , , , ,[ , ], [ ]
The corresponding explanations are as follows:

The black and bold parts in the figure are msg_type currently used in MTK Android 4.4. This can be found in the comment of the handleCallProcessInfo () method in GSMCallTracker. Corresponding to this table, let's sort it out.

01-01 18:11:47.047   682   705 D use-Rlog/RLOG-AT: AT< +ECPI: 1,130,0,0,0,0,13800138000,129,

The preceding log information is as follows: Call_id: 1, call id is 1; Msg_type: 130, indicating CSMCC_CALL_ID_ASSIGN_MSG, that is, Dialing; Dir: 0, CLCC_MO_CALL, indicating the MO operation; Call_mode: 0, CLCC_VOICE_CALL, indicating normal voice dialing; Number: 138001380000 indicates the caller's number; Type: 129, National call, that is, the domestic phone number. If it is 145, it indicates the international phone number. After the Modem completes the DIAL operation, the following log is returned:

01-01 18:11:47.048  1061  1274 V RILJ    :  RIL(1) :[UNSL RIL]< UNSOL_CALL_PROGRESS_INFO {1, 130, 0, 0, 0, 0, 13800138000, 129, }

This is an UnSolicited response Message. The processing method is in RIL. java ProcessUnsolicited ()Type: UNSOL_PROGRESS_INFO. According to the previous article "Analysis of the working process of Android 4.4 Kitkat Phone (v) _ MT (incoming call) process", the ProcessUnSolicited () method will be executed in RILJ, and the corresponding type is UNSOL_PROGRESS_INFO. RIL. java transmits the processed messages to GsmCallTracker in the yyregistrants () method. HandleCallProcessInfo ()The following code defines the Call status as DIALING:

//...... Omitted part of the Code if (msgType = 132 | msgType = 6) dc. state = DriverCall. state. ACTIVE; else if (msgType = 131) dc. state = DriverCall. state. HOLDING; else if (msgType = 130 & callId! = 254) // from the log, you can see msgType = 130, call_id = 1 dc. state = DriverCall. state. DIALING; else if (msgType = 2) dc. state = DriverCall. state. ALERTING; else if (msgType = 0) {for (j = 0; j <MAX_CONNECTIONS; j ++) {if (mConnections [j]! = Null) {count ++ ;}} if (mState = PhoneConstants. state. IDLE | (count = 0 & mForegroundCall. getState () = GsmCall. state. DIALING) {/* if the 2nd condition is true, that means we make a MO call, processing ing + ECPI: 130, * then processing ing + ECPI: 133 immediately due to MT call (+ ECPI: 0) is loading ing */if (count = 0 & mForegroundCall. getState () = GsmCall. state. DIALING) log (MO/MT conflict !!); Dc. state = DriverCall. State. INCOMING;} else dc. state = DriverCall. State. WAITING ;}

After the status changes NotifyPreciseCallStateChanged ()Method to initiate a response, as follows:

if ((hasNonHangupStateChanged || newRinging != null) && crssAction != CrssAction.SWAP && !(hasPendingReplaceRequest && msgType == 133)) {    log(notify precise call state changed);    mPhone.notifyPreciseCallStateChanged();}

CallManager will be called in the Observer mode later HandleMessage ()In the method, case is EVENT_PRECISE_CALL_STATE_CHANGEDThe Code is as follows:

Case EVENT_PRECISE_CALL_STATE_CHANGED ://...... partial code index = (msg. what-EVENT_PRECISE_CALL_STATE_CHANGED)/NOTIFICATION_ID_OFFSET; mPreciseCallStateRegistrantsGemini [index]. policyregistrants (AsyncResult) msg. obj); mPreciseCallStateRegistrants. policyregistrants (AsyncResult) msg. obj); handleappsswitchlock ();

Here, MTK Gemini processing, that is, dual-card processing, sends status change information to TeleService through the yyregistrants () method in the same observer mode. The entire process is as follows:

TeleService Message Processing CallManager informs TeleService of the Call status change information CallStateMonitorBy using this name, you can easily know that it is used to monitor the Call status. At the same time CallNotifierAnd CallModelerCallStateMonitor status change callback is registered. Once the Call status changes, CallNotifier and CallModeler are notified. Here, CallNotifier does not perform any major action, but updates the status of the close-range sensor to determine whether the sensor is connected. If the general rule is used for vibration, call related to the interface is in CallModeler. In CallModelerOf OnPhoneStateChanged ()Method, pass the information CallHandlerServiceProxyOf OnUpdate ()Method:

if (!ignoreUpdate()) {    if (updatedCalls.size() > 0) {        for (int i = 0; i < mListeners.size(); ++i) {            mListeners.get(i).onUpdate(updatedCalls);        }    }}

This will trigger thmanager, CallHandlerServiceProxyAnd DTMFTonePlayer OnUpdate ()Method callback. Here we can check the onUpdate () method in CallHandlerServiceProxy. For more information about the above Code, the onPhoneStateChanged method of CallModeler in native Android 4.4 does not IgnoreUpdate ()Method. This is the main purpose of MTK addition. It is used to determine whether to ignore this interface update. It is used to automatically reject incoming calls and quickly stop the phone that is ringing. The Code is as follows:

    /*     * The function to judge whether should skip update calls to InCallUI,     * for auto reject case, or quick hang up ringing case.     * When 1A + 1R, if ringing call is hanged up while query(ringtone),     * CallNotifier will not notify InCallUI the onIncoming(), then we should ignore update calls to InCallUI;     * or will show callcard with ringing call information but no AnswerFragment shown.     */    private boolean ignoreUpdate() {        boolean shouldIgnore = false;        final boolean hasActiveFgCall = mCallManager.hasActiveFgCall();        final boolean hasActiveBgCall = mCallManager.hasActiveBgCall();        shouldIgnore = (hasActiveFgCall || hasActiveBgCall) && PhoneGlobals.getInstance().notifier.hasPendingCallerInfoQuery();        Log.i(TAG, ignoreUpdate()... shouldIgnore:  + shouldIgnore);        return shouldIgnore;    }

The Code clearly shows that when the CallerInfo query is not completed HasPendingCallerInfoQuery ()If the return value is true, this interface update is ignored.
In the onUpdate () method of CallHandlerServiceProxy, The bindService operation is executed first, that is, to establish a connection with InCallUI. The Code is as follows:

@ Overridepublic void onUpdate (List
          
           
CILS) {synchronized (mServiceAndQueueLock) {if (mCallHandlerServiceGuarded = null) {// set the update type to METHOD_UPDATE enqueueUpdate (); return ;}}// execute the update processUpdate (CILS );}
          

Update types include: QueueParams. METHOD_INCOMING: The update type is INCOMING; QueueParams. METHOD_UPDATE: The UPDATE type is UPDATE; QueueParams. METHOD_DISCONNECT: The update type is DISCONNECT; QueueParams. METHOD_VT_DIAL_SUCCESS: The update type is VT_DIAL_SUCCESS. The call to the video screen is successfully dial-up; QueueParams. METHOD_VT_SETTING_PARAMS: The update type is VT_SETTING_PARAMS. You can set the call parameters for the video; QueueParams. METHOD_VT_STATE_CHANGE: The update type is VT_STATE_CHANGE, and the call status on the video screen changes; QueueParams. METHOD_UPDATE_RECORD_STATE: The update type is UPDATE_RECORD_STATE. It is a call recording;
Android native only has the first three types, which are added by MTK later. Then pass SetupServiceConnection ()Method to establish a connection with CallHandlerService of InCallUI. OnServiceConnected ()Method to call OnCallHandlerServiceConnected ()Method, and continue calling in this method ProcessQueue ()Method, and then call the final jump method, that is ProcessUpdate (). You may have questions, OnUpdate ()Method ProcessUpdate ()When will this method be called? When the Dial operation is performed for the first time, TeleService and InCallUI have not yet established a contact. Therefore, bindService is required. After the connection is established successfully, subsequent updates will be called directly. OnUpdate ()Method ProcessUpdate ()After this call, the execution interface display and update will jump to InCallUI. The entire process is as follows: InCallUI display/update ProcessUpdate ()The method is called using AIDL. MCallHandlerServiceGuarded. onUpdate (), And finally jump to InCallUI CallHandlerService. onUpdate ()The Code is as follows:

@ Overridepublic void onUpdate (List
          
           
Cballs) {try {Log. I (TAG, onUpdate: + cballs); // Note: The type here is ON_UPDATE_MULTI_CALL mMainHandler. sendMessage (mMainHandler. obtainMessage (ON_UPDATE_MULTI_CALL, CILS);} catch (Exception e) {Log. e (TAG, Error processing onUpdate () call ., e );}}
          

It is strange that the type is ON_UPDATE_MULTI_CALL, And the ON_UPDATE_CALL type also exists in the Code. This is google's native version. MTK has not been changed and I don't know what it means. Next, continue to jump CallListMedium NotifyListenersOfChange ()Method:

    /**     * Sends a generic notification to all listeners that something has changed.     * It is up to the listeners to call back to determine what changed.     */    private void notifyListenersOfChange() {        for (Listener listener : mListeners) {            listener.onCallListChange(this);        }    }

The listener callback will be executed here, respectively in AnswerPresenterAnd InCallPresenter. CallList is only responsible for notifying the listener of status changes. The listener determines whether to process the changes. The AnswerPresenter can only process the data in the incoming mode. InCallPresenterOf OnCallListChange ()Method:

@ Override public void onCallListChange (CallList callList) {if (callList = null) {return;} InCallState newState = getPotentialStateFromCallList (callList ); // determine whether to display or disable InCallActivity newState = startOrFinishUi (newState );//...... omitted code}

This will jump StartOrFinishUi ()For the first time. InCallActivityInterface. StartActivity ()InCallActivity is started, and the display process of the entire InCallActivity interface is over. Subsequent Modem-side status changes will be passed to InCallPresenter according to this process, and the InCallPresenter will start/Close the interface to respond to different States. The entire process is as follows:

Summary in Android 4.2, the interface is called after placeCall is returned, but in Android 4.4, the display of the interface is completely dependent on the status information returned by Logic because of the separation of UI and Logic. The display and update processes of InCallActivity are similar to those of the MT process in general: Telephony framework, TeleService, InCallUI. At last, I need to mention that What should I do if I want to actively display or update the InCallActivity interface? In CallModeler. javaThere is Updatecballs ()Of PublicYou can call the updatecall() method to display and update the InCallActivity interface by constructing the CallModeler object. The Code is as follows:

    public void updateCalls() {        final List
          
            updatedCalls = Lists.newArrayList();        doUpdate(true, updatedCalls);        if (!ignoreUpdate()) {            if (updatedCalls.size() > 0) {                for (int i = 0; i < mListeners.size(); ++i) {                    mListeners.get(i).onUpdate(updatedCalls);                }            }        }    }
          

Note: This method is added by MTK. The native AOSP does not. If you want to use it, you can add it in this way.
Image download point: Here's the AT command introduction point: here