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

来源：互联网发布：泉州数据分析培训编辑：程序博客网时间：2024/05/17 13:09

本文来自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());        mCallOptionHandlerList.add(callOptionHandlerFactory.getEmergencyCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getInternetCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getVideoCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getSimSelectionCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getSimStatusCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getVoiceMailCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getInternationalCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getIpCallOptionHandler());        mCallOptionHandlerList.add(callOptionHandlerFactory.getFinalCallOptionHandler());    }

这里完成的链表的构造，但还是无法直接看出第一个节点内容是什么，因此我们需要继续查看调用CallOptionHandler构造方法的地方，并弄清楚传递的参数。经过查看我们可以知道在Dialer中的ContactsCallOptionHandler构造方法中使用super调用了父类构造方法，其父类就是CallOptionHandler。

    public ContactsCallOptionHandler(Context activityContext, CallOptionHandlerFactory callOptionHandlerFactory) {        super(callOptionHandlerFactory);        mActivityContext = activityContext;    }

继续查看ContactsCallOptionHandler构造方法调用处。我们在Dialer中DialpadFragment的onCreate方法里看到了调用：

mCallOptionHandler = new ContactsCallOptionHandler(getActivity(),                new ContactsCallOptionHandlerFactory());

这里完成了真正的赋值，也就说CallOptionHandler中的mCallOptionHandlerList链表对象，使用了ContactsCallOptionHandlerFactory的对象进行了赋值。说白了就是：

mCallOptionHandlerList.add(callOptionHandlerFactory.getFirstCallOptionHandler());//等价于mCallOptionHandlerList.add(new ContactsCallOptionHandlerFactory().getFirstCallOptionHandler());mCallOptionHandlerList.getFirst().handleRequest(request);//等价于new ContactsCallOptionHandlerFactory().getFirstCallOptionHandler().handleRequest(request);

ContactsCallOptionHandlerFactory类继承自CallOptionHandlerFactory，该类是一个抽象类，需要实现抽象方法createHandlerPrototype。ContactsCallOptionHandlerFactory本身并不具有getFirstCallOptionHandler()方法，而需要调用其父类的该方法：

public class ContactsCallOptionHandlerFactory extends CallOptionHandlerFactory {    protected void createHandlerPrototype() {        mInternetCallOptionHandler = new ContactsInternetCallOptionHandler();        mVideoCallOptionHandler = new ContactsVideoCallOptionHandler();        mInternationalCallOptionHandler = new ContactsInternationalCallOptionHandler();        mSimSelectionCallOptionHandler = new ContactsSimSelectionCallOptionHandler();        mSimStatusCallOptionHandler = new ContactsSimStatusCallOptionHandler();        mIpCallOptionHandler = new ContactsIpCallOptionHandler();        mVoiceMailCallOptionHandler = new ContactsVoiceMailCallOptionHandler();        ExtensionManager.getInstance().getContactsCallOptionHandlerFactoryExtension().createHandlerPrototype(this);    }}

在实例化ContactsCallOptionHandlerFactory对象的时候会调用其父类构造方法即：

public abstract class CallOptionHandlerFactory {    protected CallOptionBaseHandler mFirstCallOptionHandler;    protected CallOptionBaseHandler mEmergencyCallOptionHandler;    protected CallOptionBaseHandler mInternetCallOptionHandler;    protected CallOptionBaseHandler mVideoCallOptionHandler;    protected CallOptionBaseHandler mInternationalCallOptionHandler;    protected CallOptionBaseHandler mSimSelectionCallOptionHandler;    protected CallOptionBaseHandler mSimStatusCallOptionHandler;    protected CallOptionBaseHandler mIpCallOptionHandler;    protected CallOptionBaseHandler mVoiceMailCallOptionHandler;    protected CallOptionBaseHandler mFinalCallOptionHandler;    //调用这里的构造方法    public CallOptionHandlerFactory() {        mFirstCallOptionHandler = new FirstCallOptionHandler();        mEmergencyCallOptionHandler = new EmergencyCallOptionHandler();        mFinalCallOptionHandler = new FinalCallOptionHandler();        createHandlerPrototype();//这里完成部分初始化    }    protected abstract void createHandlerPrototype();    public CallOptionBaseHandler getFirstCallOptionHandler() {        return mFirstCallOptionHandler;    }    public CallOptionBaseHandler getInternetCallOptionHandler() {        return mInternetCallOptionHandler;    }    //... ...省略}

这是典型的工厂模式，通过这里我们可以知道：

mCallOptionHandlerList.getFirst().handleRequest(request);//等价于new ContactsCallOptionHandlerFactory().getFirstCallOptionHandler().handleRequest(request);//等价于mFirstCallOptionHandler.handleRequest(request);

也就是说PhoneCommon的第一个handleRequest是在FirstCallOptionHandler中。代码如下：

