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.

Service bundle updates

Service bundles can be updated as APEX packages, independently of full system updates. In SDV, this update process is managed by the SDV update manager. For an update to take effect, you must reboot the device.

Two types of APEX are supported for service bundle updates:

Pre-installed APEX: An earlier version of the APEX package already exists on one of the read-only partitions (/system, /system_ext, /product, /vendor, and /odm).
New APEX: No APEX package with the same name (as declared in apex_manifest.json) exists on any of the read-only partitions.

Pre-installed APEX

This is the most common and recommended method for updating service bundles. For this update to be valid, the new APEX package must meet these requirements:

Have the same package name in the apex_manifest.json as the pre-installed APEX.
Declare a higher version code in the apex_manifest.json than the pre-installed APEX.

Note: The pre-installed APEX must not use a version code of 0.
Sign the APEX with the same key pair as the pre-installed APEX.

New APEX

While using pre-installed APEXes is the security best practice, new APEXes are supported. When using this approach, partners are responsible for maintaining comprehensive security protocols. These responsibilities include:

Securely managing the signing keys used for these APEXes.
Establishing a robust process to identify and block malicious packages.
Converting new APEXes to pre-installed APEXes in subsequent system updates whenever possible.

To install or update a new APEX, the following configurations are required.

Pre-install trusted public keys

To install a new APEX, its public signing key must be pre-installed on the target partition. Place the public key in /partition/etc/brand_new_apex/, where /partition/ represents the partition where the APEX is associated with under Treble rules. For example, if an APEX's signature is verified against a public key in /vendor/etc/brand_new_apex/, it will behave as a vendor APEX. The system will reject any new APEX that is not signed by a key corresponding to a pre-installed public key.

Block a malicious new APEX

If a new APEX is identified as malicious after installation, it must be blocked using a system update. To do this, add the APEX package name to a blocklist file in /partition/etc/brand_new_apex/blocklist.json. This blocklist must be placed on the APEX's target partition (the same partition where its public key was pre-installed). Each partition has its own dedicated blocklist file.