The Evolution of Android Updates: From A/B to Virtual A/B

Android’s update mechanism has undergone a profound transformation, moving from the once revolutionary A/B (Seamless) updates to an even more efficient system enabled by the super_partition and dynamic partitions, culminating in what’s known as Virtual A/B. This evolution not only streamlines the update process for end-users but also significantly alters the landscape for custom ROM developers, kernel hackers, and anyone deeply involved in Android system modifications. Understanding this architectural shift is crucial for navigating the modern Android ecosystem.

A/B Updates: The Foundation of Seamlessness

Before diving into super_partition, let’s briefly revisit traditional A/B updates. Introduced with Android 7.0 Nougat, A/B updates (also known as seamless updates) were designed to provide a more robust and user-friendly update experience. The core idea was simple: instead of having a single set of system partitions (e.g., system, vendor, boot), devices had two complete sets, ‘A’ and ‘B’.

• When an update arrived, it was applied to the inactive slot (e.g., if you were running on slot A, the update went to slot B).
• The user could continue using their device uninterrupted while the update downloaded and installed in the background.
• Upon reboot, the device would simply switch to the newly updated slot B.
• If any issues arose with the new update, the device could safely roll back to the previous, working slot A.

While a significant improvement in user experience and update reliability, traditional A/B updates had a major drawback: they required roughly double the storage space for system-related partitions. This was a non-trivial overhead, especially for devices with limited internal storage.

The Rise of system_as_root

Before the full advent of dynamic partitions, Android 9 Pie introduced system_as_root. This change unified the system partition and the root filesystem, which previously existed as a separate ramdisk within boot.img on non-A/B devices. With system_as_root, the system partition itself became the root filesystem. This simplification was critical for standardizing the partition layout and laid the groundwork for future advancements, particularly dynamic partitions.

Introducing super_partition and Dynamic Partitions

The real game-changer arrived with Android 10 and became widespread with Android 11: the super_partition, which enabled Dynamic Partitions. This innovation directly addresses the storage overhead of traditional A/B updates while retaining its benefits. Instead of fixed, separate physical partitions for system, vendor, product, odm, and system_ext, these are now logical partitions residing within a single, large physical partition called super_partition.

What is super_partition?

The super_partition is a large, physical block device that acts as a container for all the other system-related partitions. Inside super_partition, the Logical Partition Manager (LPM) creates and manages logical partitions like system, vendor, product, etc. These logical partitions are not fixed in size; they can be resized, created, or deleted dynamically as needed.

This means a device no longer needs separate physical system_a, system_b, vendor_a, vendor_b partitions. Instead, the super_partition can host logical partitions for both slots (e.g., system_a and system_b) and manage their storage allocation dynamically.

Key Benefits of Dynamic Partitions:

• Flexible Partition Sizing: OEMs can adjust partition sizes post-launch, allowing for more efficient use of storage space.
• Reduced Storage Overhead: Eliminates the need for full duplication of system partitions, saving significant space.
• Seamless Updates with Less Storage: Paves the way for Virtual A/B.

Virtual A/B: The Best of Both Worlds

Virtual A/B, sometimes referred to as ‘A/B with Dynamic Partitions’ or ‘Retrofit Dynamic Partitions’ (for devices upgraded to support it), combines the safety and seamlessness of A/B updates with the storage efficiency of dynamic partitions. Here’s how it works:

• Instead of maintaining a full inactive slot, Virtual A/B uses snapshots. When an update is available, the device creates a snapshot of the currently active logical partitions.
• The update is then applied to these snapshotted partitions. This process involves writing the new system images to new blocks within the super_partition, without affecting the active slot.
• Once the update is successfully installed, the device simply switches to the new, updated set of logical partitions on reboot.
• If the update fails, the device can revert to the pre-update snapshot, effectively rolling back the changes.

This approach significantly reduces the storage footprint required for updates because only the changes are stored, rather than a full duplicate system image. The fastbootd userspace daemon plays a critical role in managing and applying these updates within the super_partition environment.

Impact on Custom ROMs (LineageOS), Kernels, and Modding

The introduction of super_partition and Virtual A/B dramatically changes how custom ROMs are flashed and how developers interact with the underlying system.

Flashing Custom ROMs:

• No More Direct Partition Flashing: You can no longer reliably fastboot flash system system.img or fastboot flash vendor vendor.img individually if those are logical partitions within super_partition. The `fastboot` command needs to understand the dynamic partition layout.
• fastbootd Mode: Many devices now require booting into a special userspace fastbootd mode (accessible via adb reboot fastboot then fastboot reboot fastboot, or sometimes just fastboot reboot fastboot from OS) to perform flashing operations on dynamic partitions.
• Payload Updates: Custom ROMs often provide update packages (e.g., payload.bin based) that contain all necessary logical partition images, which are then installed via adb sideload or specific fastboot commands designed to interact with dynamic partitions.
• fastboot update Command: This command is often used with OEM-provided .zip packages that contain the necessary instructions and images for updating dynamic partitions.

Kernel and Boot Image Implications:

• The boot.img (containing the kernel and ramdisk) typically remains a physical partition outside the super_partition. Therefore, flashing a custom kernel using fastboot flash boot boot.img usually works as before.
• However, some devices use a ramdisk-less configuration, where the ramdisk is integrated into the system image. In such cases, flashing a kernel might involve modifying the system image or using specific tools.

Practical Commands and Checks:

To determine if your device uses dynamic partitions, you can use adb or fastboot:

adb shell getprop ro.boot.dynamic_partitions_enabled

If this returns true, your device uses dynamic partitions. You can also inspect partition layout from fastboot:

fastboot getvar all

Look for lines indicating logical partitions (e.g., (slot_a) is-logical:system:true or (slot_b) is-logical:vendor:true).

When flashing custom ROMs on devices with dynamic partitions, the process typically looks like this (consult specific device instructions for exact steps):

# Boot into fastbootd (sometimes needed) adb reboot fastboot fastboot reboot fastboot # Erase old partitions (if clean install is needed, careful!) # These commands are often specific to the ROM/device. # For instance, 'fastboot erase system' might not work directly. # Instead, it's often handled by the update package. # Flash the custom ROM package fastboot update /path/to/rom_package.zip # Or using adb sideload if flashing from recovery adb sideload /path/to/rom_package.zip # Reboot to new system fastboot reboot

For developers creating custom images, tools like lpmake are used to construct super_partition images with the correct logical partition layout.

Conclusion

The journey from traditional A/B updates to Virtual A/B via system_as_root and super_partition represents a significant leap forward in Android’s system architecture. It delivers more efficient storage utilization, enhances update reliability, and reduces user downtime. While it introduces a new layer of complexity for the custom ROM and modding communities, understanding these underlying changes is key to successfully developing, flashing, and maintaining custom Android experiences in the modern era. The Android ecosystem continues to evolve, and staying informed about these fundamental shifts is essential for any power user or developer.