phone7:SIM的基础知识

第4章 SIM的基础知识

4.1 ICC和UICC

UICC：通用集成电路卡。分为两类UIM_ICC、UIM_UICC，即我们所说的SIM、USIM。

SIM：支持移动2G的GSM和电信3G的CDMA两种制式；

USIM：升级版的SIM卡，支持联通3G制式WCDMA，同时也支持4G制式。

4.2 UICC分类

根据逻辑模块的不同，分为以下几种不同的电话卡：

1.SIM：如用户标识模块（Subscriber Identity Module）

早期的SIM卡类型，支持GSM网络。

2.USIM：通用用户标识模块（Universal Subscriber Identity Module，）

升级版的SIM卡，支持UMTS（WCMDA，TD-SCDMA）和GSM网络，（联通卡，移动卡）

3.RUIM：可移动用户身份模块（Removable User Identity Module）

在SIM卡基础上做了扩展，专门为网络而设计，不再只是针对GSM，比如：CDMA.R-UIM卡支持在CDMA和GSM网络之间的漫游。支持CDMA和GSM网络（电信卡）

4.ISIM：IP多媒体业务标识模块（IP Multi Media Service Identity Module，）

存储了IMS（IP多媒体系统）专用的用户数据，主要由IMS运营商所提供。

5.CSIM：CDMA用户识别模块（CDMA Subscriber Identity Module ）        

4.3 UICC框架涉及类

1） UiccController    设计为单例模式。监听RIL中的SIM卡状态，并把SIM卡状态的变化通知给其他类。在UICC框架中，它属于核心部分，除了分发SIM卡状态变化，还对外提供接口用于获取UiccCard，IccFileHandler，IccRecords，UiccCardApplication的对象。

2） UiccCard   它代表了具体的卡，一个UiccCard对象就表示了一张SIM卡（PhoneID）。SIM卡中的状态或者数据都可以在这里获取，比如，属性mCardState保存了SIM卡状态，mUniversalPinState保存了PIN码状态，mCatService代表了STK应用信息，mUiccApplications中包含了SIM卡的具体数据。。。等等，总结起来，UiccCard是SIM卡的大管家，它既代表了SIM卡，又控制了UiccApplications，CatService的生命周期。

3） UiccCardApplication   顾名思义，这是SIM卡应用（不是STK）。应该是对应了上面说到的逻辑模块，一张SIM卡可以有多个逻辑模块，也就有多个UiccCardApplication对象。它控制了IccRecords和IccFileHandler的生命周期。而IccRecords和IccFileHandler都是读取和保存SIM卡中具体数据的操作类

4） IccFileHandler    读取SIM卡中（逻辑模块）的文件系统，也就是SIM卡中的具体数据。根据UICC卡的种类不同，衍生了几个对应的子类SIMFileHandler，UsimFileHandler，RuimFileHandler，CsimFileHandler，IsimFileHandler

5） IccRecords     模板类，通过IccFileHandler来操作SIM卡中的文件系统个，获取并保存SIM中的具体数据，根据UICC卡的种类不同，衍生了几个对应的子类SIMRecords，RuimRecords，IsimUiccRecords

6） IccCardProxy   封装了对UICC的一系列操作（状态和数据），并对外提供接口。一张卡（PhoneID）对应一个IccCardProxy对象。实际上，我们可以使用UiccController获取其他的对象从而实现对UICC的操作，但是需要传入一系列参数并保证卡状态正确，否则需要做判断处理，使用IccCardProxy操作只需要知道PhoneID。并发出ACTION_SIM_STATE_CHANGED广播，通知应用层以及没有监听UiccController得知SIM卡状态发生变化的其他类。

7） AdnRecordCache   

4.4 UICC流程

RIL.java->UiccController.java->UiccCard.java->UiccCardApplication.java->IccCardProxy.java

UiccController监听RIL中的状态变化，其中几个比较重要的监听事件如下：

EVENT_ICC_STATUS_CHANGED ： SIM卡状态

EVENT_GET_ICC_STATUS_DONE ：主动查询SIM卡状态

EVENT_RADIO_UNAVAILABLE ：Modem没启动或者错误

EVENT_SIM_REFRESH ：SIM卡刷新

EVENT_ICC_STATUS_CHANGED，EVENT_RADIO_UNAVAILABLE，EVENT_SIM_REFRESH 都是RIL主动上报的事件消息。

其中EVENT_ICC_STATUS_CHANGED这个事件消息的上报结果中并不会携带结果，也就是说得到这个状态，只能判断到当前SIM卡状态变化了，

但是当前是CARDSTATE_ABSENT，CARDSTATE_PRESENT，CARDSTATE_ERROR中的哪一个，你还需要查询一遍，所以就有了以下的这个状态监听：

EVENT_GET_ICC_STATUS_DONE 主动查询SIM卡状态

这就是有了EVENT_ICC_STATUS_CHANGED事件消息后还需要设置EVENT_GET_ICC_STATUS_DONE事件消息的原因。

1. RIL.java

RIL中处理SIM卡状态相关的事件消息。其中，在处理EVENT_GET_ICC_STATUS_DONE 主动查询SIM卡状态的时候，查询结果被封装在IccCardStatus类中并交由其监听类UiccController中处理（ret）：

1. UiccController.java

UiccController中处理SIM卡状态相关的事件消息：主要分析主动查询SIM卡状态时的流程：为每一张SIM卡初始化一个UiccCards对象并赋初值。

1. UiccCard.java

一个UiccCard对象就表示了一张SIM卡（PhoneID），其控制了UiccApplications，CatService的生命周期。参见UiccCard.java—->createAndUpdateCatService()和update()

1. UiccApplications.java

UiccApplications代表了SIM卡中的逻辑模块，根据当前SIM中的逻辑模块的多少产生多少个UiccApplications对象，上限为8个。控制着IccRecords和IccFileHandler的生命周期，此外还包含了一系列对SIM卡数据的操作，比如pin码，puk码，是否锁卡，是否支持FDN等等，系统文件的读取则交由IccFileHandler处理。

根据UICC卡的种类不同，创建相应的模板类IccRecords：

根据UICC卡的种类不同，创建相应的系统文件读取类IccFileHandler：

1. IccCardProxy.java

IccCardProxy设计的初衷就是对外提供接口。因为UiccCards对象的创建跟卡状态相关，会动态创建和销毁，如果外部通过UiccCards来获取卡的状态以及其他信息，不可避免的会出现错误，因此，android就设计了IccCardProxy，无论卡状态如何变化，它的对象都存在，其初始化在TelephonyComponentFactory.java中：

Phone对象创建时，先创建了UiccController对象，之后根据mPhoneId创建了IccCardProxy对象，意味着有几个卡槽就有几个IccCardProxy对象。

如果我们需要操作SIM卡相关，正确的姿势应该是通过Phone对象获取IccCardProxy对象，通过IccCardProxy暴露出的接口来实现对SIM卡相关的操作。