Android5.0雙卡分析

Android 5.0 雙卡資訊管理分析

    Android5.0開始支援雙卡了。對于雙卡的卡資訊的管理，也有了實作，盡管還不是完全徹底完整，如卡的slot id， display name，iccid，color等，其設計思路竟然跟之前接觸到的一個平台是一樣的，都是同不同顔色來辨別不同的卡，讓使用者一目了然，隻是5.0的實作目前還局限在FW架構裡，應用層的實作還沒有，相信，等到5.1或者再之後的版本中，我們就可以在setting裡看到對卡表示顔色、名稱等進行設定的功能菜單啦。

下面進入正題，來分析Android5.0的雙卡資訊是如何來維護的：

1 卡資訊的存儲

    先說結論，5.0是将所有卡資訊通過資料庫進行儲存的。資料庫表URL：content://telephony/siminfo，對應到的資料庫為telephony.db中的siminfo表，代碼檔案在TelephonyProvider.java，在這裡可以看到createTable的詳情，來看看這個表都包含哪些字段。

總共設計了11個字段，下面這張圖是從5.0模拟器上拉出來的telephony.db裡截取到的，可以用來做示例：

表名：

表資料示例：

下面分别介紹一下這些字段的含義。

1.1 _id

　　這個自不必說，android裡的每個db都有的，是資料庫裡的資料主key，這裡的_id值也是以後代碼裡看到的subId，是在資料庫中儲存時所在的條目的唯一辨別。有多少條資料，就說明儲存了多少個sim卡的資訊；

1.2 icc_id

　　從卡上讀取得到，是卡的唯一身份辨別，世界上的所有sim卡，每個卡都有不同的iccid，就像身份證一樣；如上面圖中的16進制串89014103211118510720；

1.3 sim_id

　　配置設定給卡的id序号，android設計從0開始，最大為卡槽個數，比如如果是雙卡終端，那麼隻有可能是0或者1；當然無卡時其值為-1，是以這裡其實是與卡槽固定對應的，卡槽如果有卡就取對應id，如果無卡，就設為-1；

1.4 display_name

　　配置設定給卡的顯示名字，從代碼上來看開機後會嘗試使用營運商名字，如果取不到，就使用簡單的SUB 01這樣的字串表示，等拿到營運商名字之後重新set，另外從下面的name_source字段的設計來看，android是允許使用者來自己指定這個顯示名的；

1.5 name_source

　　表明display_name字段的來源，有兩種來源，一是系統自動，name_source取值為0，另一種就是來自使用者指定，取值為1；

1 /**
 2 * The name_source is the default
 3 * @hide
 4 */
 5 publicstaticfinalint NAME_SOURCE_DEFAULT_SOURCE =0;
 6 
 7 /**
 8 * The name_source is from the SIM
 9 * @hide
10 */
11 publicstaticfinalint NAME_SOURCE_SIM_SOURCE =1;
12 
13 /**
14 * The name_source is from the user
15 * @hide
16 */
17 publicstaticfinalint NAME_SOURCE_USER_INPUT =2;      

1.6 color

　　顯示顔色，将使用顔色在UI上明顯區分卡1和卡2；android設定每個卡都隻能從固定的幾個顔色中取，如下：

1 /** @hide */
 2 publicstaticfinal String COLOR ="color";
 3 
 4 /** @hide */
 5 publicstaticfinalint COLOR_1 =0;
 6 
 7 /** @hide */
 8 publicstaticfinalint COLOR_2 =1;
 9 
10 /** @hide */
11 publicstaticfinalint COLOR_3 =2;
12 
13 /** @hide */
14 publicstaticfinalint COLOR_4 =3;
15 
16 /** @hide */
17 publicstaticfinalint COLOR_DEFAULT = COLOR_1;      

　　這四種顔色根據主題是dark還是light分别對應4種顔色，這些顔色其實并非是色值，而是固定顔色的背景9.png圖檔，都定義在資源drawable裡，看來是用來做backgroud用的。如

　　sim_dark_blue 

 sim_light_purple 

其他幾種顔色可以參考 SubscriptionController. setSimResource函數裡去color資源數組的初始化。

1.7 number

　　該卡對應的号碼，phone number。 //TODO：研究一下這個是怎麼擷取到呢？

1.8 display_number_format

　　辨別number字段的格式，總共有固定的3種，取其一。

/** @hide */
publicstaticfinalint DISPLAY_NUMBER_NONE =0;

/** @hide */
publicstaticfinalint DISPLAY_NUMBER_FIRST =1;

/** @hide */
publicstaticfinalint DISPLAY_NUMBER_LAST =2;

/** @hide */
publicstaticfinalint DISLPAY_NUMBER_DEFAULT = DISPLAY_NUMBER_FIRST;      

　　從SubscriptionController. setDisplayNumberFormat()函數的注釋可以看出點門道，

　　　　*Set number display format. 0: none, 1: the first four digits, 2: the last four digits

