Android 5.0 Uicc框架分析

已同步更新至我的blog:   dxjia.cn

Uicc框架

UICC框架是Android在4.1引入的，使的对卡的管理控制更加清晰。要了解这个UICC框架，须要从UiccController开始，它是整个UICC框架的开始与控制者，该类被设计为单例，是消息处理类Handler的子类，因此其实现确定是基于event触发的，其在Phone建立的早期被初始化：

1 2 3

// Instantiate UiccController so that all other classes can just // call getInstance() mUiccController = UiccController.make(context, sCommandsInterfaces);

make函数只能被调用一次，之后若是要想得到UiccController对象，只能经过getInstance进行，来看UiccController的构造函数：

1 2 3 4   5 6 7 8 9

publicstatic UiccController make(Context c, CommandsInterface[] ci){ synchronized(mLock){ if(mInstance !=null){ thrownew RuntimeException("MSimUiccController.make() should only be called once"); } mInstance =new UiccController(c, ci); return(UiccController)mInstance; } }

 

private UiccController(Context c, CommandsInterface []ci){     if(DBG) log("Creating UiccController");     mContext = c;     mCis = ci;     for(int i =0; i < mCis.length; i++){   Integer index =new Integer(i);        mCis[i].registerForIccStatusChanged(this, EVENT_ICC_STATUS_CHANGED, index);        // TODO remove this once modem correctly notifies the unsols        mCis[i].registerForAvailable(this, EVENT_ICC_STATUS_CHANGED, index);        mCis[i].registerForNotAvailable(this, EVENT_RADIO_UNAVAILABLE, index);     } }

 

CommandsInterface即为RILJ实例，这里保存下来就能够直接与RIL进行通讯。与此同时，在每一个RILJ实例上注册了3个事件，分别是

1 2 3

registerForIccStatusChanged(this,EVENT_ICC_STATUS_CHANGED, index); registerForAvailable(this,EVENT_ICC_STATUS_CHANGED, index); registerForNotAvailable(this,EVENT_RADIO_UNAVAILABLE, index);

这里能够看到增长了一个index参数，这个index这里就是指的phoneId，是对双卡的支持，是5.0新增的。增长了这个参数以后，EVENT_ICC_STATUS_CHANGED和EVENT_RADIO_UNAVAILABLE消息上来，UiccController才能分清是从哪一个Phone过来的消息，也就是从哪一个modem或者说是从哪一个卡。。。

 

再来看看消息处理：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

@Override publicvoid handleMessage (Message msg){ synchronized(mLock){ Integer index = getCiIndex(msg);   if(index <0|| index >= mCis.length){ Rlog.e(LOG_TAG,"Invalid index : "+ index +" received with event "+ msg.what); return; }   switch(msg.what){ caseEVENT_ICC_STATUS_CHANGED: if(DBG) log("Received EVENT_ICC_STATUS_CHANGED, calling getIccCardStatus"); mCis[index].getIccCardStatus(obtainMessage(EVENT_GET_ICC_STATUS_DONE, index)); break; caseEVENT_GET_ICC_STATUS_DONE: if(DBG) log("Received EVENT_GET_ICC_STATUS_DONE"); AsyncResult ar =(AsyncResult)msg.obj; onGetIccCardStatusDone(ar, index); break; caseEVENT_RADIO_UNAVAILABLE: if(DBG) log("EVENT_RADIO_UNAVAILABLE, dispose card"); if(mUiccCards[index]!=null){ mUiccCards[index].dispose(); } mUiccCards[index]=null; mIccChangedRegistrants.notifyRegistrants(new AsyncResult(null, index,null)); break; default: Rlog.e(LOG_TAG," Unknown Event "+ msg.what); } } }

总结以下：

1). 消息到来以后，首先从Message中取出index值，也就是PhoneId；

2). 根据EVENT分发处理，若是是 EVENT_ICC_STATUS_CHANGED消息，对根据index调用对应的RILJ的getIccCardStatus函数，并传递EVENT_GET_ICC_STATUS_DONE，典型的异步处理，当EVENT_GET_ICC_STATUS_DONE返回时，就会从底层获取到了这个index对应的卡的状态，而后调用onGetIccCardStatusDone来更新对应index的卡相关的对象。卡相关的对象都是在这里被建立出来的。具体以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

