Effective in 2026, to align with our trunk stable development model and ensure platform stability for the ecosystem, we will publish source code to AOSP in Q2 and Q4. For building and contributing to AOSP, we recommend utilizing android-latest-release instead of aosp-main. The android-latest-release manifest branch will always reference the most recent release pushed to AOSP. For more information, see Changes to AOSP.

SDV profile for DICE

The SDV Profile for the Device Identifier Composition Engine (DICE) is an extension of the Android Profile for DICE. In SDV, a VM uses two parallel DICE chains:

Secure World DICE chain
Android SDV DICE chain

These fields from the Configuration descriptor of the Android Profile for DICE are relevant to each of these chains:

Name	Key	Type	Description
Component name	`-70002`	`tstr`	Recommended on each CDI layer. Component name unambiguously identifies the stage among all the DICE chains of hardware that run Android SDV VMs on a vehicle or vehicle platform.
Security version	`-70005`	`uint`	Required on each CDI stage. Enables defining a DICE policy that prevents unsecure remote VM versions from joining the SDV secure mesh.
Component Instance Name	`-70007`	`tstr`	Required on the first VM specific CDI layer. For example, after the hypervisor, for Android SDV DICE chain. Name of the SDV instance. If multiple CDI layers contain the component instance name, each layer must have the same value.

Secure World DICE chain

The Secure World DICE chain is the same that Android's Remote Key Provisioning (RKP) server receives from Android devices. The IRemotelyProvisionedComponent HAL's generateCertificateRequestV2() exposes this DICE chain to Android.

This table depicts a sample Secure World DICE chain:

Boot stage	DICE CDI layer	Issued by
Primary bootloader	`CDI[0]`	UDS
Secondary bootloader	`CDI[1]`	Primary bootloader
TEE boot	`CDI[2]`	Secondary bootloader
KeyMint TA boot	`CDI[3]` (Leaf)	TEE

To implement the KeyMint trusted application (TA), use one of these options:

Single KeyMint instance for all SDV VMs: You MUST designate a single CDI for all VMs.

or,

One KeyMint instance for each SDV VM: You MUST designate a different CDI value for each VM. Individual CDI values MUST contain a Component Instance Name that matches the VM's Component Instance Name.

Android SDV DICE chain

The Android SDV DICE chain certifies the software running on the boot path leading through the hypervisor to the Android high-level operating system (HLOS) running on the SDV VMs.

This table depicts a sample Android SDV DICE chain:

Boot stage	DICE CDI layer	Issued by
Primary bootloader	`CDI[0]`	UDS
Secondary bootloader	`CDI[1]`	Primary bootloader
Hypervisor	`CDI[2]`	Secondary bootloader
Android HLOS	`CDI[3]` (Leaf)	(Android loader in the) Hypervisor¹

¹ Hypervisor certifies the Android bootloader in the guest as a layer. Android bootloader certifies the Android HLOS.

Android HLOS CDI Certificate

The Android Bootloader (or the Hypervisor, if there's no Android bootloader but just an Android "loader" program that loads the VM within the Hypervisor) signs the Android HLOS CDI Certificate and covers the Android HLOS. For example, it covers all code the Android Bootloader verifies according to Android Verified Boot (AVB).

The Android HLOS CDI Certificate must contain SDV-specific values of the Android OS that mitigate security vulnerabilities. For example, potential secret leakage by banning VMs with known vulnerabilities from the SDV Secure Mesh. The AVB verification provides most of these values.

They're also handed over to the KeyMint in the TEE, where the certificate is signed by the leaf CDI of the SecureWorld DICE chain, and passed to Android in the DeviceInfo for enabling features like Key and ID attestation in core Android.

Code input and codeHash certificate fields

The VBMeta digest (an output the Android bootloader performs for the AVB verification) covers the software of the Android HLOS. Therefore, it serves as the android-dice-input-values for deriving the CDI secrets, and it goes into the dice-cert-fields field of the CDI certificate.

The recommended hash algorithm for AVB is SHA-256 which results in a 32 bytes long VBMeta digest. In contrast to the Open Profile for DICE, the Android Profile for DICE allows android-dice-hash-algos using 32 bytes long android-dice-input-values for the DICE flow as well as placing the same 32 bytes long value as the codeHash in the DICE certificate.

Configuration descriptor: fields in Android Profile for DICE

Beyond what's described for all CDI layers, the following specifics apply to the Configuration descriptor fields from the Android Profile for DICE:

Name	Key	Type	Description
Component version	`-70003`	`int`	The system OS version from AVB `version-info-avb`. Also the same as `android.os.Build.VERSION.release`.
Security version	`-70005`	`uint`	The security patch level of the `system` partition in `YYYYMMDD` format.
RKP VM marker	`-70006`	`null`	The RKP VM marker prevents the : Remote Key Provisioning from issuing certificates for the Android SDV DICE chain.

The RKP VM marker must appear in the first CDI certificate of the Android SDV DICE Chain that is not in common with the Secure World DICE chain. It also must NOT appear in any further CDI certificates to prevent the RKP server rkp-avf-support from considering the DICE chain as coming from an RKP VM.

Configuration descriptor: new fields

The Android HLOS CDI Certificate's Configuration descriptor must contain SDV specific values beyond the ones the Android Profile for DICE describes. The SDV Profile for DICE reserves the key value range [-71000, -71999] for this purpose. You can add implementation-specific fields using key values outside of the reserved range. The SDV specific values are:

Name	Key	Type	Description
Verified boot state	`-71000`	`tstr`	Either `green`, `yellow` or `orange`.
build fingerprint	`-71001`	`tstr`	Human-readable string that uniquely identifies this build, the same as `ro.build.fingerprint`. The Android CDD, 3.2.2 Build Parameters, `cdd-3-2-2` defines this. VBMeta stores this as the property named, `com.android.build.system.fingerprint`
`system_ext` security patch level	`-71002`	`uint`	Security patch level of the `system_ext` partition in `YYYYMMDD` format.
`product` security patch level	`-71003`	`uint`	Security patch level of the `product` partition in `YYYYMMDD` format.
`vendor` security patch level	`-71004`	`uint`	Security patch level of the `vendor` partition in `YYYYMMDD` format.
`boot` security patch level	`-71005`	`uint`	Security patch level of the `boot` partition (which contains the Linux Kernel) in `YYYYMMDD` format.
SDV boot mode	`-71006`	`tstr`	`locked` or `unlocked`. To learn more, see Mesh Status and Provisioning.

Mode input value selection of Android HLOS CDI

The android-dice-mode of the Android HLOS CDI certificate uses the following definition:

	AVB UNLOCKED	AVB LOCKED
SDV boot mode UNLOCKED	Debug	Debug
SDV boot mode LOCKED	Not configured (invalid)	Normal

Key derivation function

The android-dice-kdf that derives the public and private key pair from the CDI_Attest secret for the Android HLOS CDI must be HKDF with SHA512 as its hash function.