An analysis of the workflow of Android 4.4 Kitkat phone (vi) __incallactivity display update process

<span id="Label3"></p><br><strong><strong><span style="font-size:14px; color:#ff0000">This article is from Http://blog.csdn.net/yihongyuelan reprint please be sure to indicate the source</span></strong></strong><br><span style="font-size:16px"><strong><strong>This code is based on the MTK platform Android 4.4 as the analysis object, and Google native Aosp a little difference, please read the Reader.</strong><p><strong></strong></p></strong><p><p><strong></strong><span style="font-size:16px"><strong><br></strong></span>Predecessor Article: "Android 4.4 Kitkat Phone Workflow Analysis (a) __ Summary and Learning plan"<br></p></p><p><p>An analysis of the work flow of Android 4.4 Kitkat phone (II) __ui structure</p></p><p><p>An analysis of the workflow of Android 4.4 Kitkat phone (iii) __mo (power Off) Process<br></p></p><p><p>An analysis of the work flow of Android 4.4 Kitkat phone (iv) __rilj workflow<br></p></p><p><p>An analysis of the workflow of Android 4.4 Kitkat phone (v) __mt (incoming call) Process</p></p>Overview of the previous five articles, the MO/MT process of Android 4.4 is linked Together. The same time includes a simple analysis of the UI structure, as well as Rilj workflow Analysis.        This and perhaps about the phone article, mainly on the front mo/mt main Line of the supplement and description, in order to intact the entire MO/MT process. Throughout the analysis of the MO/MT process, a lot of detail was omitted, and after figuring out the whole mo/mt, there were some questions. So I intend to continue to analyze some of the missing details. The cause of this article is very easy, is to know how incallactivity is displayed and updated, through analysis found.        Now Android 4.4 Interface update is also from the modem state changes initiated, and does not directly update the display interface as Ever. intuitively, when the user presses the dial key, it immediately displays the calling interface, which is Incallactivity. In Android 4.2, This interface is called incallscreen, which is mentioned earlier in this Article. The Incallscreen is displayed through the upper Call.<p><p></p></p><p><p>And in Android 4.4. Incallactivity's display is determined by the call state, which can be divided into 6 types:<strong>active</strong>,<strong>HOLDING</strong>,<strong>dialing</strong>,<strong>alerting </strong>,<strong>INCOMING</strong>,<strong>waiting</strong>. When the MO process is initiated and the other party has not been connected to this Period.        The status of call is Dialing. How does this dialing state react to the interface? How does incallactivity know the status of the current call? Assuming that there are children's shoes that have seen the Mt process, the MT process actually includes changes to the call state and is passed from the bottom to the upper layer, and the dialing state is fed back from the BOTTOM. So the whole process is similar to MT and is divided into three parts: Telephony framework, teleservice, incallui. For example, With:<br></p></p><p><p>watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvewlob25nexvlbgfu/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/center "><br><br>The Telephony framework receives processing feedback through the previous analysis we KNOW. All state changes are initiated by the underlying modem, and the relevant state is fed back to the Rilj of the framework Layer. The upper layer interacts with the modem via the at command, and some introductory information about at is here and here and here, this article mainly introduces the display update of incallactivity, then why does it refer to the at command?        This has to start at the Source. After the user initiates the MO process. Tell the modem to run the Dial Operation. At this point the state of the modem will change, and the status change information to the upper layer, so here will be related to some of the System's radio log, can be seen to initiate the dial operation of the relevant important log information such as the Following:</p></p><pre code_snippet_id="310183" snippet_file_name="blog_20140424_1_361020" name="code" class="plain">01-01 18:11:47.039 1061 1061 D rilj:ril (1):[0147]> DIAL ... Omit 01-01 18:11:47.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; Omit 01-01 18:11:47.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_cmd_reader_2:ok01-01 18:11:47.047 682 705 D use-rlog/rlog-at:01-01 1 8: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.0 682 705 D use-rlog/rlog-at: +ecpi:1,130,0,0,0,0, "13800138000", 129, "" 01-01 18:11:47.047 682 707 D Use-Rlog/RLOG -at:ril_cmd_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 1 8: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:unhandl Ed unsolicited result code: +ciev:5, 101-01 18:11:47.047 682 705 D use-rlog/rlog-at:at< +ecpi:1,130,0,0,0,0, "138 00138000 ", 129," "01-01 18:11:47.047 682 705 D use-rlog/rlog-at:ril_urc_reader:+ecpi:1,130,0,0,0,0," 13800138000 ", 129, "" 01-01 18:11:47.047 682 692 D Use-rlog/rlog-at:response received on ril_cmd_reader_2, tid:308646929601-01 18:11:47.0 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,0,0,0,0, "13800138000", 129, "" ... Omit 01-01 18:11:47.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,}</pre>Here is a simple analysis of important log information:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_2_612191" name="code" class="plain"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_2_612191" name="code" class="plain">RIL (1):[0147]> DIAL</pre></pre>This indicates that the dial request was Initiated. Immediately after the run ATD is at the Dial command:<br><pre code_snippet_id="310183" snippet_file_name="blog_20140424_3_6610219" name="code" class="plain"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_3_6610219" name="code" class="plain">01-01 18:11:47.044 682 692 D use-rlog/rlog-at:at> ATD13800138000;</pre></pre>We have said in the "Android 4.4 Kitkat phone workflow Analysis (iv) __rilj workflow Brief analysis" Article. Ability to view the pairing of the at command according to the serial Number. At the same time, the meaning of ">" and "what" in log is also Mentioned. That is, ">" means request, "" "means response, The above two log information can be interpreted as Rilj initiated two request Requests.<p><p></p></p><p><p>According to the serial number "0147" of the first at instruction, we can find the corresponding response in the following way:</p></p><pre code_snippet_id="310183" snippet_file_name="blog_20140424_4_6544963" name="code" class="plain"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_4_6544963" name="code" class="plain">01-01 18:11:47.048 1061 1274 D Rilj : </pre></pre>This indicates that the entire dial-up request and response have been completed, during which the modem actively returned the following information:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_6_9969480" name="code" class="plain"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_6_9969480" name="code" class="plain">01-01 18:11:47.047 682 705 D use-rlog/rlog-at:at< +ecpi:1,130,0,0,0,0, "13800138000", 129, ""</pre></pre>The at directive +ECPI is a MTK addition. Cannot be queried in the standard at directive, with detailed meanings such as the following: ECPI is the abbreviation for Call Progress information to enable/disable call Progress Information. +ecpi:<call_id>,<msg_type>,<is_ibt>,<is_tch>,<dir>,<call_mode>,[<number >,<type>],[<disc_cause>]<br>The corresponding explanations are for example:<br><p><p>watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvewlob25nexvlbgfu/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/center "><br>The black bold portion of the figure is now available in the MTK Android 4.4 msg_type, which can be found in the gaze of the Handlecallprocessinfo () method in Gsmcalltracker.</p></p><p><p>we'll Comb the table accordingly.</p></p><pre code_snippet_id="310183" snippet_file_name="blog_20140424_6_9969480" name="code" class="plain"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_6_9969480" name="code" class="plain">01-01 18:11:47.047 682 705 D use-rlog/rlog-at:at< +ecpi:1,130,0,0,0,0, "13800138000", 129, ""</pre></pre>The above log important information such as the Following:<strong><strong>call_id</strong></strong>: 1. Call ID is 1;<strong><strong>Msg_type</strong></strong>: 130, indicating csmcc_call_id_assign_msg, that is, dialing;<strong><strong>dir</strong></strong>: 0,clcc_mo_call, indicates MO operation;<strong><strong>Call_mode</strong></strong>: 0,clcc_voice_call, indicates normal voice dialing;<strong><strong></strong> number</strong>: 138001380000, indicates the calling Number.<strong><strong>type</strong></strong>: 129,national call, Home Phone. The assumption is that 145 represents an international Call. After the modem is finished dial Operation. The following log is returned immediately:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_7_8683507" name="code" class="plain"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_7_8683507" name="code" class="plain">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,}</pre></pre>This is a unsolicited response message that is handled by Ril.java<strong><strong>processunsolicited ()</strong></strong>, the type is: unsol_progress_info. Based on the previous "Android 4.4 Kitkat phone workflow analysis (v) __MT (incoming call) process analytics" to know, here will start running the processunsolicited () method in rilj, and the corresponding type is unsol_progress _info.<p><p></p></p><p><p>Ril.java passes the processed message through notifyregistrants () to Gsmcalltracker. In Gsmcalltracker's <strong>handlecallprocessinfo ()</strong> method, You can see how the call state is defined as Dialing. The code is as Follows:</p></p><pre code_snippet_id="310183" snippet_file_name="blog_20140424_8_6633383" name="code" class="java">//... ... Omit part of the code if (msgtype = = | | | msgtype = = 6) Dc.state = Drivercall.state.active;else if (msgtype = = 131) Dc.state = Dri Vercall.state.holding;else if (msgtype = = && callid! = 254)//can be seen from log 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, which means we make a MO call, receiving +ecpi:130, * then receiving +ecpi:133 Immediately due to MT call (+ecpi:0) is receiving*/if (count = = 0 && mforegroundcall.getstate () = = Gsmcall.s Tate. Dialing) Log ("MO/MT conflict!!"); Dc.state = DriverCall.State.INCOMING; } Else Dc.state = DRIVERCALL.STATE.Waiting;} </pre>When the state changes, it passes through the Gsmphone<strong><strong>notifyprecisecallstatechanged ()</strong></strong>Method initiates a Response. For example, the Following:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_9_4234596" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_9_4234596" name="code" class="java">If (hasnonhangupstatechanged | | newringing! = null) && crssaction! = Crssaction.swap &&! ( Haspendingreplacerequest && Msgtype = = 133) { log ("notify precise call State changed"); Mphone.notifyprecisecallstatechanged ();}</pre></pre>The CallManager will then be called through the Observer pattern Mode.<strong><strong>handlemessage ()</strong></strong>method, the case is<strong><strong>event_precise_call_state_changed</strong></strong>。 The code is as Follows:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_10_6328930" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_10_6328930" name="code" class="java">Case event_precise_call_state_changed://... Omit part of the code index = (msg.what-event_precise_call_state_changed)/notification_id_offset; Mprecisecallstateregistrantsgemini[index].notifyregistrants ((AsyncResult) msg.obj); Mprecisecallstateregistrants.notifyregistrants ((AsyncResult) msg.obj); Handle3gswitchlock ();</pre></pre>There will be MTK Gemini processing, that is, dual sim processing, through the same observer mode to the state change information through the Notifyregistrants () method to send to Teleservice. The entire process is for example With:<br><br>Teleservice Message Processing CallManager The call status change information to Teleservice.<strong><strong>Callstatemonitor</strong></strong>。 By this name it is very easy to know that it is used to monitor the call State.<p><p></p></p><p><p>At the same time <strong>callnotifier</strong> and <strong>Callmodeler</strong> both registered the Callstatemonitor status change callback. Callnotifier and Callmodeler are notified once the call status Changes. Here Callnotifier did not do any big action, just update the state of the proximity sensor, infer whether to connect the assumption that the vibration of the class.        The interface-related calls are in Callmodeler. In the <strong>onphonestatechanged ()</strong> method of the <strong>Callmodeler</strong> . Pass the information to <strong>Callhandlerserviceproxy</strong> 's <strong>onUpdate ()</strong> method:</p></p><pre code_snippet_id="310183" snippet_file_name="blog_20140424_11_690756" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_11_690756" name="code" class="java">If (!ignoreupdate ()) { if (updatedcalls.size () > 0) {for (int i = 0; i < mlisteners.size (); ++i) { MLIs Teners.get (i). onUpdate (updatedcalls);}} </pre></pre>This will trigger bluetoothmanager,<strong><strong>Callhandlerserviceproxy</strong></strong>, Dtmftoneplayer in three Classes.<strong><strong>onUpdate ()</strong></strong>Method callback, Here we look at the callhandlerserviceproxy in the OnUpdate () method can Be. For the above code to say a few more words, native Android 4.4, Callmodeler's onphonestatechanged method did not<strong><strong>ignoreupdate ()</strong></strong>method, which is the main purpose of the MTK increase is to infer whether to ignore this interface Update. For self-rejection and high-speed hanging up the ringing of the phone two kinds of scenes. The code is as Follows:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_12_6373140" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_12_6373140" name="code" class="java"> */* the Func tion to judge whether should skip update calls to incallui, * for auto reject case, or quick hang up ringing case. * When 1 A + 1R, if ringing call was hanged up while query (ringtone), * Callnotifier would not notify Incallui the Onin Coming (), then we should ignore update calls to incallui; * or would 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; }</pre></pre>Through the code can know very clearly, when Callerinfo no query is completed<strong><strong>haspendingcallerinfoquery ()</strong></strong>Returns true to ignore this interface Update.<br>In Callhandlerserviceproxy's OnUpdate () method, The first thing to do is to run the Bindservice operation, which is to establish a connection with Incallui. The code is as Follows:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_13_3243221" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_13_3243221" name="code" class="java">@Overridepublic void OnUpdate (list<call> calls) { synchronized (mserviceandqueuelock) { if ( mcallhandlerserviceguarded = = Null) { //set update type method_update enqueueupdate (calls); Establish a connection with Callhandlerservice setupserviceconnection (); return; } } Run Update processupdate (calls);}</pre></pre>The update type contains:<strong><strong>queueparams.method_incoming</strong></strong>: The update type is incoming;<strong><strong>queueparams.method_update</strong></strong>: The update type is update;<strong><strong>Queueparams.method_disconnect</strong></strong>: The update type is Disconnect.<strong><strong>queueparams.method_vt_dial_success</strong></strong>: The update type is vt_dial_success and the video call is dialed successfully.<strong><strong>Queueparams.method_vt_setting_params</strong></strong>: The update type is VT_SETTING_PARAMS. Video Call set the number of parameters;<strong><strong>Queueparams.method_vt_state_change</strong></strong>: The update type is vt_state_change and the video call status Changes.<strong><strong>queueparams.method_update_record_state</strong></strong>: Update type is update_record_state, call recording;<br>Android native only has the previous three types, followed by MTK Join. Followed by<strong><strong>setupserviceconnection ()</strong></strong>method to establish a connection with the Incallui callhandlerservice. It is important to note that when a connection is established, it is called<strong><strong>onserviceconnected ()</strong></strong>Method. Further calls<strong><strong>oncallhandlerserviceconnected ()</strong></strong>method, and continue calling in the method<strong><strong>Processqueue ()</strong></strong>method, which is then called to the last jump method<strong><strong>processupdate ()</strong></strong>。<p><p></p></p><p><p>Here you may have questions about when the <strong>processupdate ()</strong> method in the<strong>onUpdate ()</strong> method is Called. Teleservice and Incallui have not yet been contacted when the dial operation was first Run. therefore, we need to Bindservice First. When a connection is established, a possibly update calls the <strong>processupdate ()</strong> method in the <strong>onUpdate ()</strong> method directly. After this call, it jumps to the display and update of the run interface in Incallui. The entire process is, for example, Incallui display/update in the Teleservice <strong>processupdate ()</strong> method. Call <strong>mcallhandlerserviceguarded.onupdate ()</strong>using the Aidl method. finally, jump to the <strong>callhandlerservice.onupdate ()</strong> method in incallui, where the code such as the Following:</p></p><pre code_snippet_id="310183" snippet_file_name="blog_20140424_14_6417350" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_14_6417350" name="code" class="java">@Overridepublic void onUpdate (list<call> calls) { try { log.i (TAG, "onUpdate:" + calls); Note: the type here is On_update_multi_call mmainhandler.sendmessage (mmainhandler.obtainmessage (on_update_multi_call, calls)); } Catch (Exception e) { log.e (TAG, "Error processing onUpdate () call.", e); }}</pre></pre>The very strange thing here is That. The type is on_update_multi_call, and there are on_update_call types in the Code. This is a native of Google. MTK has not changed. Do not know what is the Intention. Continue to jump to the following<strong><strong>calllist</strong></strong>In<strong><strong>Notifylistenersofchange ()</strong></strong>Method:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_15_6875481" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_15_6875481" name="code" class="java"> /** * Sends a generic notification to all listeners this something has Changed. * It's up to the Listeners-to-determine what Changed. */ private void Notifylistenersofchange () {for (Listener listener:mlisteners) { Listener.oncalllistchange (this); } }</pre></pre>This will run the listener callback, respectively, in the<strong><strong>Answerpresenter</strong></strong>And<strong><strong>Incallpresenter</strong></strong>In Calllist is only responsible for notifying the state changes to listener, and whether or not they are handled is up to Listener. Answerpresenter is only handled when Incoming. So Here's what you should see<strong><strong>Incallpresenter</strong></strong>Of<strong><strong>Oncalllistchange ()</strong></strong>Method:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_16_8969815" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_16_8969815" name="code" class="java"> @Override public void Oncalllistchange (calllist calllist) { if (calllist = = Null) { return; } Incallstate newstate = getpotentialstatefromcalllist (calllist); Here to infer whether to show/close incallactivity newstate = Startorfinishui (newstate); //... ... Omit part of Code }</pre></pre>This will jump to<strong><strong>Startorfinishui ()</strong></strong>Because it is the first time to start<strong><strong>incallactivity</strong></strong>Interface. Will finally pass<strong><strong>startactivity ()</strong></strong>The way to start incallactivity, the entire incallactivity interface shows that the process is over. Perhaps the modem side of the state changes in accordance with the process passed to the incallpresenter, by the Incallpresenter to respond to different states need to start/close Interface. The entire process is for example With:<br><br>Summary in Android 4.2 The interface display is called after the Placecall is returned, but in Android 4.4. Because of the separation of the UI and logic, the display of the interface depends entirely on the state information returned by LOGIC. The display and update process on incallactivity is similar to the MT process as a whole, and is divided into:<strong><strong>Telephony Framework</strong></strong>、<strong><strong>Teleservice</strong></strong>、<strong><strong>Incallui</strong></strong>。 finally, a point needs to be raised. Suppose you want to actively display or update the incallactivity interface, what should I do? In<strong><strong>Callmodeler.java</strong></strong>Has a<strong><strong>updatecalls ()</strong></strong>Of<strong><strong></strong> public</strong>Method can be used to construct the Callmodeler object to invoke the Updatecalls () method to complete the display and update of the incallactivity interface, such as the following code:<pre code_snippet_id="310183" snippet_file_name="blog_20140424_17_6919692" name="code" class="java"><pre code_snippet_id="310183" snippet_file_name="blog_20140424_17_6919692" name="code" class="java"> public void Updatecalls () { final list<call> updatedcalls = lists.newarraylist (); DoUpdate (true, updatedcalls); If (!ignoreupdate ()) { if (updatedcalls.size () > 0) {for (int i = 0; i < mlisteners.size (); ++i) { MLIs Teners.get (i). onUpdate (updatedcalls);}}} </pre></pre>Note: This method is MTK itself to join, the native AOSP did not, the false idea uses can also imitate this way to Join.<br><span style="font-size:14px"><span style="font-size:14px">Picture Download point: here</span></span><span style="font-size:14px">The at <span style="font-size:14px">command describes the document Point: here</span></span> <p><p>An analysis of the workflow of Android 4.4 Kitkat phone (vi) __incallactivity display update process</p></p></span></span>