    @Override    public void handleRequest(final Request request) {        log("handleRequest()");        //If the call is an voicemail, we put an exact slot here if the voice call        //setting isn't always ask. This will help to get the correct voice mail number.        Intent intent = request.getIntent();        Context ctx = request.getApplicationContext();        if (Constants.VOICEMAIL_URI.equals(intent.getData().toString())) {            final long defaultSim = Settings.System.getLong(ctx.getContentResolver(),                    Settings.System.VOICE_CALL_SIM_SETTING, Settings.System.DEFAULT_SIM_NOT_SET);            final SIMInfoWrapper simInfoWrapper = com.mediatek.phone.SIMInfoWrapper.getDefault();            if (defaultSim > 0 && simInfoWrapper.getSlotIdBySimId((int)defaultSim) >= 0) {                intent.putExtra("simId", simInfoWrapper.getSlotIdBySimId((int)defaultSim));            }        }        if (null != mSuccessor) {            mSuccessor.handleRequest(request);        }    }

根据MTK的注释我们大概知道FirstCallOptionHandler主要是为了voicemail做一些特殊的处理，即在intent中加入了simId字段。但我们这里是进行普通的拨号，因此不会执行voicemail相关代码，直接执行mSuccessor.handleRequest()方法。

这里比较重要了，这个mSuccessor对象是什么呢？它的定义在抽象类CallOptionBaseHandler中，而FirstCallOptionHandler是CallOptionBaseHandler的子类：

    protected CallOptionBaseHandler mSuccessor;

这里我们回到前面CallOptionHandler的doCallOptionHandle方法，注意到：

        ListIterator<CallOptionBaseHandler> iterator = mCallOptionHandlerList.listIterator();        CallOptionBaseHandler previousHandler = iterator.next();        while (iterator.hasNext()) {            CallOptionBaseHandler currentHandler = (CallOptionBaseHandler)iterator.next();            previousHandler.setSuccessor(currentHandler);//也就是说前一个对象的mSuccessor对象是当前的OptionHanderHandler            previousHandler = currentHandler;        }

这里建立了链表，那么FirstCallOptionHandler中的mSuccessor.handleRequest()方法自然跳转到EmergencyCallOptionHandler中，并依次执行下去。我们通过Log可以看出整个执行流程。

Line 6647: 03-11 16:17:37.721 D/FirstCallOptionHandler( 1944): handleRequest()Line 6649: 03-11 16:17:37.721 D/EmergencyCallOptionHandler( 1944): handleRequest()Line 6655: 03-11 16:17:37.721 D/InternetCallOptionHandler( 1944): handleRequest()Line 6657: 03-11 16:17:37.721 D/VideoCallOptionHandler( 1944): handleRequest()Line 6659: 03-11 16:17:37.721 D/VideoCallOptionHandler( 1944): handleRequest(), but not videoLine 6661: 03-11 16:17:37.721 D/SimSelectionCallOptionHandler( 1944): handleRequest()Line 7721: 03-11 16:17:39.461 D/SimStatusCallOptionHandler( 1944): handleRequest(), slot = 0Line 7735: 03-11 16:17:39.461 D/VoiceMailCallOptionHandler( 1944): handleRequest()Line 7737: 03-11 16:17:39.461 D/InternationalCallOptionHandler( 1944): handleRequest()Line 7797: 03-11 16:17:39.461 D/IpCallOptionHandler( 1944): handleRequest()Line 7799: 03-11 16:17:39.461 D/FinalCallOptionHandler( 1944): handleRequest()

也就是说整个拨号预处理过程分为10个阶段，分别为：

1. FirstCallOptionHandler

开始拨号预处理，判断呼叫号码是否属于voicemail，如果是则对intent进行一些处理，添加simId字段；

2. EmergencyCallOptionHandler

判断呼叫号码是否为紧急号码，如果是紧急号码则不再进行后续判断而直接开始拨号操作(跳转到OutgoingCallReceiver)；

3. InternetCallOptionHandler

判断当前呼叫号码是否为网络拨号，即SIP Phone；

4. VideoCallOptionHandler

判断当前是否是进行的视屏拨号，即Video Call；

5. SimSelectionCallOptionHandler

判断当前使用哪一张SIM卡进行拨号。这一步会根据用户设置的默认SIM卡进行拨号，默认是弹出对话框，用户选择其中一张SIM卡进行拨号；

6. SimStatusCallOptionHandler

判断当前SIM卡状态是否允许拨号操作；

7. VoiceMailCallOptionHandler

判断当前呼叫号码是否属于voicemail，如果是则进行相关处理；

8. InternationalCallOptionHandler

判断呼叫号码是否符合当前国家ISO码；

9. IpCallOptionHandler

判断当前呼叫号码是否是IP呼叫(加拨17951)；

10. FinalCallOptionHandler

会到Dialer中的ContactsCallOptionHandler中；

整个过程如图4：

图 4

以上就是拨号的号码预处理流程，这个预处理流程时序图如下：

图 5

TeleService服务处理

在TeleService中还是会进行各种判断，这些判断有的是在PhoneCommon中做过的，但这是Android原生流程，MTK并没有去修改。比如期间还是有SIP Call和Emergency Call的判断。

经过前面的PhoneCommon之后，会使用以下方式发出广播：

    public void onContinueCallProcess(Intent intent) {        //清楚PhoneCommon过程中产生的dialog        dismissDialogs();        /** @} */        intent.setAction(Constants.OUTGOING_CALL_RECEIVER);        intent.setClassName(Constants.PHONE_PACKAGE, Constants.OUTGOING_CALL_RECEIVER);        DialerApplication.getInstance().sendBroadcast(intent);    }

这里就和原生Android有点区别了，Android原生是直接使用StartActivity的方式启动到OutgoingCallBroadcaster去，而这里是通过广播跳转到，TeleService/com/mediatek/phone/OutgoingCallReceiver中去。在原生 Android中是没有OutgoingCallReceiver.java的，它是OutgoingCallBroadcaster.java的内部类，这里被提取了出来。

    @Override    public void onReceive(Context context, Intent intent) {        if (Constants.OUTGOING_CALL_RECEIVER.equals(intent.getAction())) {            Intent broadcastIntent = new Intent(Intent.ACTION_NEW_OUTGOING_CALL);            String number = CallOptionUtils.getInitialNumber(context, intent);            OutgoingCallBroadcaster.sendNewCallBroadcast(context, intent, number, false, this);            //... ...省略        }    }

这里调用OutgingCallBroadcaster的sendNewCallBroadcast方法继续拨号流程：

    public static void sendNewCallBroadcast(Context context, Intent intent, String number,                                            boolean callNow, BroadcastReceiver receiver) {        //... ...省略 这里指定了接收的receiver，也就是前面提到的OutgoingCallReceiver        context.sendOrderedBroadcastAsUser(broadcastIntent, UserHandle.OWNER,                PERMISSION, receiver,                null,  // scheduler                Activity.RESULT_OK,  // initialCode                number,  // initialData: initial value for the result data                null);  // initialExtras    }

看到这里我也很纳闷，为什么要这样转一圈呢？直接跳转过去不可以？这个要问就只能问写这块代码的人了。我发现这些代码从MTK 2.3 到 4.2 在结构上都没怎么变化，我猜测是因为之前的架构是这样做的，后面只是移植并没有去优化完善，除非有bug采取解决，否则就只是拿来使用了。

这里通过制定receiver又跳转到了OutgoingCallReceiver的onReceive方法中，根据Action：Intent.ACTION_NEW_OUTGOING_CALL执行代码如下：

    @Override    public void onReceive(Context context, Intent intent) {        if (Constants.OUTGOING_CALL_RECEIVER.equals(intent.getAction())) {            //... ...省略 第一次执行这里        } else if (Intent.ACTION_NEW_OUTGOING_CALL.equals(intent.getAction())) {            //... ...省略 判断是否是SIP Call            if ((PhoneNumberUtils.isUriNumber(number) && intent.getIntExtra(Constants.EXTRA_SLOT_ID, -1) == -1)                    || Constants.SCHEME_SIP.equals(uri.getScheme())) {//... ...省略 如果是SIP Call则执行                startSipCallOptionHandler(context, newIntent);            } else {//... ...省略 经过前面处理之后，开始往framework传递                PhoneGlobals.getInstance().callController.placeCall(newIntent);            }        }    }

跳转到CallController中继续执行，根据拨号类型( 这里所说的类型是双卡拨号，视屏拨号 )，再跳转到PhoneUtils中的placeCallGemini方法中，在该方法中也会调用startGetCallerInfo()方法获取呼叫号码的信息，用于显示在CallCard上。

TeleService中Call处理部分，实际上主要是后台逻辑处理，Android 4.4 Phone最重要的特点就是将显示和逻辑分离。这块与Android 4.2改动并不大，只是从原来的Phone中分离了出来。

TeleService执行时序图如下：

图 6

Framework Telephony处理拨号请求

这里的调用和参数传递也比较多，有几个关键点需要提一下。当我们跳转到CallManager的dial方法后，会执行到以下代码获取Connection：

result = basePhone.dial(dialString);

basePhone是Phone对象，而Phone是一个接口类，而且这里是通过参数传递过来的。我们在CallController的placeCallInternal()方法中可以看到以下代码：

phone = PhoneUtils.pickPhoneBasedOnNumber(mCM, scheme, number, sipPhoneUri);

继续查看pickPhoneBasedOnNumber方法：

    public static Phone pickPhoneBasedOnNumber(CallManager cm,            String scheme, String number, String primarySipUri) {        if (primarySipUri != null) {            Phone phone = getSipPhoneFromUri(cm, primarySipUri);            if (phone != null) return phone;        }        return CallManagerWrapper.getDefaultPhone();//不是SIP Call    }

继续查看CallManagerWrapper中的getDefaultPhone方法：

    public static Phone getDefaultPhone() {        Phone phone = null;        if (GeminiUtils.isGeminiSupport()) {//是否支持双卡            phone = ((GeminiPhone) MTKCallManager.getInstance().getDefaultPhoneGemini());        } else {            phone = CallManager.getInstance().getDefaultPhone();        }        return phone;    }

因为这里是GSM/WCDMA支持双SIM卡的手机，而双SIM卡支持是Android原生没有的，MTK自己做了这一块，但却把相关方法实现封装到了jar包中，并进行混淆(这一点高通就比较厚道，直接开放源代码)。MTK加入了这个所谓MTKCallManager主要目的是用于管理双卡这块，关于双卡分析后面再做。虽然MTK将Gemini相关代码封装到了jar包中，但我们依然可以将其反解进行查看，在该路径下找到gemini所使用的jar包：

SourceCode/vendor/mediatek/banyan_addon_x86/artifacts/out/target/common/obj/JAVA_LIBRARIES/static_gemini_intermediates/classes.jar

banyan_addon_x86是MTK的模拟器，我们找到其中MTKCallManager的getDefaultPhoneGemini如下：

  public Phone getDefaultPhoneGemini()  {    return this.U;  }

这里的U是Phone对象，我们可以简单的这样理解MTK的双卡改动，将单卡流程复制一遍，然后弄一个MTKCallManager来管理总管理。

那么这里的Phone是如何赋值的呢，可以看到有一个registerPhoneGemini的方法：

  public void registerPhoneGemini(Phone paramPhone){    this.U = paramPhone;    //... ...省略 }

那么这里的registerPhoneGemini()是什么时候调用的呢？我们看到TeleService的PhoneGlobals.java中onCreate方法：

    public void onCreate() {//... ...省略        if (phone == null) {            PhoneFactory.makeDefaultPhones(this);            // Get the default phone            phone = PhoneFactory.getDefaultPhone();            //... ...省略            registerPhone();            //... ...省略        }//... ...省略   }

这里为什么要找到PhoneGlobals中呢？这要说道Phone的启动流程了，后面再介绍吧。在第一次启动时phone == null，因此就会执行其中的makeDefaultPhones方法：

    public static void makeDefaultPhones(Context context) {//是否支持双卡        if (FeatureOption.MTK_GEMINI_SUPPORT == true){            SystemProperties.set(Phone.GEMINI_DEFAULT_SIM_MODE, String.valueOf(RILConstants.NETWORK_MODE_GEMINI));            MTKPhoneFactory.makeDefaultPhone(context, RILConstants.NETWORK_MODE_GEMINI);        }else{            SystemProperties.set(Phone.GEMINI_DEFAULT_SIM_MODE, String.valueOf(RILConstants.NETWORK_MODE_WCDMA_PREF));            MTKPhoneFactory.makeDefaultPhone(context, RILConstants.NETWORK_MODE_WCDMA_PREF);        }        //... ...省略    }

接下来找到MTKPhoneFactory中的makeDefalutPhone方法：

  public static void makeDefaultPhone(Context paramContext, int paramInt)  {    //如果是Gemini那么S=RILConstants.NETWORK_MODE_GEMINI//如果不是Gemini那么S=RILConstants.NETWORK_MODE_WCDMA_PREF    S = paramInt;    makeDefaultPhone(paramContext);  }  public static void makeDefaultPhone(Context paramContext) {    synchronized (Phone.class) {      if (!M) {//... ...省略 创建本地socket服务端        new LocalServerSocket("com.android.internal.telephony");        N = new DefaultPhoneNotifier();        //... ...省略 获取Phone Type        int i1 = getPhoneType(j);        if (i1 == 1) { //if phoneType == PhoneConstants.PHONE_TYPE_GSM          I = new RIL(paramContext, localInterruptedException1, k, 0);          UiccController.make(paramContext, I);          H = new PhoneProxy(new GSMPhone(paramContext, I, N));          Rlog.i("PHONE", "Creating GSMPhone");        } else if (i1 == 2) { //if phoneType == PhoneConstants.PHONE_TYPE_CDMA          I = new RIL(paramContext, localInterruptedException1, k, 0);          UiccController.make(paramContext, I);          H = new PhoneProxy(new CDMAPhone(paramContext, I, N));          Rlog.i("PHONE", "Creating CDMAPhone");        } else if (i1 == 4) { //if phoneType == PhoneConstants.PHONE_TYPE_GEMINI  //这里DefaultPhoneNotifier的参数是指定SIM卡id          //... ...省略                    //GEMINI_SIM_NUM = 2          int[] arrayOfInt = new int[PhoneConstants.GEMINI_SIM_NUM];          //... ...省略          //... ...arrayOfInt[0]和arrayOfInt[1]均=1          //... ...获取RILJ对象这里的RIL构造方法最后一个参数是SimId          //... ...int k = CdmaSubscriptionSourceManager.getDefault(paramContext);          I = new RIL(paramContext, arrayOfInt[0], k, 0);          J = new RIL(paramContext, arrayOfInt[1], k, 1);                    //... ...省略 初始化GSMPhone数组                    GSMPhone[] arrayOfGSMPhone = new GSMPhone[PhoneConstants.GEMINI_SIM_NUM];                    arrayOfGSMPhone[0] = new GSMPhone(paramContext, I, N, 0);                    arrayOfGSMPhone[1] = new GSMPhone(paramContext, J, O, 1);                    if (PhoneConstants.GEMINI_SIM_NUM == 2) {          //这里的H实际上为GeminiPhone对象，而GeminiPhone extends Handler implements Phone          H = new GeminiPhone(new PhoneProxy(arrayOfGSMPhone[0]), new PhoneProxy(arrayOfGSMPhone[1]), i2);          }          //... ...省略        }       }   }}

这里的H 实际上是GeminiPhone对象，而GeminiPhone extends Handler implement Phone，因此H实际上在这里完成了实例化，GeminiPhone负责双卡管理，对于GeminiPhone这里就再去细究了。通过代码可以看到最终我们是通过PhoneProxy来获取到的Phone对象，而这里的Phone对象实际上为GSMPhone，arrayOfGSMPhone数组可以看到。这里完成H对象(Phone对象)的赋值后，我们可以看到PhoneGlobals的onCreate中：

phone = PhoneFactory.getDefaultPhone();registerPhone();

通过getDefalutPhone()方法获取phone对象：

    public static Phone getDefaultPhone() {return MTKPhoneFactory.getDefaultPhone();    }

以及：

  public static Phone getDefaultPhone()  {    return H;  }

最终调用到registerPhone方法：

    private void registerPhone() {        mCM = CallManager.getInstance();        if (GeminiUtils.isGeminiSupport()) {            mCMGemini = MTKCallManager.getInstance();    //mCMGemini是MTKCallManager对象，这里完成了phone注册            mCMGemini.registerPhoneGemini(phone);        } else {            mCM.registerPhone(phone);        }    }

回过头来，我们终于找到了