Introduction

The Android Automotive OS (AAOS) ecosystem demands robust and reliable over-the-air (OTA) update mechanisms. For custom AAOS hardware, implementing A/B (seamless) system updates from scratch is a critical step to ensure system resilience, minimize downtime during updates, and provide a fail-safe update path. This guide provides a detailed, expert-level walkthrough for configuring A/B partitions on your custom AAOS device, focusing on the underlying Android build system configurations and bootloader interactions.

A/B updates allow an OTA update to be applied while the system is running, then boot into the new system version upon reboot. If the new system fails to boot, the device can seamlessly revert to the previous working version. This significantly enhances user experience and system reliability, making it a mandatory feature for production-ready AAOS devices.

Understanding A/B Update Fundamentals

A/B updates work by maintaining two identical sets of partitions, commonly referred to as “slots” (Slot A and Slot B). While one slot is active and running the system, the other slot can receive an update in the background. Once the update is complete, the bootloader is instructed to switch to the newly updated slot on the next reboot. If the new slot fails to boot or encounters issues, the bootloader can revert to the previously working slot.

Key components:

• Slots A and B: Duplicated sets of critical partitions (system, vendor, product, etc.).
• Super Partition: A single physical partition that dynamically allocates space for logical partitions (system, vendor, etc.) across both slots. This allows flexible sizing and efficient use of storage.
• Bootloader: Responsible for selecting which slot to boot from and managing rollback logic.
• Update Engine: The Android component responsible for applying OTA updates to the inactive slot.

Prerequisites

Before you begin, ensure you have:

• A custom AAOS hardware platform with a working Android build.
• Access to the Android Open Source Project (AOSP) source code for your target Android version.
• A configured build environment and toolchain.
• Knowledge of your device’s partition layout and bootloader capabilities.

Step 1: Configuring Dynamic Partitions and A/B in BoardConfig.mk

The core of A/B partition setup resides in your device’s BoardConfig.mk file. This file defines the partitioning scheme, enables A/B updates, and configures dynamic partitions within a super partition.

Locate or create device/<vendor>/<device>/BoardConfig.mk and add the following configurations:

# Enable A/B OTA updatesAB_OTA_UPDATER := true# Enable dynamic partitionsPRODUCT_USE_DYNAMIC_PARTITIONS := true# Define the super partition size. This must be large enough to hold all# dynamic partitions for BOTH slots (A and B). For example, if system+vendor+product# is 4GB, then the super partition should be at least 8GB.BOARD_SUPER_PARTITION_SIZE := 8589934592 # Example: 8GB in bytes# Define groups for dynamic partitions. Typically, 'android_system' contains# system, system_ext, product, and 'android_vendor' contains vendor, odm.BOARD_SUPER_PARTITION_GROUPS := android_system android_vendor# List of dynamic partitions. These partitions will be created within the super partition.BOARD_<device>_DYNAMIC_PARTITIONS_PARTITION_LIST :=     system     vendor     product     odm     system_ext# Define sizes for partitions within each group. These are *maximum* sizes.# The actual space taken will be smaller for sparse partitions.BOARD_ANDROID_SYSTEM_PARTITION_SIZE := 4294967296 # Example: 4GBBOARD_ANDROID_VENDOR_PARTITION_SIZE := 2147483648 # Example: 2GB# Assign dynamic partitions to their respective groups.BOARD_<device>_DYNAMIC_PARTITIONS_IN_ANDROID_SYSTEM := system system_ext productBOARD_<device>_DYNAMIC_PARTITIONS_IN_ANDROID_VENDOR := vendor odm# Enable Android Verified Boot (AVB) for security. Essential for production.BOARD_AVB_ENABLE := trueBOARD_AVB_ROLLBACK_INDEX_LOCATION := "1"

Explanation:

• AB_OTA_UPDATER := true: Activates the A/B update mechanism.
• PRODUCT_USE_DYNAMIC_PARTITIONS := true: Enables Android’s dynamic partition feature, which is foundational for A/B updates leveraging the super partition.
• BOARD_SUPER_PARTITION_SIZE: Crucially, this must be large enough to accommodate both Slot A and Slot B versions of all listed dynamic partitions. For instance, if your combined system, vendor, and product images are 4GB, your super partition needs to be at least 8GB.
• BOARD_SUPER_PARTITION_GROUPS: Divides the super partition into logical groups, which can help in managing partition space and access control.
• BOARD_<device>_DYNAMIC_PARTITIONS_PARTITION_LIST: Lists all the partitions that will be managed as dynamic A/B partitions. These typically include system, vendor, product, odm, and system_ext.
• BOARD_ANDROID_SYSTEM_PARTITION_SIZE and BOARD_ANDROID_VENDOR_PARTITION_SIZE: These specify the maximum allowed sizes for partitions within their respective groups.
• BOARD_AVB_ENABLE := true: Enables Verified Boot, a critical security feature that ensures the integrity of the booted software.

Step 2: Fstab Configuration for Super Partition