　　但搜了一下，對應的setDisplayNumber()函數并沒有跟這個format有關聯，直接儲存傳入的number到資料庫了。是以還不太清楚the first four digits 和 the last four digits的具體含義，等以後android應用層完善後應該能看到具體的使用方式。

1.9 data_roaming

　　是否允許這張卡進行資料漫遊，預設禁止漫遊。

1 /** @hide */
2 publicstaticfinalint DATA_ROAMING_ENABLE =1;
3 
4 /** @hide */
5 publicstaticfinalint DATA_ROAMING_DISABLE =0;
6 
7 /** @hide */
8 publicstaticfinalint DATA_ROAMING_DEFAULT = DATA_ROAMING_DISABLE;      

1.10 mcc

 移動國家碼，從卡上讀取得到，卡的mcc碼；

1.11 mnc

移動網絡碼，從卡上讀取得到，卡的mnc碼。度娘到對于mcc和mnc的解釋：

MCC 是 Mobile Country Code 的縮寫，譯為移動國家代碼。它由三位數字組成。用于辨別一個國家，但一個國家可以被配置設定多個 MCC 。比如美國的 MCC 有 310，311，和316。中國的 MCC 隻有 460。 MNC 是 Mobile Network Code 的縮寫，譯為移動網絡代碼。它由二到三位數字組成。MNC和 MCC 合在一起唯一辨別一個移動網絡提供者。比如中國移動的 MNC 是00，中國聯通的 MNC 是 01，中國聯通 CDMA 的 MNC 是 03，中國衛星全球星網的 MNC 是 04。 是以，460 00 就唯一辨別了中國移動。

　　是以卡的displayname應該也是通過mcc+mnc得到的。

2 主要工作類

　　上面介紹了卡資訊的資料設計，接下來看看有哪些類圍繞着這些資料來對外提供接口和功能。

類	功能介紹
TelephonyProvider	siminfo資料庫provider，直接操作DB，實作siminfo表的增删改查。
SubscriptionController	實作為遠端service，在phone初始化時被建立，作為資料庫的對外接口提供功能，其内部維護從資料庫讀取到的siminfo list，并實作了大量的如getSubId getDisplayName setDisplayName等getter和setter方法，這些方法維護siminfo list以及通過URL通路資料庫來實作功能。
SubscriptionManager	該類所有的内部接口都實作為了static，也就是該類是一個純粹提供接口的靜态類，其内部并不實作具體的邏輯，隻是通過調用SubscriptionController這個service的對應接口來完成工作，是以該類是一個對外接口的封裝，APP可以直接通過SubscriptionManager.getSubId等來實作功能，不需要直接操作service。目前還是Hide的，估計以後會開放給SDK。這種設計模式，android FW層用的很多，如SmsMnager、TelephonyManager等。
SubInfoRecordUpdater	卡資訊變化的監聽者和更新者，其在PhoneFactory中建立完phones之後被建立，起來之後會注冊對 ACTION_SIM_STATE_CHANGED 的監聽，收到監聽之後更新對應siminfo的資訊，如iccid、displayname(營運商名)、phonenumber。并且在自己内部維護了每個卡的卡狀态，這裡的卡狀态差別與ACTION_SIM_STATE_CHANGED所攜帶的卡狀态，ACTION_SIM_STATE_CHANGED的卡狀态有 LOCKED、READY、NOT READY、ABSENT等，是指的卡的具體狀态，而這裡的卡狀态是指 有沒有插卡、該卡槽的卡是不是變過了（換了一張卡）、卡槽的卡是一張沒見過的新卡、卡槽的卡是位置互換啦、卡槽的卡沒變化。【狀态還真有點繞，管的挺多的啊。。。】這些狀态是在收到ACTION_SIM_STATE_CHANGED之後，根據卡狀态以及卡的iccid等一些資訊算出來的，如果發現有新卡插入會進行廣播。
SubInfoRecord	subinfo的可序列化實作，封裝資料庫資料。

　　另外，在代碼中還可以看到 Subscription 和 SubscriptionData這兩個類，這兩個其實隻是資料封裝，并不直接跟卡資訊管理相關，其隻是儲存了一些卡的資料來提供給phone等使用，目前還找不到組織他們的接口，全局搜尋會發現，好多地方google都注釋掉了，邏輯還沒完整。SubscriptionData是Subscription list，目前從代碼來看，這兩個還沒有真正用起來，是以可以先無視了，不過要吐槽下google的代碼，起名咋這麼繞啊。另外還有個 CdmaSubscriptionSourceManager的類，這個是跟CDMA的卡提供者資訊有關的，會影響到具體的網絡行為，也跟本文的雙卡資訊管理無關。

3 工作流程

　　通過上面主要類的介紹，基本上整個雙卡資訊管理的架構就出來了，畫了一個圖友善了解。

4總結

　　5.0通過DB來儲存和維護雙卡資訊，SubInfoRecordUpdater通過監聽卡的變化動态更新資料庫裡的卡資料；SubscriptionController和SubscriptionManager通過各種接口來向外提供卡資訊的查詢和修改，這樣看來邏輯還是比較清晰明了的