Android 5.1 推出了一種機制，可為通用積體電路卡 (UICC) 應用程式的擁有者，授予 API 特殊權限。Android 平台會載入儲存在 UICC 上的憑證，並授予由這些憑證簽署的應用程式，以便呼叫少數特殊 API。
Android 7.0 擴充了這項功能，以支援 UICC 電信業者權限規則的其他儲存空間來源，大幅增加可使用 API 的電信業者數量。如需 API 參考資料，請參閱 CarrierConfigManager；如需操作說明，請參閱「電信業者設定」。
電信業者可以完全掌控 UICC，因此這項機制可讓使用者以安全又靈活的方式，透過一般應用程式發布管道 (例如 Google Play) 上代管的行動網路業者 (MNO) 管理應用程式，同時在裝置上保留特殊權限，也不需要使用個別裝置平台憑證簽署應用程式，也不需要預先安裝系統應用程式做為系統應用程式。
UICC 規則
UICC 上的儲存空間與
GlobalPlatform 安全元件存取權控制規格相容。資訊卡上的應用程式 ID (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 中的存取權控制規則檔案 (ACRF)，並尋找具有 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 - 行動裝置 ID (MEID)：
getMeid - 網路存取 ID (NAI)：
getNai - SIM 卡序號：
getSimSerialNumber
- 國際行動裝置識別碼 (IMEI)：
- 取得電信業者設定的方法：
getCarrierConfig - 取得資料傳輸網路類型的方法：
getDataNetworkType - 取得語音服務網路類型的方法：
getVoiceNetworkType - 取得 UICC SIM (USIM) 應用程式資訊的方法：
- SIM 卡序號：
getSimSerialNumber - 資訊卡資訊：
getUiccCardsInfo - GID1 (群組 ID 層級 1)：
getGroupIdLevel1 - 第 1 行電話號碼字串：
getLine1Number - 禁止的公共陸地行動網路 (PLMN)：
getForbiddenPlmns - 對等的住家 PLMN：
getEquivalentHomePlmns
- SIM 卡序號：
- 取得或設定語音信箱號碼的方法：
- 傳送特殊撥號代碼的方法：
sendDialerSpecialCode - 重設無線電數據機的方法：
rebootModem - 取得或設定網路選取模式的方法：
- 要求網路掃描的方法：
requestNetworkScan - 取得或設定允許/偏好網路類型的方法：
- 檢查是否已依使用者設定啟用行動數據或漫遊功能的方法：
- 檢查或設定數據連線的方法，原因如下：
- 取得緊急電話號碼清單的方法：
getEmergencyNumberList - 控制隨機網路的方法：
- 設定或清除行動網路訊號強度更新要求的方法：
TelephonyCallback
TelephonyCallback 具有具有回呼方法的介面，可在註冊狀態變更時通知呼叫應用程式：
- 訊息等待指標已變更：
onMessageWaitingIndicatorChanged - 來電轉接指標已變更：
onCallForwardingIndicatorChanged - IP 多媒體系統 (IMS) 通話中斷原因已變更：
onImsCallDisconnectCauseChanged - 精確的資料連線狀態已變更：
onPreciseDataConnectionStateChanged - 目前的緊急電話號碼清單已變更：
onEmergencyNumberListChanged - 有效的資料訂閱 ID 已變更：
onActiveDataSubscriptionIdChanged - 電信業者網路已變更：
onCarrierNetworkChange - 網路註冊或位置/路線/追蹤區域更新失敗：
onRegistrationFailed - 封鎖資訊變更：
onBarringInfoChanged - 目前的實體頻道設定已變更：
onPhysicalChannelConfigChanged
SubscriptionManager
- 取得各種訂閱資訊的方法：
- 取得有效訂閱項目數量的方法：
getActiveSubscriptionInfoCount - 管理訂閱項目群組的方法：
- 取得或設定電信業者與特定訂閱者之間的結帳關係計劃說明的方法：
- 方法：暫時覆寫運營商與特定訂閱者之間的帳單關係，以便視為未計量：
setSubscriptionOverrideUnmetered - 方法：暫時覆寫運營商與特定訂閱者之間的帳單關係，以便判斷是否壅塞：
setSubscriptionOverrideCongested - 方法：檢查具有指定內容的應用程式是否獲授權，可根據中繼資料管理指定的訂閱項目：
canManageSubscription
簡訊管理工具
- 讓呼叫端建立新傳入簡訊的方法：
injectSmsPdu。 - 方法：傳送文字簡訊，但不寫入簡訊供應器：
sendTextMessageWithoutPersisting
CarrierConfigManager
- 設定通知的方法已變更：
notifyConfigChangedForSubId。 - 取得預設訂閱項目的電信業者設定的方法：
getConfig - 取得指定訂閱項目的電信業者設定的方法：
getConfigForSubId
如需操作說明，請參閱「電信業者設定」一文。
BugreportManager
開始連線錯誤報告的方法，這是錯誤報告的專屬版本，僅包含用於偵錯連線相關問題的資訊：
startConnectivityBugreport
網路統計資料管理員
- 查詢網路用量摘要的方法：
querySummary - 查詢網路使用記錄的方法：
queryDetails - 註冊或取消登錄網路使用回呼的方法：
ImsMmTelManager
- 註冊或取消註冊 IMS MmTel 註冊回呼的方法：
ImsRcsManager
- 註冊或取消註冊 IMS RCS 註冊回呼的方法：
- 取得 IMS 註冊狀態或傳輸類型的方法：
ProvisioningManager
- 註冊及取消註冊 IMS 功能佈建更新回呼的方法：
- 與 IMS MmTel 或 RCS 功能佈建狀態相關的方法：
EuiccManager
切換至 (啟用) 指定訂閱項目的方法：
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 類別參考資料
WifiNetworkSuggestion
建構 WifiNetworkSuggestion 物件時，請使用下列方法設定訂閱 ID 或訂閱群組：
- 設定訂閱 ID 的方法：
setSubscriptionId - 設定訂閱群組的方法：
setSubscriptionGroup
Android 平台
在偵測到的 UICC 上，平台會建構內部 UICC 物件，並將電信業者權限規則納入 UICC。
UiccCarrierPrivilegeRules.java 會載入規則，從 UICC 卡片解析規則，並將規則快取到記憶體中。需要權限檢查時，UiccCarrierPrivilegeRules 會逐一比較呼叫端憑證與本身的規則。如果移除 UICC，規則也會一併刪除，以及 UICC 物件。
驗證
如要使用 CtsCarrierApiTestCases.apk 透過
Compatibility Test Suite (CTS) 驗證導入作業，您必須具備具備正確 UICC 規則或 ARF 支援的開發人員 UICC。請所選 SIM 卡供應商準備開發人員 UICC，並按照本節所述設定正確的 ARF，然後使用該 UICC 執行測試。UICC 不需要啟用行動服務，即可通過 CTS 測試。
準備 UICC
在 Android 11 以下版本中，CtsCarrierApiTestCases.apk 是由 aosp-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 卡，且該 SIM 卡必須符合最新版本第三方 第三方 GSMA TS.48 測試設定檔中的需求條件。
Android 12 以下版本也可以使用相同 SIM 卡。
修改 CTS SIM 卡設定檔
- 新增：存取規則應用程式主要執行個體 (ARA-M) 或 ARF 中的 CTS 電信業者權限。兩個簽章都必須在電信業者特權規則中編碼：
- Hash1(SHA1)：
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 - Hash2(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
- Hash1(SHA1)：
- 建立：TS.48 中沒有 ADF USIM 基本檔案 (EF)，但 CTS 需要這類檔案：
- EF_MBDN (6FC7)，記錄大小：28，記錄編號：4
- 內容
- Rec1: 566F696365204D61696CFFFFFFFF0691515555555FF…FF
- Rec2-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 支援裝置符記，可限制測試僅在使用相同符記設定的裝置上執行。Carrier API CTS 測試支援裝置權杖 sim-card-with-certs。舉例來說，下列裝置符記會限制電信業者 API 測試，只在裝置 abcd1234 上執行：
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
在不使用裝置權杖的情況下執行測試時，測試會在所有裝置上執行。
常見問題
如何在 UICC 上更新憑證？
答：採用現有的卡片 OTA 更新機制。
UICC 可以與其他規則並用嗎？
答：在相同 AID 下，UICC 上可以有其他安全性規則，平台會自動篩除這些規則。
如果應用程式需要依賴 UICC 上的憑證，移除 UICC 會有什麼影響？
答：由於與 UICC 相關聯的規則會在移除 UICC 時遭到銷毀，因此應用程式會失去權限。
UICC 上的憑證數量是否有限制？
答：平台不會限制憑證數量，但由於檢查是線性的，太多規則可能會導致檢查延遲。
這個方法支援的 API 數量是否有上限？
答：否，但範圍僅限於與電信業者相關的 API。
是否有某些 API 禁止使用這種方法？如果是的話，您會如何強制執行這些政策？(也就是說，您是否有測試來驗證這個方法支援哪些 API？)
答：請參閱 Android 相容性定義說明文件 (CDD) 中的「 API 行為相容性」一節。我們會執行一些 CTS 測試，確保 API 的權限模型不會變更。
多 SIM 卡功能如何運作？
答：系統會使用使用者指定的預設 SIM 卡。
這是否與其他 SE 存取技術 (例如 SEEK) 互動或重疊？
答：舉例來說，SEEK 會使用與 UICC 相同的 AID。因此，規則會並存，並由 SEEK 或 UiccCarrierPrivileges 篩選。
什麼時候適合檢查電信業者的權限？
答：在 SIM 卡狀態載入廣播之後。
原始設備製造商 (OEM) 可以停用部分電信業者 API 嗎？
答：否。我們認為目前的 API 是最低限的集合，並計劃日後使用位元遮罩，以便更精細地控制細節。
setOperatorBrandOverride 是否會覆寫所有其他形式的運算子名稱字串？例如 SE13、UICC SPN 或網路 NITZ？
是的，業者品牌覆寫為最高優先順序。設定後，會覆寫所有其他形式的運算子名稱字串。
injectSmsPdu 方法呼叫有何作用？
答：這個方法可在雲端中備份/還原簡訊。injectSmsPdu 呼叫會啟用還原函式。
在簡訊篩選方面，onFilterSms 呼叫是否依簡訊 UDH 通訊埠篩選？或者，電信業者應用程式是否可存取所有傳入的簡訊？
答：電信業者可存取所有簡訊資料。
DeviceAppID-REF-DO 的擴充功能似乎無法支援 32 位元，與目前的 GP 規格 (僅允許 0 或 20 位元) 不相容，那麼為何要引入這項變更？SHA-1 是否足以避免碰撞？您是否已提議對 GP 進行此變更，因為此變更可能會與現有的 ARA-M/ARF 回溯不相容？
答：為了提供未來可靠的安全性，這個擴充功能除了目前 GP SEAC 標準中唯一的選項 SHA-1 外，也為 DeviceAppID-REF-DO 導入 SHA-256。我們強烈建議使用 SHA-256。
如果 DeviceAppID 為 0 (空白)，您是否會將規則套用至未套用特定規則的所有裝置應用程式？
答：Carrier API 需要填入 DeviceAppID-REF-DO。留空僅供測試之用，不建議進行營運部署。
根據您的規格，如果 PKG-REF-DO 單獨使用，而沒有 DeviceAppID-REF-DO，則不應接受。但規格表 6-4 仍將其描述為擴充 REF-DO 的定義。這是特有用途嗎？當 REF-DO 中只使用 PKG-REF-DO 時，程式碼的行為為何？
答：最新版本已移除在 REF-DO 中將 PKG-REF-DO 設為單一值項目的選項。PKG-REF-DO 只能與 DeviceAppID-REF-DO 合併使用。
我們假設可以授予所有電信業者權限的存取權，或擁有更精細的控管機制。如果是，下列何者定義了位元遮罩和實際權限之間的對應關係？每個類別一個權限？每種方法分別具備一項權限嗎？64 個獨立權限是否足以應付長期需求？
答：我們會在日後推出這項功能，歡迎提供建議。
您能否進一步針對 Android 定義 DeviceAppID？這是用於簽署指定應用程式的發布者憑證的 SHA-1 (20 個位元組) 雜湊值，因此名稱應反映該用途。(這個名稱可能會讓許多讀者感到困惑，因為這項規則適用於所有使用相同發布商憑證簽署的應用程式)。
答：現有規格支援 DeviceAppID 儲存憑證。我們盡量減少規格變更，以降低採用門檻。詳情請參閱「UICC 上的規則」。