privatesynchronizedvoid onGetIccCardStatusDone(AsyncResult ar, Integer index){ if(ar.exception !=null){ Rlog.e(LOG_TAG,"Error getting ICC status. " +"RIL_REQUEST_GET_ICC_STATUS should " +"never return an error", ar.exception); return; } if(!isValidCardIndex(index)){ Rlog.e(LOG_TAG,"onGetIccCardStatusDone: invalid index : "+ index); return; }   IccCardStatus status =(IccCardStatus)ar.result;   if(mUiccCards[index]==null){ //Create new card mUiccCards[index]=new UiccCard(mContext, mCis[index], status, index);   /* // Update the UiccCard in base class, so that if someone calls // UiccManager.getUiccCard(), it will return the default card. if (index == PhoneConstants.DEFAULT_CARD_INDEX) { mUiccCard = mUiccCards[index]; } */ }else{ //Update already existing card mUiccCards[index].update(mContext, mCis[index], status); }   if(DBG) log("Notifying IccChangedRegistrants"); mIccChangedRegistrants.notifyRegistrants(new AsyncResult(null, index,null));   }

从代码的实现能够看出，首先从result中解析出IccCardStatus，而后根据这个值进行UiccCard的建立，若是对应的index的卡 UiccCard已经存在，那么就会调用UiccCard.update来更新其内部的UiccCardApplication，这里提一下这几个类的关系：

 

UIccController 中根据卡的个数建立对应数量的 UIccCard，而每一个UiccCard中又会分别根据本身卡的实际状况建立对应的UiccCardApplication

UiccController 整体控制

UiccCard 具体的卡

UiccCardApplication 具体的卡里的应用【每一个UiccCardApplication内部都会根据app_type来建立对应的 IccRecords和IccFileHandler对象做为操做卡上内容的接口】

 

3). 若是是 EVENT_RADIO_UNAVAILABLE消息，则会销毁对应的UiccCard实例，并notify。

 

因此总结来看，UiccController就是经过向RIL注册卡状态变化的监听，当底层一有变化时，会经过RIL上报给UiccController，这样就会触发其下发getIccCardStatus来查询卡状态，获得卡状态后更新其内部的UiccCard及UIccCardApplication等。因此phone或者其余state tracker service能够经过UiccController来获取到正确的卡信息。

整个家族树总结以下：

 

IccardProxy

在我看来IccardProxy是一个有些多余的类，由于其内部实际维护的各类实例都是从UiccController框架中取得的，就连ICC_CARD_STATUS_CHANGED消息，也是经过向UiccControler注册来获得notify，因此卡状态的更新与维护，UiccController永远是第一步的。

经过阅读代码，我感受IcccardProxy就是一个用来提供给外部使用的接口，可使得app不用直接操做UiccController，android给出来注释以下：

/** * @Deprecated use {@link UiccController}.getUiccCard instead. * * The Phone App assumes that there is only one icc card, and one icc application * available at a time. Moreover, it assumes such object (represented with IccCard) * is available all the time (whether {@link RILConstants#RIL_REQUEST_GET_SIM_STATUS} returned * or not, whether card has desired application or not, whether there really is a card in the * slot or not). * * UiccController, however, can handle multiple instances of icc objects (multiple * {@link UiccCardApplication}, multiple {@link IccFileHandler}, multiple {@link IccRecords}) * created and destroyed dynamically during phone operation. * * This class implements the IccCard interface that is always available (right after default * phone object is constructed) to expose the current (based on voice radio technology) * application on the uicc card, so that external apps won't break. */

 

IccCardProxy在Phone建立的时候被构造，在UiccController初始化以后，

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15   16 17 18

// Instantiate UiccController so that all other classes can just // call getInstance() mUiccController = UiccController.make(context, sCommandsInterfaces);   for(int i =0; i < numPhones; i++){ PhoneBase phone =null; int phoneType = TelephonyManager.getPhoneType(networkModes[i]); if(phoneType == PhoneConstants.PHONE_TYPE_GSM){ phone =new GSMPhone(context, sCommandsInterfaces[i], sPhoneNotifier, i); }elseif(phoneType == PhoneConstants.PHONE_TYPE_CDMA){ phone =new CDMALTEPhone(context, sCommandsInterfaces[i], sPhoneNotifier, i); } Rlog.i(LOG_TAG,"Creating Phone with type = "+ phoneType +" sub = "+ i);   sProxyPhones[i]=newPhoneProxy(phone); }

上面的l17行，经过phone建立的PhoneProxy代理类实例内部会建立IccCardProxy。

mIccCardProxy = new IccCardProxy(mActivePhone.getContext(), mCommandsInterface, mActivePhone.getPhoneId());

这里也能够看出，IccCardProxy实例的个数是与Phone的个数相对应的，有2个phone就会有两个IccCardProxy对象，而UiccController里的UiccCard对象是跟卡动态关联的。因此，app若是经过phoneproxy.getIccCard是能够随时拿到IccCardProxy对象的，这样就不会发生获取不到卡状态的问题。也就是说APP是不会直接操做UiccController的，都是经过IccCardProxy来进行。

先来看看他的构造函数：

1 2 3 4 5 6 7 8 9 10   11 12 13 14   15 16 17 18 19 20 21

public IccCardProxy(Context context, CommandsInterface ci){ log("Creating"); mContext = context; mCi = ci; mCdmaSSM = CdmaSubscriptionSourceManager.getInstance(context, ci,this, EVENT_CDMA_SUBSCRIPTION_SOURCE_CHANGED,null); mUiccController = UiccController.getInstance(); mUiccController.registerForIccChanged(this, EVENT_ICC_CHANGED,null); ci.registerForOn(this,EVENT_RADIO_ON,null); ci.registerForOffOrNotAvailable(this, EVENT_RADIO_OFF_OR_UNAVAILABLE,null); setExternalState(State.NOT_READY); }   public IccCardProxy(Context context, CommandsInterface ci,int cardIndex){ this(context, ci);   mCardIndex = cardIndex;   resetProperties(); setExternalState(State.NOT_READY,false); }

 

黄色高亮的是几个关键函数。

首先IccCardProxy会向UiccController中注册ICC_CARD_STATUS_CHANGED消息，也就是在UiccController在更新完本身内部的UiccCard以后会notify IccCardProxy来让IccCardProxy更新本身内部的UiccCard实例等，但这里有个问题，就是UiccController虽是单例的，但其内部的UiccCard却可能会是多个的（多卡的状况下），而这里registerForIccChanged，注册EVENT时，却没有指定phoneid，那么UiccController不管哪一个卡有更新都会来notify，单卡的状况下无所谓，但双卡的状况下就会引入多余notify，是一个能够考虑改进的地方。

 

另外，重置properties，这里使用系统属性记录卡的状态

1 2 3 4 5 6 7 8

void resetProperties(){ if(mCurrentAppType == UiccController.APP_FAM_3GPP){ log("update icc_operator_numeric="+""); setSystemProperty(PROPERTY_ICC_OPERATOR_NUMERIC, mCardIndex,""); setSystemProperty(PROPERTY_ICC_OPERATOR_ISO_COUNTRY, mCardIndex,""); setSystemProperty(PROPERTY_ICC_OPERATOR_ALPHA, mCardIndex,""); } }

 

1 2 3 4

privatevoid setSystemProperty(String property,int slotId, String value){ long[] subId = SubscriptionController.getInstance().getSubId(slotId); TelephonyManager.setTelephonyProperty(property, subId[0], value); }

TelephonyManager.setTelephonyProperty 这里再也不贴了，说一下其记录property来支持双卡的方法：android使用同一个key，同时保存两个卡的属性值，值之间使用","分隔，顺序以phoneId从小到大排序。使用时取出后将","分隔转换为数组直接取下标便可。

 

 

总结：UiccController负责对卡槽的卡实时实例化或销毁对象，IccCardProxy监听UiccController里的变化并及时更新本身内部的状态，Phone实例经过getIccCard获得IccCardProxy实例来获取各类卡状态，Phone再经过service形式将这些接口暴露给应用层。