Your device’s fstab.<device> file needs to instruct the kernel to mount the super partition correctly. This is usually a single entry for the physical super partition.

# <dev>                   <mnt_point>  <type>  <mnt_flags>                                <fs_mgr_flags>/dev/block/by-name/super /super       ext4    rw,barrier=1,discard,nosuid,nodev,noatime,errors=panic wait,logical,first_stage_mount

Ensure the <dev> path correctly points to your super partition as defined in your device’s partition table (e.g., in `platform_<soc>.dtsi` or similar).

Step 3: Bootloader Integration for Slot Management

The bootloader’s role is paramount for A/B updates. It must be aware of the active slot and be able to switch between slots based on commands from the Android system’s Update Engine.

• Boot Control HAL: Your bootloader needs to implement the Android boot_control HAL (Hardware Abstraction Layer). This HAL defines an API that allows Android to query the active slot, mark slots as successful, and switch slots for the next boot.
• Kernel Command Line: The bootloader passes the androidboot.slot_suffix parameter to the kernel command line (e.g., _a or _b) to indicate which slot is currently active. The Android system then uses this suffix to mount the correct root filesystem and dynamic partitions.
• Rollback Mechanism: Implement logic to revert to the previous slot if the newly updated slot fails to boot a specified number of times (e.g., using `boot_control_set_active_boot_slot` and `boot_control_mark_boot_successful`).

Specific bootloader modifications are highly platform-dependent (e.g., U-Boot, UEFI-based ABL). Consult your bootloader’s documentation or source code for integrating the boot_control HAL and handling slot selection.

Step 4: Building the AAOS Image

With BoardConfig.mk updated, you can now build your AAOS image. The build system will automatically generate the super.img and slot-aware partition images.

# Set up your environmentcd <AOSP_ROOT>source build/envsetup.sh# Select your device lunch <device_codename>-userdebug# Build the entire Android systemmake -j$(nproc)

This process will create the necessary images, including super.img, which contains the dynamic partitions.

Step 5: Initial Flashing of A/B Partitions

The first flash of your device with A/B partitions is crucial. The recommended method is to use the `fastboot update` command with a full OTA package, which correctly initializes the super partition and populates Slot A.

# Reboot device to bootloaderadb reboot bootloader# Flash the full image with the fastboot update commandfastboot update <path_to_your_ota_package>.zip

Alternatively, if you only have individual images, you might need to flash the super.img first, then flash individual partitions to their respective `_a` slots:

fastboot flash super super.imgfastboot flash boot_a boot.imgfastboot flash system_a system.imgfastboot flash vendor_a vendor.imgfastboot flash product_a product.img# ... and so on for all dynamic partitions to the '_a' slot

Remember to adjust partition names (`system_a`, `vendor_a`) based on your dynamic partition list.

Step 6: Testing A/B OTA Updates

After initial flashing, it’s time to test the A/B update mechanism.

1. Build a new OTA package: Make a minor change in your AOSP tree (e.g., a small text file, a build number increment), then rebuild and generate an OTA package. This can be a full OTA or a delta OTA from your currently flashed build.

# Example: Build a full OTA package for testingmake otapackage -j$(nproc)

2. Push and apply the OTA:

# Push the OTA package to the deviceadb push <path_to_ota_package> /data/ota_update/update.zip# Initiate the update via update_engine_clientadb shell update_engine_client --payload=file:///data/ota_update/update.zip --update --follow_progress# Monitor statusadb shell update_engine_client --status

3. Verify Slot Switching: Once the update reports completion, reboot the device.

adb reboot

4. Check active slot: After reboot, verify the active slot.

adb shell getprop ro.boot.slot_suffix

It should now show `_b` (or `_a` if it was `_b` before). You can also verify the new software version.

5. Test Rollback (Optional but recommended): If the new slot has a critical issue, manually mark it as unhealthy or cause a boot loop. The bootloader should detect this and revert to the previous working slot upon subsequent reboots. You can manually set the active slot for testing too:

# To manually set the active slot in bootloader (if supported)fastboot set_active b

Troubleshooting Common Issues

• Super Partition Size Mismatch: If BOARD_SUPER_PARTITION_SIZE is too small, your build will fail, or flashing will error out. Ensure it’s double the combined size of all dynamic partitions for one slot.
• Bootloader Not Switching Slots: Double-check your bootloader’s implementation of the boot_control HAL. Use `adb shell cmd boot_control get-slots` to inspect slot states from Android.
• OTA Package Generation Errors: Ensure all necessary signing keys are correctly configured and present.
• Verified Boot Issues: Incorrect AVB configurations or corrupted signatures can prevent booting. Check `dmesg` or kernel logs for AVB errors.

Conclusion

Configuring A/B partitions for AAOS on custom hardware is a multi-faceted process involving careful build system configuration, bootloader integration, and thorough testing. By following this guide, you can successfully implement a robust and reliable A/B update mechanism, crucial for the longevity and user experience of your Android Automotive device. This foundation ensures that future software updates are seamless, secure, and resilient against potential failures.