com.google.android.rkpdapp Copy

The Google-signed build of the Remote Key Provisioning Daemon (RKPD), labelled "RemoteProvisioner" on device. It is the same component this site documents under the AOSP-keyed name com.android.rkpdapp, shipped under a Google package name; the app still declares its internal broadcast permission under the com.android.rkpdapp namespace, which is consistent with one codebase built under two package names. AOSP places the app inside the Remote Key Provisioning Mainline APEX, stating that "The RKP Mainline APEX, com.android.rkpd, contains the Remote Key Provisioning Daemon (RKPD) application and a remote provisioning system server component". Its job is to obtain attestation certificates for the device's IRemotelyProvisionedComponent implementations, which is why it holds internet, network state and boot permissions and has no launcher entry. Remote Key Provisioning replaces the older model in which attestation keys were burned into a device at the factory. AOSP records that "Android 12 introduces Remote Key Provisioning, and Android 15 requires all devices to implement it", and that it "provides devices in the field with per app, ECDSA P256 attestation certificates" which "are shorter-lived than the factory-provisioned certificates". Android 14 is where RKP became an updatable Mainline module; before that the work was split between a RemoteProvisioner app and Keystore 2.0. Version note: the version dimension is the important part of this entry, and it continues past the Mainline change. Google's developer documentation states that "For devices that launch with Android 16, the system supports only RKP. This policy phases out factory keys", and describes this as "expanding on the Android 15 policy where RKP support was optional". Be aware that the two official pages describe Android 15 differently, and this note does not attempt to resolve the difference. AOSP says Android 15 "requires all devices to implement it", while the developer documentation calls Android 15 the release "where RKP support was optional". The most likely reading is that the two are talking about different things, one about a device supporting RKP at all and the other about RKP being the only mechanism, but that reconciliation could not be sourced and should not be relied on. What both pages agree on is the Android 16 position: on devices launching with Android 16, factory-provisioned attestation keys are out and RKP is the only route. That matches what this site records for this package name: the sample begins at version name 16 with a minimum target SDK of 35, and the newest observation carries a release codename rather than a version number, so this Google-namespaced variant is something seen on recent and preview firmware rather than across the whole history of RKP. The site's sample spans Crosscall, Fairphone, Google, OPPO, OUKITEL, OnePlus, URAO, Xiaomi, motorola, samsung and vivo devices, signed Google rather than by each maker's platform key, which distinguishes it from the AOSP-keyed variant. For Android Enterprise, EMM and kiosk fleets this is security infrastructure rather than a feature. The certificates it obtains are what hardware-backed key attestation chains up to, so anything that verifies device integrity or relies on hardware-backed keys depends on this pipeline working. Google also notes an operational consequence of the newer model that matters when troubleshooting: RKP certificates have a shorter validity period, and it is "critical" that verifiers "ensure that Remote Key Provisioning (RKP) certificates continue to have their validity period checked". Disabling or removing this package risks breaking attestation for every app on the device that uses it, and it offers no management benefit, so it should not be disabled.

• Remote Key Provisioning - Android Open Source Project →
• Key and ID attestation - Android Open Source Project →
• Verify hardware-backed key pairs with key attestation - Android Developers →
• Package provenance for com.google.android.rkpdapp - Android System App Database →

• Signed by Google's own signing key (the same key Google uses across devices), so it is a Google-provided preinstall that updates independently of the system image, though 2 different Google signing keys appear across the fleet. This certificate spans 10 device makes - the hallmark of a globally distributed Google key.
• Its largest observed manifest declares 10 permissions: 1 signature or system-level, 6 install-time and 3 vendor or uncatalogued.
• Never reported as user-facing, so it runs as a background or system component rather than an app the user opens.