自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
远程密钥配置
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
从 Android 12 开始，远程密钥配置 (RKP) 已成为 AOSP 的一部分。Android 14 引入了远程配置可更新模块，该模块可提高服务 API 的稳健性并缩短向其引入任何改进的时间，从而提高功能弹性。
设计初衷
通过将所有内容封装到 APEX 来简化 RKP 服务。
在 Android 14 之前，RKP 拆分为应用 RemoteProvisioner 和密钥库 2.0。RemoteProvisioner 应用负责与 RKP 后端通信，密钥库 2.0 负责存储密钥以及与 HAL 通信。这不是一个好的架构，因为在附加的元数据方面，RKP 密钥与密钥库密钥有很大不同。此外，还需要对密钥库框架代码进行复杂的修改，以提醒 RemoteProvisioner 可能存在资源不足问题。
作为 Mainline 模块，RKP 旨在通过巧妙地将所有内容打包到 APEX 中来改进这些方面。
模块边界
RKP Mainline APEX com.android.rkpd 包含远程密钥配置守护程序 (RKPD) 应用和远程配置系统服务器组件（使用 Java 构建）。
堆栈架构
图 1 展示了 RKP 堆栈架构。
图 1. RKP 堆栈架构。
内部架构
图 2 展示了 RKP 内部架构。
图 2. RKP 内部架构。
有关 RKP 内部架构的更多信息：
模块的应用和其他功能都会被打包为 APEX 文件 com.android.rkpd。
依赖项
RKP 模块仍然依赖于 IRemotelyProvisionedComponent 实现是否存在，以提供认证密钥和证书请求。
测试策略
应用 APEX 的 AOSP 版本包含原始设备制造商 (OEM) 可以运行的单元测试。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-03-11。
[[["易于理解","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"]],["最后更新时间 (UTC)：2025-03-11。"],[],[],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."]]
