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.

A/B system updates

SDV follows the standard Android approach of A/B (seamless) system updates. The AOSP documentation applies primarily to SDV. This page details usage specific to SDV and known good paths for building and applying update packages.

At the moment SDV is configured to use non-virtual A/B updates.

Implement the boot control HAL

The SDV Core image for Cuttlefish (sdv_core_cf) provides a standard implementation of the boot control HAL based on hardware/interfaces/boot/aidl/default/. Other bootloaders must implement the HAL to support A/B updates.

Refer to the Implement the boot control HAL section of the AOSP documentation for details. You can use bootctl included on debug (eng and userdebug) SDV images to test the implementation.

Generate an OTA package

To learn more, see: Build OTA packages. The instructions in this page follow the AOSP documentation with minor deviations.

Full update

From the repository root:

source build/envsetup.sh && lunch sdv_core_cf-trunk_staging-userdebug
mkdir dist_output
m dist DIST_DIR=dist_output

These commands produce target files in the dist_output directory. For local builds of sdv_core_cf this is normally sdv_core_cf-target_files-$USER.zip.

To produce an OTA package, you need to use ota_from_target_files. Unlike in AOSP, the package is not built as a part of m dist.

m ota_from_target_files
ota_from_target_files \
  dist_output/sdv_core_cf-target_files-$USER.zip \
  ota_update.zip

Incremental update

Same ota_from_target_files invocation as in AOSP:

ota_from_target_files \
  -i PREVIOUS-sdv_core_cf-target_files.zip \
  dist_new/sdv_core_cf-target_files-$USER.zip \
  incremental_ota_update.zip

Install an OTA package

Updates are installed using the update_engine service. Debug SDV builds include update_engine_client which can be used to debug and test the update process.

To install an OTA package run:

system/update_engine/scripts/update_device.py ota_update.zip

If the update is installed correctly (the final status is UPDATE_STATUS_UPDATED_NEED_REBOOT and the result is ErrorCode::kSuccess), the update will be activated on the next reboot.

Versioning

For system updates, SDV uses Android's OTA package metadata to determine if an OTA package fulfills the requirements and can be installed.

Also for APEX, SDV follows Android's concepts regarding updatabilty. Therefore, an APEX can be updated when the APEX is not a bootstrap APEX. Bootstrap APEX must be updated through system updates, and either:

The declared version is higher than the preinstalled version, and both are larger than or equal to 1,

or,

The declared version is a non-preinstalled APEX and the version is higher than the version in the denylist, if listed.

SDV is typically deployed to multiple systems in a network. Therefore, you must ensure updates made to a single system are correctly executed. Still, this care doesn't guarantee that all systems can communicate properly.

It's equally critical that you update the overall network, which requires that updates to service bundles are either deployed to all machines at the same time or that updates contain no breaking changes. For example, incompatible changes to the interface.

Although SDV doesn't provide tooling to detect incompatible changes, our guidelines describe how to reconcile changes made to interfaces as well as the best practices needed to deploy the changes.

In addition, SDV supports rollback mechanisms for system and APEX updates. If the system unintentionally enters a dissatisfactory state, we can recover the last known satisfactory state.