自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
遠端金鑰佈建
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
自 Android 12 起，遠端金鑰佈建 (RKP) 就已是 AOSP 的一部分。Android 14 推出可更新的遠端佈建模組，可透過改善服務 API 的健全性，並縮短導入任何改善項目的時間，進而提升功能的彈性。
動機
將所有內容封裝成 APEX，簡化 RKP 服務。
在 Android 14 之前，RKP 已分離為應用程式 RemoteProvisioner 和 KeyStore 2.0。RemoteProvisioner 應用程式負責與 RKP 後端聯絡，Keystore 2.0 則負責儲存金鑰並與 HAL 通訊。這並非理想的架構，因為 RKP 金鑰與 Keystore 金鑰在附加中繼資料方面有顯著差異。此外，這項作業需要對 Keystore 架構程式碼進行不便的修改，才能提醒 RemoteProvisioner 可能發生資源耗盡的情況。
RKP 是 Mainline 模組，旨在將所有內容整齊地打包至 APEX，以改善這些問題。
模組邊界
RKP Mainline APEX (com.android.rkpd) 包含遠端金鑰佈建 Daemon (RKPD) 應用程式和遠端佈建系統伺服器元件 (以 Java 建構)。
堆疊架構
圖 1 說明 RKP 堆疊架構。
圖 1. RKP 堆疊架構。
內部架構
圖 2 說明 RKP 內部架構。
圖 2. RKP 內部架構。
關於 RKP 內部架構的其他資訊：
模組的應用程式和其他功能會封裝為 APEX 檔案 com.android.rkpd。
依附元件
RKP 模組仍會依賴 IRemotelyProvisionedComponent 實作項目的存在，以提供認證金鑰和憑證要求。
測試策略
應用程式 APEX 的 AOSP 版本包含原始設備製造商 (OEM) 可執行的單元測試。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# Remote Key Provisioning (RKP) has been a part of AOSP since Android\n12. Android 14 introduces a\nremote provisioning updatable module that increases feature resilience by\nimproving the robustness of the service API and decreasing the time to\nintroduce any improvements to it.\n\nMotivation\n----------\n\nSimplify the RKP service by packaging everything into an APEX.\n\nBefore Android 14, RKP was separated into an app,\n`RemoteProvisioner`, and Keystore 2.0. The `RemoteProvisioner` app was\nresponsible for contacting the RKP backend, and Keystore 2.0 was responsible for\nboth storing the keys and communicating with HALs. This wasn't a good\narchitecture because RKP keys are significantly different from Keystore keys in\nterms of attached metadata. Additionally, this required awkward modifications to\nthe Keystore framework code to alert `RemoteProvisioner` about potential\nresource starvation.\n\nRKP as a Mainline module is designed to improve on these points by neatly\npacking everything into an APEX.\n\nModule boundary\n---------------\n\nThe RKP Mainline APEX, `com.android.rkpd`, contains the Remote Key Provisioning\nDaemon (RKPD) application and a remote provisioning system server component\n(built with Java).\n\n### Stack architecture\n\nFigure 1 illustrates the RKP stack architecture.\n\n**Figure 1.** RKP stack architecture.\n\n### Internal architecture\n\nFigure 2 illustrates the RKP internal architecture.\n\n**Figure 2.** RKP internal architecture.\n\nAdditional information about the RKP internal architecture:\n\n- RKPD Mainline APEX - `com.android.rkpd`\n\n - RKPD app (Java)\n - `packages/modules/RemoteKeyProvisioning/app`\n - RKPD system server fragment (Java)\n - `packages/modules/RemoteKeyProvisioning/system-server`\n- HAL interface/implementation (Rust/C++)\n\n - `IRemotelyProvisionedComponent`\n - `hardware/interfaces/security/keymint`\n\nPackage format\n--------------\n\nThe application and other functionalities of the module are packaged as APEX\nfile `com.android.rkpd`.\n\nDependencies\n------------\n\nThe RKP module continues to depend on the existence of\n`IRemotelyProvisionedComponent` implementations to provide the attestation keys\nand certificate requests.\n\nTesting strategy\n----------------\n\nThe AOSP version of the application APEX contains unit tests that OEMs can run."]]
