OTA Update Flow - Full

OTA Update Flow and A/B Architecture

Over-The-Air (OTA) updates in modern Android rely on A/B (Seamless) system updates. This architecture guarantees that a device remains operable even if an update fails during installation, and drastically reduces the time a user spends waiting for the update to apply during reboot.

The A/B Update Lifecycle

1. Server Push and Download: The OS update client (e.g., Google Play Services) communicates with the OTA server. Once an update is available, it hands over the download URL and metadata to the update_engine daemon.
2. Background Application: update_engine runs in the background. It downloads the OTA payload (which contains blocks of data) and writes them directly to the inactive partition slot. For example, if the device is currently running from Slot A, update_engine writes the new OS to Slot B.
3. Verification: After writing, the bootloader cryptographic signatures and dm-verity hashes are verified on the inactive slot.
4. Slot Switch and Reboot: update_engine marks the inactive slot as the new active slot. When the user reboots the device, the bootloader reads the active slot flag and boots into the newly updated OS (now Slot B).

// system/update_engine/payload_consumer/delta_performer.cc
bool DeltaPerformer::Perform() {
    while (buffer_.size() >= next_operation_size_) {
        InstallOperation operation;
        // Parse operation and apply blocks to inactive partition
        ApplyInstallOperation(operation);
    }
    return true;
}

Virtual A/B and Snapshot Merging

Traditional A/B updates require doubling the storage for system partitions (two system, two vendor partitions). To save space, modern Android uses Virtual A/B.

In Virtual A/B, there is only one base partition. During an OTA, the update_engine creates a Snapshot (a Copy-on-Write device). The updated blocks are written to the Snapshot, while the active system remains untouched.

Upon reboot, the device boots using the Snapshot. Once the device boots successfully, the system begins a Snapshot Merge in the background, applying the Snapshot data to the base partition. Until the merge completes, performance may be slightly reduced.

Rollback Conditions

If an OTA update is flawed, the device must not remain bricked. Android implements a robust fallback mechanism:

1. When booting into a newly updated slot, the bootloader marks the boot as "unsuccessful".
2. If the OS successfully boots to the home screen, the update_engine calls markBootSuccessful().
3. If the device crashes or reboots multiple times before marking the boot successful (a bootloop), the bootloader automatically switches the active slot back to the previous, working slot (e.g., back to Slot A).

Mainline Module Updates

Project Mainline allows Google to update core OS components via the Google Play Store (APEX files), bypassing the full OTA flow. APEX files are mounted early in the boot process via apexd. During an update, the new APEX is staged in /data, and upon reboot, apexd mounts the new version instead of the factory version in /system.

To monitor the update engine:

adb shell update_engine_client --status