转(Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析)
来源:互联网 发布:在线视频网站cms 编辑:程序博客网 时间:2024/05/17 01:41
前置文章:
《Android 4.4 Kitkat Phone工作流程浅析(一)__概要和学习计划》《Android 4.4 Kitkat Phone工作流程浅析(二)__UI结构分析》
《Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析》
《Android 4.4 Kitkat Phone工作流程浅析(四)__RILJ工作流程简析》
概述
上一篇文章简单分析了RILJ的工作流程,实际上MTK对于RILJ的改动还是较大的,添加了很多request和respone类型。对于MT(来电)来讲,首先还是会由Modem接收到信息,然后发给RILC,RILC再发送给RILJ,并在RILJ的RILReceiver中接收到并进行处理。MTK对于Modem侧的AT指令进行一些定制,这和AOSP原生使用CLCC方式后去来电信息不同,MTK这里使用了自己添加的AT指令ECPI来反馈通话状态改变的信息。后面会针对MTK的log进行一个简单的分析,根据log来分析 MO/MT 流程,其中会涉及AT log和main log。
通过上一篇文章《Android 4.4 Kitkat Phone工作流程浅析(四)__RILJ工作流程简析》的分析,我们知道RILJ会从RILC收到Solicited和Unsolicited信息,并对之进行处理之后向上反馈。本次分析的MT(来电)流程,就属于Unsolicited信息,而信息从RILJ中的RILReceiver的run方法中开始。首先我们先看到RILJ与RILC的简单交互图,当RILJ收到RILC的Unsolicited信息时,RILReceiver开始处理。
先来看看MT(来电)的整个流程图:
通过上图可以知道,整个MT(来电)过程分为三个部分:Telephony framework、TeleService、InCallUI。来电信息通过处理并逐层传递,最终显示到界面上。界面主要包括:CallCardFragment、CallButtonFragment、AnswerFragment内容的更新。
Telephony framework处理
通过RILReceiver接收到MT(来电)信息,RILC将相关来电信息通过socket发送给RILJ,RILReceiver接收到之后进行读取并打包进行上报。整个流程如下图:
整个过程看起来比较清晰,但实际跟踪起来还是比较麻烦的,这里运用到了观察者模式也就是RegistrantList和Registrant,使用handler来传递信息。
RegistrantList消息处理
这里实际上使用的是观察者模式,即:
RegistrantList:通知者
通过add()/addUnique()、remove()方法负责添加、删除通知者,使用notifyRegistrants()方法发出通知;
Registrant:观察者
通过internalNotifyRegistrant()响应通知者发出的通知;
RegistrantList的工作流程大致如下:
(1). RegistrantList通过registerForXXX方法注册观察者Registrant的方法;
在BaseCommands.java中可以看到registerForCallProgressInfo()方法,如下:
- protected RegistrantList mCallProgressInfoRegistrants = new RegistrantList();
- //注册观察者
- public void registerForCallProgressInfo(Handler h, int what, Object obj) {
- Registrant r = new Registrant (h, what, obj);
- mCallProgressInfoRegistrants.add(r);
- }
- //取消注册观察者
- public void unregisterForCallProgressInfo(Handler h) {
- mCallProgressInfoRegistrants.remove(h);
- }
- WeakReference refH;
- int what;
- Object userObj;
- public Registrant(Handler h, int what, Object obj) {
- refH = new WeakReference(h);
- this.what = what;
- userObj = obj;
- }
- mCi.registerForCallProgressInfo(this, EVENT_CALL_PROGRESS_INFO, null);
也就是说在GsmCallTracker初始化的时候完成了注册过程。
(2). 调用notifyRegistrants触发Handler的handleMessage回调;
注册完毕之后又是如何触发的呢?我们在RIL.java的ProcessUnsolicited方法中,来电时会上报以下RIL_UNSOL_CALL_PROGRESS_INFO信息,该信息由底层上报,并执行以下方法:- mCallProgressInfoRegistrants.notifyRegistrants(new AsyncResult (null, ret, null));
- public void notifyRegistrants(AsyncResult ar){
- internalNotifyRegistrants(ar.result, ar.exception);
- }
- private synchronized void internalNotifyRegistrants (Object result, Throwable exception) {
- for (int i = 0, s = registrants.size(); i < s ; i++) {
- Registrant r = (Registrant) registrants.get(i);
- r.internalNotifyRegistrant(result, exception);
- }
- }
- public synchronized void add(Registrant r) {
- removeCleared();
- registrants.add(r);
- }
- internalNotifyRegistrant (Object result, Throwable exception) {
- Handler h = getHandler();
- if (h == null) {
- clear();
- Log.d("Registrant", "internalNotifyRegistrant(): Warning! Handler is null, it could be already GCed. ( what=" + what + ", userObj=" + userObj + ", result=" + result + ", exception=" + exception + " )");
- } else {
- Message msg = Message.obtain();
- msg.what = what;
- msg.obj = new AsyncResult(userObj, result, exception);
- h.sendMessage(msg);
- }
- }
TeleService消息处理
经过Telephony framework中的各种处理后,来电信息就传递到了TeleService中。在TeleService中会查询来电号码的信息,比如归属地,是否是已知联系人等,将这些查询到的消息保存到Connection对象中,再将其传递给InCallUI进行最后的显示。整个处理流程如下:这一块原来是放在Phone中进行处理的,在4.4中Phone一分为二,TeleService在后台负责相关数据的查询和获取,InCallUI负责取出TeleService中的数据并进行界面显示更新。这里的CallStateMonitor正如其名,用于注册监听Phone的状态改变并统一发起通知。CallNotifier和CallModeler均添加了CallStateMonitor的Listener,一旦Phone状态改变即可通过Handler的handleMessage回调到相关注册类中,并进行一些处理。
因为我们这里仅分析MT(来电)流程,其中附带的响铃以及点亮屏幕等流程这里就不详述,在来电的时候并不是直说只有EVENT_NEW_RINGING_CONNECTION,还有EVENT_PRECISE_CALL_STATE_CHANGED和EVENT_INCOMING_RING等,每一个状态对应一种处理。这些状态在CallManager中处理之后便通过CallStateMonitor进行回调处理。
startIncomingCallQuery()方法负责查询来电号码的相关信息,CallModeler将查询结果放入Connection对象中,并触发Listener的回调方法onIncoming()。CallModeler中包含了很多重要的方法,CallModeler继承自Handler,CallHandlerServiceProxy注册了其Listener,CallModeler处理完Connection之后会回调到CallHandlerServiceProxy中。
CallModeler主要对Connection进行处理,并且用Connection来标识一个通话,在代码顶部的注释中可以发现:
- /**
- * Creates a Call model from Call state and data received from the telephony
- * layer. The telephony layer maintains 3 conceptual objects: Phone, Call,
- * Connection.
- *
- * Phone represents the radio and there is an implementation per technology
- * type such as GSMPhone, SipPhone, CDMAPhone, etc. Generally, we will only ever
- * deal with one instance of this object for the lifetime of this class.
- *
- * There are 3 Call instances that exist for the lifetime of this class which
- * are created by CallTracker. The three are RingingCall, ForegroundCall, and
- * BackgroundCall.
- *
- * A Connection most closely resembles what the layperson would consider a call.
- * A Connection is created when a user dials and it is "owned" by one of the
- * three Call instances. Which of the three Calls owns the Connection changes
- * as the Connection goes between ACTIVE, HOLD, RINGING, and other states.
- *
- * This class models a new Call class from Connection objects received from
- * the telephony layer. We use Connection references as identifiers for a call;
- * new reference = new call.
- *
- * TODO: Create a new Call class to replace the simple call Id ints
- * being used currently.
- *
- * The new Call models are parcellable for transfer via the CallHandlerService
- * API.
- */
- //大致信息如下:
- //根据从Telephony framework层返回的Call状态和数据创建一个Call model。Telephony framework层包含3个概念性的对象:Phone、Call、Connection;
- //Phone包含的类型有:GSMPhone、SipPhone、CDMAPhone等,一般来讲,在一个生命周期里仅存在三种类型中的其中一种。
- //在一个生命周期中Call有三个引用:RingingCall、ForegroundCall、BackgroundCall。
- //一般来说Connection被用来表示通话。当用户拨号时便会创建Connection,其隶属于三种类型的Call。Connection的状态包含:ACTIVE、HOLD、RINGING等。
- //Modeler中的Connection对象<span style="font-family: Arial, Helvetica, sans-serif;">来自于</span><span style="font-family: Arial, Helvetica, sans-serif;">从telephony framework层,并且,使用Connection的引用来标识一个通话。</span>
- //Modeler将相关数据通过CallHandlerService传递给InCallUI。
- @Override
- public void onIncoming(Call call) {
- // 清空重链接计数.
- resetConnectRetryCount();
- synchronized (mServiceAndQueueLock) {
- if (mCallHandlerServiceGuarded == null) {
- if (DBG) {
- Log.d(TAG, "CallHandlerService not connected. Enqueue incoming.");
- }
- //设置操作类型为QueueParams.METHOD_INCOMING
- enqueueIncoming(call);
- //与InCallUI中的CallHandlerService建立连接,使用bindService
- setupServiceConnection();
- return;
- }
- }
- //第二次再处理来电信息,第一次如果没有建立连接则会先执行上面的代码
- processIncoming(call);
- }
(1). 设置界面处理类型;
因为这里是来电,因此类型为QueueParams.METHOD_INCOMING。
- enqueueIncoming(call);
- private void enqueueIncoming(Call call) {
- getQueue().add(new QueueParams(QueueParams.METHOD_INCOMING, new Call(call)));
- }
使用的是bindService来建立Service的连接。
- if (!mContext.bindService(serviceIntent, mConnection, Context.BIND_AUTO_CREATE)) {
- // This happens when the in-call package is in the middle of being installed
- Log.w(TAG, "Could not bind to default call handler service: " + serviceIntent.getComponent());
- failedConnection = true;
- }
执行上面两步之后会return,但来电信息并不是只有一次上报,因此在建立CallHandlerService连接之后再执行processIncoming。
- private void processIncoming(Call call) {
- //... ...省略
- synchronized (mServiceAndQueueLock) {
- if (mCallHandlerServiceGuarded != null) {
- mCallHandlerServiceGuarded.onIncoming(call,
- RejectWithTextMessageManager.loadCannedResponses());
- }
- //... ....省略
- }
- private void onCallHandlerServiceConnected(ICallHandlerService callHandlerService) {
- //... ...省略
- mCallHandlerServiceGuarded = callHandlerService;
- //... ...省略
- }
- onCallHandlerServiceConnected(ICallHandlerService.Stub.asInterface(service));
InCallUI界面更新
经过前面Telephoney framework和TeleService处理之后,已经获取到了UI界面所需要的数据,在InCallUI中要做的仅仅是将相关数据更新的界面上。整个流程如图:
在CallHandlerService中,首先会执行onIncoming()方法,并进而跳转到CallList中。
- mCallList.onIncoming(entry.getKey(), entry.getValue());
在完成call列表化之后便会通知相应的presenter,这里是MT(来电)流程。所以主要涉及到两个presenter即AnswerPresenter和InCallPresenter。前者负责来电接听/拒接控件的更新显示,后者负责CallCard和CallButton以及VTCall ( MTK加入的VideoCall )的界面更新显示。
通过CallCardPresenter中的onStateChange()方法,回调到CallCardFragment,并使用ui.setXXX()方法设置界面元素的内容,这里CallCard的更新可以查看《Android 4.4 Kitkat Phone工作流程浅析(二)__UI结构分析》,里面有涉及CallCard的更新流程。
小结
MT(来电)从Modem端发起,最终显示到界面上,整个过程的传递大致可以分为以下三个步骤:
1. Telephony framework处理;
主要对来电信息进行初步加工与分类。
2. TeleService处理;
完成对Telephony framework加工后的消息进行记录登记,并获取显示界面所需要的各种数据。
3. InCallUI界面显示更新
接收TeleService传递过来的更新请求,并将相关联系人数据更新到界面上。
虽然简单的将MT(来电)流程分成了三个部分,但通过代码的查看可以知道,在此过程中有很多分支。比如:来电响铃,Notification通知等等,这些都属于MT(来电)流程的一部分。对于Android 4.4来讲,Phone模块一分为二即InCallUI和TeleService,google实际上将界面显示逻辑与后台处理逻辑进行了更好的分离,对比Android 4.2的Phone可以知道,在Android 4.4 的Phone中很多东西都比以前明确和清晰。特别是界面更新这一块,引入了Presenter和Fragment的方式,使得逻辑更加清楚。
虽然简单的理清了MT(来电)的整个流程,但很多细节地方还值得推敲。MTK在原生Android 4.4 的基础上又添加和修改了许多东西,对于这一块MTK很大程度上是为了复用自己以前的代码,所以很多地方看起来杂乱无章,与原生Android 4.4 的代码相比显得格格不入。
- 转(Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析)
- Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析
- Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析
- Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析
- Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析
- 转(Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析)
- Android 4.4 Kitkat Phone工作流程浅析(七)__来电(MT)响铃流程
- Android 4.4 Kitkat Phone工作流程浅析(七)__来电(MT)响铃流程
- Android 4.4 Kitkat Phone工作流程浅析(七)__来电(MT)响铃流程
- 转(Android 4.4 Kitkat Phone工作流程浅析(二)__UI结构分析)
- 转(Android 4.4 Kitkat Phone工作流程浅析(四)__RILJ工作流程简析)
- Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析
- Android 4.4 Kitkat Phone工作流程浅析(九)__状态通知流程分析
- Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析
- Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析
- Android 4.4 Kitkat Phone工作流程浅析(九)__状态通知流程分析
- Android 4.4 Kitkat Phone工作流程浅析(九)__状态通知流程分析
- Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析
- fatal error C1083: Cannot open precompiled header file: 'Debug/Hello.pch': No such file or directory
- Feed系统架构资料收集
- Java XML文件解析
- NYOJ17 单调递增最长子序列 【二分法】+【动态规划】
- linux汇编详解
- 转(Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析)
- struts2 CRUD
- COJ - 1049 - Sum 题解
- Epoll在LT和ET模式下的读写方式
- POJ2240Arbitrage
- 点滴
- 共轭对称序列和共轭反对称序列
- 运行异常:android.view.WindowManager$BadTokenException:is not valid; is your activity running?
- eclipse 导入 WEB项目不识别