Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析

本文来自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 Phone 大致差异以及整体结构，本文主要分析 Android 4.4 Phone 的去电流程。通话是手机最基本也是最终要的功能，而通话可以大致分为来电和去电，这也是对Phone模块熟悉必不可少的基本流程。

        本文主要以方法调用时序图以及关键代码作为分析，因芯片厂商差异所以代码与原生略有出入，各位看官取其所需即可，切不可生搬硬套。

        MTK在Android的原生的基础上添加了很多功能，比如VideoCall, 来电/去电归属地等等，这些功能是Android原生所不具有。MTK在加入这些功能的同时，为了方便后续移植使用了一套自己的架构即pluginManager ( Phone中使用ExtensionManager从PluginManager中获取实例，Contacts也使用同样的方式 )。什么是PluginManager呢？当我们需要增强Android原生APP的功能时，一般来讲我们可以直接去修改原生的代码添加我们想要的功能，但这样会导致Android原生代码混乱并可能降低执行效率等。MTK为解决这样的问题推出了Plugin架构，即使用类似插件的方式将新功能嵌入到Android原生代码中，但这也并不是说一点都不会修改Android原生代码。

        这里为什么要提到Plugin呢？因为我们MTK平台Phone处理流程与原生的有所不同，MTK对拨号进行了一个预处理，我们姑且这么称呼吧，预处理主要目的是判断是否是Voice Mail, 是否是SIP Phone, 是否是Video Call等等，这些功能是MTK自己加入的，也就是说这里使用了plugin机制。

拨号时序图

        这里放上拨号时序图，具体信息就需要自己查看代码了，后面会简单提下我在看代码的过程中觉得一些重要的地方，因为图片太大后面会提供原图下载。时序图如图2：

图 2

        我们可以将图2分成四个部分：Dialer，PhoneCommon，TeleService，Telephony Framework。他们非别对应packages/apps/Dialer、packages/apps/PhoneCommon、packages/services/TeleService、framework/opt/telephony。实际上拨号操作会调用到RIL并使用AT指令发送给Modem，最终Modem与硬件交互后向基站发起通话请求，本文流程以APP-Framework为主。

拨号入口Dialer

        前面的文章我们已经提到 4.4 中的拨号界面不在附属于 Contacts 而是独立的Dialer应用，也就是把Contacts中Dialpad部分抽离了出来。拨号界面是DialtactsActivity，实际控件为DialpadFragment，点击拨号按钮触发DialpadFragment的onClick事件，并调用dialButtonPressed方法中，最终调用到ContactsCallOptionHandler中开始拨号预处理。整个过程比较简单，就不贴代码了。如图3：

图 3

拨号预处理PhoneCommon

        这里所说的拨号预处理是对于MTK平台来讲的，Android 原生没有这一块，直接从DialpadFragment使用StartAcitivty跳转到OutgongCallBroadcaster，我们主要看一下MTK对这一块做了什么。

        通过Dialer拨号我们可以知道，在Dialer的ContactsCallOptionHandler类中，调用doCallOptionHandle方法开启Phone的入口。代码如下：

    public void doCallOptionHandle(Intent intent) {
        
        //... ...省略部分代码，这里通过调用父类的doCallOptionHandle开始跳转到PhoneCommon中
        super.doCallOptionHandle(mActivityContext, DialerApplication.getInstance(), intent,
                                 this, DialerApplication.getInstance().cellConnMgr,
                                 telephony, SlotUtils.isGeminiEnabled(),
                                 FeatureOption.MTK_GEMINI_3G_SWITCH);

    }

看到CallOptionHandler中的doCallOptionHandle方法：

    public void doCallOptionHandle(Context activityContext, Context applicationContext, Intent intent,
                                   CallOptionBaseHandler.ICallOptionResultHandle resultHandler,
                                   CellConnMgr cellConnMgr, ITelephony telephonyInterface,
                                   boolean isMultipleSim, boolean is3GSwitchSupport) {
        ListIterator<CallOptionBaseHandler> iterator = mCallOptionHandlerList.listIterator();
        CallOptionBaseHandler previousHandler = iterator.next();
        while (iterator.hasNext()) {
            CallOptionBaseHandler currentHandler = (CallOptionBaseHandler)iterator.next();
            previousHandler.setSuccessor(currentHandler);
            previousHandler = currentHandler;
        }

        Request request = new Request(activityContext, applicationContext, intent, resultHandler,
                                      cellConnMgr, telephonyInterface, isMultipleSim, is3GSwitchSupport,
                                      mCallOptionHandlerFactory);
        mCallOptionHandlerList.getFirst().handleRequest(request);
    }

按照常理，我们直接去跟踪handleRequest方法就好了，可是这里MTK做了一个链表的结构。我们先看到这里的mCallOptionHandlerList对象，需要知道第一个节点中存放的内容。mCallOptionHandlerList的赋值是在CallOptionHandler的构造方法中完成的，如下：

    public CallOptionHandler(CallOptionHandlerFactory callOptionHandlerFactory) {
        mCallOptionHandlerFactory = callOptionHandlerFactory;
        mCallOptionHandlerList = new LinkedList<CallOptionBaseHandler>();

        mCallOptionHandlerList.add(callOptionHandlerFactory.getFirstCallOptionHandler());
        mCal