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.

APEX signing

Each APEX file is signed twice:

Once for the mini file system image (apex_payload.img file), see vbmeta signing.
Once for the entire APEX file, see APEX signing.

Manage APEX keys

Every APEX uses two unique keys: one for its mini file system image and another for the entire APEX file.

Test keys are used for development builds, while release keys are used to sign public builds. For best practices on release key management and the signing process, see Key management.

Non-pre-installed APEX

As described in pre-install trusted public keys, the public signing key for a non-pre-installed APEX's mini file system image must be pre-installed on the target partition. The OEM build server must populate the /partition/etc/brand_new_apex/ directory with the necessary release public keys for all potential non-pre-installed APEXes and ensure any test keys are removed.

APEX signing Stay organized with collections Save and categorize content based on your preferences.

Manage APEX keys

Non-pre-installed APEX

APEX signing