Android 5.1 引入了一種機制，可為與通用集成電路卡 (UICC) 應用程序所有者相關的 API 授予特殊權限。 Android 平台加載存儲在 UICC 上的證書，並授予由這些證書籤名的應用程序調用少數特殊 API 的權限。
Android 7.0 擴展了此功能以支持 UICC 運營商權限規則的其他存儲源，從而顯著增加了可以使用 API 的運營商數量。有關 API 參考，請參閱CarrierConfigManager ；有關說明，請參閱運營商配置。
運營商擁有對 UICC 的完全控制權，因此該機制提供了一種安全且靈活的方式來管理來自移動網絡運營商 (MNO) 在通用應用分發渠道（例如 Google Play）上託管的應用，同時保留設備上的特殊權限，而無需使用每個設備平台證書籤署應用程序或預安裝為系統應用程序。
UICC規則
UICC 上的存儲與GlobalPlatform 安全元素訪問控制規範兼容。卡上的應用程序標識符 (AID) 是A00000015141434C00 ，標準的GET DATA命令用於獲取存儲在卡上的規則。您可以通過卡無線 (OTA) 更新來更新這些規則。
數據層次結構
UICC 規則使用以下數據層次結構（括號中的兩個字符的字母和數字組合是對象標記）。每個規則都是REF-AR-DO ( E2 )，由REF-DO和AR-DO的串聯組成：
-
REF-DO(E1) 包含DeviceAppID-REF-DO或DeviceAppID-REF-DO和PKG-REF-DO的串聯。-
DeviceAppID-REF-DO(C1) 存儲證書的 SHA-1（20 字節）或 SHA-256（32 字節）簽名。 -
PKG-REF-DO(CA) 是清單中定義的完整包名稱字符串，ASCII 編碼，最大長度 127 字節。
-
-
AR-DO(E3) 擴展為包括PERM-AR-DO(DB)，它是一個 8 字節的位掩碼，代表 64 個單獨的權限。
如果PKG-REF-DO不存在，則任何由證書籤名的應用都被授予訪問權限；否則證書和包名都需要匹配。
規則示例
應用名稱為com.google.android.apps.myapp ，十六進製字符串中的 SHA-1 證書為：
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
十六進製字符串中 UICC 的規則是：
E243 <= 43 is value length in hex
E135
C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
E30A
DB08 0000000000000001
訪問規則文件支持
Android 7.0 增加了對從訪問規則文件 (ARF) 中讀取運營商權限規則的支持。
Android 平台首先嘗試選擇訪問規則應用程序 (ARA) AID A00000015141434C00 。如果在 UICC 上找不到 AID，它會通過選擇 PKCS15 AID A000000063504B43532D3135回退到 ARF。然後，Android 讀取位於 0x4300 的訪問控制規則文件 ( 0x4300 ) 並查找具有 AID FFFFFFFFFFFF的條目。具有不同 AID 的條目將被忽略，因此其他用例的規則可以共存。
十六進製字符串中的示例 ACRF 內容：
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
訪問控制條件文件 (ACCF) 內容示例：
30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81
在上面的示例中， 0x4310是 ACCF 的地址，其中包含證書哈希61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 。由該證書籤名的應用程序被授予運營商特權。
啟用的 API
Android 支持以下 API。
電話經理
- 讓運營商應用程序向 UICC 詢問質詢/響應的方法：
getIccAuthentication。 - 檢查調用應用程序是否已被授予運營商權限的方法：
hasCarrierPrivileges。 - 覆蓋品牌和編號的方法：
- 直接 UICC 通信的方法：
- 將設備模式設置為全局的方法：
setPreferredNetworkTypeToGlobal。 - 獲取設備或網絡身份的方法：
- 國際移動設備識別碼 (IMEI)：
getImei - 移動設備標識符 (MEID)：
getMeid - 網絡訪問標識符 (NAI)：
getNai - SIM 序列號：
getSimSerialNumber
- 國際移動設備識別碼 (IMEI)：
- 獲取運營商配置的方法：
getCarrierConfig - 獲取數據傳輸網絡類型的方法：
getDataNetworkType - 獲取語音服務網絡類型的方法：
getVoiceNetworkType - UICC SIM (USIM) app信息獲取方法：
- SIM 序列號：
getSimSerialNumber - 卡片信息：
getUiccCardsInfo - GID1（組 ID 級別 1）：
getGroupIdLevel1 - 第 1 行的電話號碼字符串：
getLine1Number - 禁止公共陸地移動網絡 (PLMN)：
getForbiddenPlmns - 等效家庭 PLMN：
getEquivalentHomePlmns
- SIM 序列號：
- 獲取或設置語音信箱號碼的方法：
- 發送特殊撥號代碼的方法：
sendDialerSpecialCode - 重置無線調製解調器的方法：
rebootModem - 獲取或設置網絡選擇模式的方法：
- 請求網絡掃描的方法：
requestNetworkScan - 獲取或設置允許/首選網絡類型的方法：
- 檢查每個用戶設置是否啟用移動數據或漫遊的方法：
- 有理由檢查或設置數據連接的方法：
- 獲取緊急號碼列表的方法：
getEmergencyNumberList - 控制機會網絡的方法：
- 設置或清除蜂窩信號強度更新請求的方法：
電話回撥
TelephonyCallback具有帶有回調方法的接口，用於在註冊狀態更改時通知調用應用程序：
- 消息等待指示器發生了變化：
onMessageWaitingIndicatorChanged - 呼叫轉移指示符更改：
onCallForwardingIndicatorChanged - IP多媒體系統（IMS）呼叫斷開原因更改：
onImsCallDisconnectCauseChanged - 精確數據連接狀態改變：
onPreciseDataConnectionStateChanged - 當前緊急號碼列表已更改：
onEmergencyNumberListChanged - 活動數據訂閱 ID 已更改：
onActiveDataSubscriptionIdChanged - 運營商網絡變更：
onCarrierNetworkChange - 網絡註冊或位置/路由/跟踪區域更新失敗：
onRegistrationFailed - 限制信息變化：
onBarringInfoChanged - 當前物理通道配置改變：
onPhysicalChannelConfigChanged
訂閱管理器
- 獲取各種訂閱信息的方法：
- 獲取活躍訂閱數的方法：
getActiveSubscriptionInfoCount - 管理訂閱組的方法：
- 獲取或設置運營商與特定訂戶之間計費關係計劃描述的方法：
- 臨時覆蓋運營商和特定訂戶之間的計費關係計劃的方法被視為未計量：
setSubscriptionOverrideUnmetered - 臨時覆蓋運營商和特定訂戶之間的計費關係計劃以被視為擁塞的方法：
setSubscriptionOverrideCongested - 檢查具有給定上下文的應用程序是否有權根據其元數據管理給定訂閱的方法：
canManageSubscription
短信管理器
- 讓調用者創建新的傳入 SMS 消息的方法：
injectSmsPdu。 - 無需寫入 SMS 提供程序即可發送基於文本的 SMS 消息的方法：
sendTextMessageWithoutPersisting
運營商配置管理器
- 通知配置更改的方法：
notifyConfigChangedForSubId。 - 獲取默認訂閱運營商配置的方法：
getConfig - 獲取指定訂閱的運營商配置的方法：
getConfigForSubId
有關說明，請參閱運營商配置。
錯誤報告管理器
啟動連接錯誤報告的方法，它是錯誤報告的專門版本，僅包含用於調試連接相關問題的信息： startConnectivityBugreport
網絡統計管理器
- 查詢網絡使用摘要的方法：
querySummary - 查詢網絡使用歷史的方法：
queryDetails - 註冊或註銷網絡使用回調的方法：
ImsMmTelManager
- 註冊或註銷IMS MmTel註冊回調方法：
ImsRcsManager
- 註冊或註銷IMS RCS註冊回調的方法：
- 獲取 IMS 註冊狀態或傳輸類型的方法：
供應管理器
- 註冊和註銷 IMS 功能配置更新回調的方法：
- 與 IMS MmTel 或 RCS 能力的供應狀態相關的方法：
Euicc管理器
切換到（啟用）給定訂閱的方法： switchToSubscription
運營商消息服務
在發送或接收新的 SMS 和 MMS 時從系統接收呼叫的服務。要擴展此類，請在清單文件中使用android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE權限聲明服務，並使用#SERVICE_INTERFACE操作包含意圖過濾器。方法包括：
- 過濾入站短信的方法：
onFilterSms - 截取設備發送的短信的方法：
onSendTextSms - 截取設備發送的二進制短信的方法：
onSendDataSms - 截取設備發送的長短信的方法：
onSendMultipartTextSms - 攔截設備發送的彩信的方法：
onSendMms - 下載收到的彩信的方法：
onDownloadMms
承運人服務
向系統公開運營商特定功能的服務。要擴展此類，請在應用清單文件中使用android.Manifest.permission#BIND_CARRIER_SERVICES權限聲明服務，並使用CARRIER_SERVICE_INTERFACE操作包含意圖過濾器。如果服務具有長期綁定，請在服務的元數據中將android.service.carrier.LONG_LIVED_BINDING設置為true 。
該平台將CarrierService與特殊標誌綁定，讓運營商服務進程運行在一個特殊的應用程序備用桶中。這使運營商服務應用程序不受應用程序空閒限制，並使其在設備內存不足時更有可能保持活動狀態。但是，如果運營商服務應用因任何原因崩潰，它將失去上述所有權限，直到應用重新啟動並重新建立綁定。因此，保持運營商服務應用程序穩定至關重要。
CarrierService中的方法包括：
- 覆蓋和設置運營商特定的配置：
onLoadConfig - 通知系統運營商應用程序有意進行的運營商網絡更改：
notifyCarrierNetworkChange
電話供應商
允許對電話數據庫進行修改（插入、刪除、更新、查詢）的內容提供程序 API。值字段在Telephony.Carriers中定義；有關更多詳細信息，請參閱Telephony類參考
Wifi網絡建議
在構建WifiNetworkSuggestion對象時，使用以下方法設置訂閱 ID 或訂閱組：
- 設置訂閱ID的方法：
setSubscriptionId - 設置訂閱組的方法：
setSubscriptionGroup
安卓平台
在檢測到的 UICC 上，平台構建內部 UICC 對象，其中包括作為 UICC 一部分的運營商特權規則。 UiccCarrierPrivilegeRules.java加載規則，從 UICC 卡解析它們，並將它們緩存在內存中。當需要進行權限檢查時， UiccCarrierPrivilegeRules會將調用者證書與自己的規則一一進行比較。如果 UICC 被移除，則規則與 UICC 對像一起被銷毀。
驗證
要使用CtsCarrierApiTestCases.apk通過兼容性測試套件 (CTS)驗證實施，您必須擁有具有正確 UICC 規則或 ARF 支持的開發人員 UICC。要求您選擇的 SIM 卡供應商按照本節所述準備具有正確 ARF 的開發人員 UICC，並使用該 UICC 運行測試。 UICC 不需要有效的蜂窩服務即可通過 CTS 測試。
準備 UICC
對於 Android 11 及更低版本， CtsCarrierApiTestCases.apk由aosp-testkey testkey 簽名，哈希值為61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 。
從 Android 12 開始， CtsCarrierApiTestCases.apk由cts-uicc-2021-testkey簽名，哈希值CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0 。
要在 Android 12 中運行 CTS 運營商 API 測試，設備需要使用具有 CTS 運營商權限的 SIM 卡，以滿足最新版本的第三方GSMA TS.48 測試配置文件規範中指定的要求。
相同的 SIM 卡也可用於 Android 12 之前的版本。
修改 CTS SIM 配置文件
- 添加：訪問規則應用程序主 (ARA-M) 或 ARF 中的 CTS 運營商權限。兩個簽名都必須在運營商特權規則中進行編碼：
- 哈希1（SHA1）：
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 - 哈希2（SHA256）：
CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
- 哈希1（SHA1）：
- 創建： ADF USIM 基本文件 (EF) 不存在於 TS.48 中，但 CTS 需要：
- EF_MBDN (6FC7)，記錄大小：28，記錄數：4
- 內容
- 建議 1：566F696365204D61696CFFFFFFFF06915155555555FF…FF
- 記錄 2-n：FF…FF
- 內容
- EF_EXT6 (6FC8)，記錄大小：13，記錄數：1
- 內容：00FF…FF
- EF_MBI (6FC9)，記錄大小：4，記錄數：1
- 內容：Rec1：01010101
- EF_MWIS (6FCA)，記錄大小：5，記錄數：1
- 內容：0000000000
- 內容：00FF…FF
- EF_MBDN (6FC7)，記錄大小：28，記錄數：4
- 修改： USIM 服務表：啟用服務 n°47、n°48
- EF_UST (6F38)
- 內容：
9EFFBF1DFFFE0083410310010400406E01
- 內容：
- EF_UST (6F38)
- 修改： DF-5GS 和 DF-SAIP 文件
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- 內容：
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- 內容：
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- 內容：
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- 內容：
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- 內容：
A0020000FF…FF
- 內容：
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- 內容：
A0020000FF…FF
- 內容：
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- 修改：在包含此名稱的各個 EF 中使用運營商名稱字符串Android CTS ：
- EF_SPN (USIM/6F46)
- 內容：
01416E64726F696420435453FF..FF
- 內容：
- EF_PNN (USIM/6FC5)
- 內容：
Rec1 430B83413759FE4E934143EA14FF..FF
- 內容：
- EF_SPN (USIM/6F46)
匹配測試配置文件結構
下載並匹配以下通用測試配置文件結構的最新版本。這些配置文件不會對 CTS 運營商特權規則進行個性化或上面列出的其他修改。
運行測試
為方便起見，CTS 支持設備令牌，該設備令牌將測試限制為僅在配置有相同令牌的設備上運行。運營商 API CTS 測試支持設備令牌sim-card-with-certs 。例如，以下設備令牌將運營商 API 測試限制為僅在設備abcd1234上運行：
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
在不使用設備令牌的情況下運行測試時，測試會在所有設備上運行。
常問問題
如何在 UICC 上更新證書？
A：使用現有的卡OTA更新機制。
UICC能否與其他規則共存？
A：同一個AID下的UICC可以有其他的安全規則；平台會自動過濾掉它們。
為依賴於其上的證書的應用程序移除 UICC 時會發生什麼？
答：應用程序失去其權限，因為與 UICC 關聯的規則在 UICC 刪除時被破壞。
UICC上的證書數量有限制嗎？
A：平台不限制證書數量；但是因為檢查是線性的，太多的規則可能會導致檢查延遲。
我們可以使用此方法支持的 API 數量是否有限制？
答：不可以，但我們將範圍限制為與運營商相關的 API。
是否有一些 API 禁止使用此方法？如果是這樣，你如何執行它們？ （也就是說，您是否有測試來驗證此方法支持哪些 API？）
答：請參閱 Android 兼容性定義文檔 (CDD) 的API 行為兼容性部分。我們進行了一些 CTS 測試以確保 API 的權限模型不會更改。
這如何與多 SIM 卡功能一起使用？
A：使用用戶指定的默認SIM。
這是否以任何方式與其他 SE 訪問技術（例如 SEEK）交互或重疊？
答：例如，SEEK 使用與 UICC 上相同的 AID。因此規則共存並由 SEEK 或UiccCarrierPrivileges過濾。
什麼時候是檢查運營商特權的好時機？
A：SIM 狀態加載後廣播。
OEM 能否禁用部分運營商 API？
A：不。我們認為當前的 API 是最小集合，我們計劃在未來使用位掩碼進行更精細的粒度控制。
setOperatorBrandOverride是否覆蓋所有其他形式的運營商名稱字符串？比如SE13、UICC SPN，還是基於網絡的NITZ？
是的，運營商品牌覆蓋具有最高優先級。設置後，它將覆蓋所有其他形式的運算符名稱字符串。
injectSmsPdu方法調用有什麼作用？
A：這種方式便於短信在雲端備份/恢復。 injectSmsPdu調用啟用恢復功能。
對於短信過濾， onFilterSms調用是基於短信UDH端口過濾嗎？還是運營商應用程序可以訪問所有傳入的短信？
答：運營商可以訪問所有 SMS 數據。
支持 32 字節的DeviceAppID-REF-DO擴展似乎與當前的 GP 規範（僅允許 0 或 20 字節）不兼容，那麼您為什麼要引入此更改？ SHA-1 不足以避免衝突嗎？您是否已經提議對 GP 進行此更改，因為這可能與現有的 ARA-M/ARF 向後不兼容？
答：為了提供面向未來的安全性，此擴展在 SHA-1 的基礎上為DeviceAppID-REF-DO引入了 SHA-256，這是目前 GP SEAC 標準中的唯一選項。我們強烈建議使用 SHA-256。
如果DeviceAppID為 0（空），您是否將規則應用於特定規則未涵蓋的所有設備應用程序？
答：運營商 API 需要DeviceAppID-REF-DO 。為空用於測試目的，不建議用於操作部署。
根據您的規範，不應接受PKG-REF-DO單獨使用，沒有DeviceAppID-REF-DO 。但在規範的表 6-4 中仍將其描述為擴展REF-DO的定義。這是故意的嗎？當 REF-DO 中僅使用PKG-REF-DO REF-DO ，代碼的行為如何？
答：在最新版本中刪除了將PKG-REF-DO作為單值項在REF-DO中的選項。 PKG-REF-DO只能與DeviceAppID-REF-DO結合使用。
我們假設我們可以授予對所有基於運營商的權限的訪問權限或進行更細粒度的控制。如果是這樣，什麼定義了位掩碼和實際權限之間的映射？每個班級一個權限？每個方法一個權限？從長遠來看，64 個單獨的權限是否足夠？
A：這是留作以後用，歡迎提出建議。
您能否進一步專門為 Android 定義DeviceAppID ？這是用於簽署給定應用程序的發布者證書的 SHA-1（20 字節）哈希值，所以名稱不應該反映該目的嗎？ （該名稱可能會讓許多讀者感到困惑，因為該規則隨後適用於使用同一發布者證書籤名的所有應用程序。）
A：現有規範支持DeviceAppID存儲證書。我們試圖最大限度地減少規範更改以降低採用障礙。詳見UICC 規則。