本文来自http://blog.csdn.net/yihongyuelan 转载请务必注明出处
本文代码以MTK平台Android 4.4为分析对象,与Google原生AOSP有些许差异,请读者知悉。
前置文章:
《 Android 4.4 Kitkat Phone工作流程浅析(一)__概要和学习计划 》《Android 4.4 Kitkat Phone工作流程浅析(二)__UI结构分析》
《Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析》
《Android 4.4 Kitkat Phone工作流程浅析(四)__RILJ工作流程简析》
《Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析》
概述
前面五篇文章,将Android 4.4 的MO/MT流程衔接了起来,同时包括了UI结构简单分析,以及RILJ的工作流程分析。本篇以及后续关于Phone的文章,主要是对前面MO/MT主线的补充和说明,用以完善整个MO/MT流程。
在整个MO/MT流程的分析过程中,遗漏了很多细枝末节,在弄清楚整个MO/MT的始末之后,便发现有一些疑问疑问,因此打算陆陆续续分析一些遗漏的细节。本篇文章的发起缘由很简单,就是想知道InCallActivity是如何显示和更新的,通过分析后发现,现在Android 4.4 的界面更新也是从Modem状态改变发起,并不像以前那样直接更新显示界面。
从直观上来讲,当用户按下拨号键之后会立刻显示正在呼叫的界面,也就是InCallActivity。在Android 4.2中,这个界面叫做InCallScreen这一点前面的文章已经有提过,InCallScreen会通过上层调用显示出来。而在Android 4.4中,InCallActivity的显示则是由Call状态来决定的,Call的状态可以分为6种:
ACTIVE、
HOLDING、
DIALING、
ALERTING、
INCOMING、
WAITING,当发起MO流程并且对方还未接通这段时间,Call的状态是DIALING。
这个DIALING状态是如何反应到界面上的呢?InCallActivity是如何知道当前Call的状态的呢?如果有看过MT流程的童鞋肯定知道,MT流程实际上就包含了Call状态的改变并从底层一路传递到上层,而DIALING的状态也是从底层反馈来的,因此整个流程和MT类似,分为三个部分:Telephony framework、TeleService、InCallUI,如下图:
Telephony Framework接收处理反馈
通过前面的分析我们知道,所有的状态改变都是由底层Modem发起的,并将相关状态信息反馈到framework层的RILJ中。上层通过AT指令与Modem进行交互,关于AT的一些介绍信息可以看
这里和
这里以及
这里,本文主要介绍的是InCallActivity的显示更新,那为什么会提到AT指令呢?这得从源头说起。
当用户发起MO流程之后,告诉Modem执行Dial操作,此时Modem的状态就会随之改变,并将状态改变信息通知到上层,因此这里会涉及到一些系统的radio log,可以看到发起拨号操作的相关重要log信息如下:
- 01-01 18:11:47.039 1061 1061 D RILJ : RIL(1) :[0147]> DIAL
- ... ...省略
- 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 wakeup
- 01-01 18:11:47.044 682 692 D use-Rlog/RLOG-AT: ATD13800138000;
- ... ...省略
- 01-01 18:11:47.047 682 707 D use-Rlog/RLOG-AT: OK
- 01-01 18:11:47.047 682 707 D use-Rlog/RLOG-AT: AT< OK
- 01-01 18:11:47.047 682 707 D use-Rlog/RLOG-AT: RIL_CMD_READER_2:OK
- 01-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, 1
- 01-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,0,0,0,0,"13800138000",129,""
- 01-01 18:11:47.047 682 707 D use-Rlog/RLOG-AT: RIL_CMD_READER_2 Enter processLine
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-AT: AT< +CIEV: 5, 1
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-AT: RIL_URC_READER:+CIEV: 5, 1
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-AT: RIL_URC_READER Enter processLine
- 01-01 18:11:47.047 682 707 I use-Rlog/RLOG-AT: AT read start
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-RIL: Nw URC:+CIEV: 5, 1
- 01-01 18:11:47.047 682 705 E use-Rlog/RLOG-RIL: Unhandled unsolicited result code: +CIEV: 5, 1
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-AT: AT< +ECPI: 1,130,0,0,0,0,"13800138000",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:3086469296
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-AT: RIL_URC_READER Enter processLine
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-RIL: Nw URC:+ECPI: 1,130,0,0,0,0,"13800138000",129,""
- ... ...省略
- 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, }
- RIL(1) :[0147]> DIAL
- 01-01 18:11:47.044 682 692 D use-Rlog/RLOG-AT: AT> ATD13800138000;
- 01-01 18:11:47.048 1061 1274 D RILJ : RIL(1) :[0147]< DIAL
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-AT: AT< +ECPI: 1,130,0,0,0,0,"13800138000",129,""
ECPI即Call Progress Information的缩写,用于开启/禁用Call Progress Information。
+ECPI:<call_id>,<msg_type>,<is_ibt>,<is_tch>,<dir>,<call_mode>,[<number>,<type>],[<disc_cause>]
对应的解释如下图:
图中黑色加粗部分为目前MTK Android 4.4有使用的msg_type,这一点可以在GSMCallTracker中的handleCallProcessInfo()方法的注释中找到。对应着这个表我们来梳理一下
- 01-01 18:11:47.047 682 705 D use-Rlog/RLOG-AT: AT< +ECPI: 1,130,0,0,0,0,"13800138000",129,""
call_id:1,call id 为1;
msg_type:130,表示CSMCC_CALL_ID_ASSIGN_MSG,也就是Dialing;
dir:0,CLCC_MO_CALL,表示MO操作;
call_mode:0,CLCC_VOICE_CALL,表示普通语音拨号;
number:138001380000,表示主叫号码;
type:129,National call,也就是本国电话,如果是145则表示国际电话;
在Modem完成DIAL操作之后,紧接着返回了以下log:
- 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, }
根据前文《
Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析》可以知道,这里会开始在RILJ中执行ProcessUnSolicited()方法,并且对应类型为UNSOL_PROGRESS_INFO。RIL.java将处理之后的消息通过notifyRegistrants()的方式传递给GsmCallTracker,在GsmCallTracker的
handleCallProcessInfo()方法中可以看到是如何定义Call状态为DIALING的,代码如下:
- //... ... 省略部分代码
- 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)
- //从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, that 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.State.DIALING)
- log("MO/MT conflict!!");
- dc.state = DriverCall.State.INCOMING;
- }
- else
- dc.state = DriverCall.State.WAITING;
- }
- if ((hasNonHangupStateChanged || newRinging != null) && crssAction != CrssAction.SWAP && !(hasPendingReplaceRequest && msgType == 133)) {
- log("notify precise call state changed");
- mPhone.notifyPreciseCallStateChanged();
- }
- case EVENT_PRECISE_CALL_STATE_CHANGED:
- //... ...省略部分代码
- index = (msg.what - EVENT_PRECISE_CALL_STATE_CHANGED) / NOTIFICATION_ID_OFFSET;
- mPreciseCallStateRegistrantsGemini[index].notifyRegistrants((AsyncResult) msg.obj);
- mPreciseCallStateRegistrants.notifyRegistrants((AsyncResult) msg.obj);
- handle3GSwitchLock();
TeleService消息处理
CallManager将Call状态改变的信息告诉TeleService中的
CallStateMonitor,通过这个名字可以很容易知道它是用来监视Call状态的。同时
CallNotifier和
CallModeler均注册了CallStateMonitor的状态改变回调,一旦Call状态改变便会通知CallNotifier和CallModeler。这里CallNotifier并没有做什么大的动作,只是更新了近距离感应器的状态,判断是否接通如果接通则震动这类,跟界面相关的调用则在CallModeler中。
在
CallModeler的
onPhoneStateChanged()方法中,将信息传递到
CallHandlerServiceProxy的
onUpdate()方法中:
- if (!ignoreUpdate()) {
- if (updatedCalls.size() > 0) {
- for (int i = 0; i < mListeners.size(); ++i) {
- mListeners.get(i).onUpdate(updatedCalls);
- }
- }
- }
- /*
- * 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;
- }
在CallHandlerServiceProxy的onUpdate()方法中,首先会去执行bindService操作也就是与InCallUI建立联系,代码如下:
- @Override
- public void onUpdate(List<Call> calls) {
- synchronized (mServiceAndQueueLock) {
- if (mCallHandlerServiceGuarded == null) {
- //设置更新类型为METHOD_UPDATE
- enqueueUpdate(calls);
- //与CallHandlerService建立连接
- setupServiceConnection();
- return;
- }
- }
- //执行更新
- processUpdate(calls);
- }
QueueParams.METHOD_INCOMING:更新类型为INCOMING;
QueueParams.METHOD_UPDATE:更新类型为UPDATE;
QueueParams.METHOD_DISCONNECT:更新类型为DISCONNECT;
QueueParams.METHOD_VT_DIAL_SUCCESS:更新类型为VT_DIAL_SUCCESS,视屏通话拨号成功;
QueueParams.METHOD_VT_SETTING_PARAMS:更新类型为VT_SETTING_PARAMS,视屏通话设置参数;
QueueParams.METHOD_VT_STATE_CHANGE:更新类型为VT_STATE_CHANGE,视屏通话状态改变;
QueueParams.METHOD_UPDATE_RECORD_STATE:更新类型为UPDATE_RECORD_STATE,通话录音;
Android原生只有前面三种类型,后面均由MTK添加。
Android原生只有前面三种类型,后面均由MTK添加。
紧接着通过
setupServiceConnection()方法与InCallUI的CallHandlerService建立连接,这里需要注意在建立连接成功后会调用
onServiceConnected()方法,进一步调用
onCallHandlerServiceConnected()方法,并在该方法中继续调用
processQueue()方法,进而调用到最终跳转方法即
processUpdate()。
这里大家可能会有疑问,
onUpdate()方法中的
processUpdate()方法什么时候调用呢?在第一次执行Dial操作时,TeleService和InCallUI还没有建立联系,因此需要先bindService,等连接建立成功后,后续的更新则会直接调用
onUpdate()方法中的
processUpdate()方法,经过如此调用之后便会跳转到InCallUI中执行界面显示与更新。整个流程如下图:
InCallUI显示/更新
在TeleService的
processUpdate()方法中,使用AIDL的方式调用
mCallHandlerServiceGuarded.onUpdate(),最终跳转到InCallUI中的
CallHandlerService.onUpdate()方法中,代码如下:
- @Override
- public void onUpdate(List<Call> calls) {
- try {
- Log.i(TAG, "onUpdate: " + calls);
- //注意:这里的类型是ON_UPDATE_MULTI_CALL
- mMainHandler.sendMessage(mMainHandler.obtainMessage(ON_UPDATE_MULTI_CALL, calls));
- } catch (Exception e) {
- Log.e(TAG, "Error processing onUpdate() call.", e);
- }
- }
后面继续跳转到
CallList中
notifyListenersOfChange()方法:
- /**
- * 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);
- }
- }
- @Override
- public void onCallListChange(CallList callList) {
- if (callList == null) {
- return;
- }
- InCallState newState = getPotentialStateFromCallList(callList);
- //这里去判断是否显示/关闭InCallActivity
- newState = startOrFinishUi(newState);
- //... ...省略部分代码
- }
小结
在Android 4.2中界面显示是在placeCall返回之后调用的,但到了Android 4.4中,因为UI和Logic的分离,界面的显示完全依赖于Logic返回的状态信息。关于InCallActivity的显示和更新流程总体上和MT流程是类似的即分为:
Telephony framework、
TeleService、
InCallUI。
最后需要提一点,如果想主动显示或者更新InCallActivity界面,应该怎么办呢?在
CallModeler.java中有一个
updateCalls()的
public方法,可以通过构造CallModeler的对象来调用updateCalls()方法完成InCallActivity界面的显示和更新,代码如下:
- 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) {
- mListeners.get(i).onUpdate(updatedCalls);
- }
- }
- }
- }