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經過各類接口來向外提供卡信息的查詢和修改，這樣看來邏輯仍是比較清晰明瞭的。