Why Dual-Slot Updates Cost You 4GB of Flash Storage
Traditional dual-slot updates created an incredible user experience. But they came with a massive hidden cost. To keep the phone running while applying a new update, the system needed an entirely separate physical slot. If the core operating system required 4GB of space, duplicating it meant locking away 8GB of flash storage permanently. That duplication left budget devices with almost no room for user data.
Imagine buying a second house just in case your first one needs renovations. You leave it empty almost all year just for a few days of maintenance work. That is exactly what traditional A/B partitioning does to device storage. On a 32GB phone, losing a quarter of the total capacity to a dormant operating system is an unscalable business problem for OEMs.
First, notice in the architectural comparison below how traditional A/B duplicates the system partition completely. Second, see how single-slot designs only maintain one system copy. Third, observe the stark difference in user data capacity between the two models.
This storage difference becomes critical on budget devices.
Tip: In emerging markets where Android Go devices dominate, users frequently rely on 32GB hardware. Every gigabyte saved directly impacts their ability to install apps and store photos.
We need a way to keep the background update feature without duplicating the physical partitions. That exact requirement leads us to Virtual A/B.
The Illusion of Two Slots: How Virtual A/B Works
Virtual A/B removes the physical duplicate entirely. It tricks the Android bootloader into thinking a second slot exists. It accomplishes this illusion by combining the existing super partition with temporary space borrowed from the /data partition. You no longer dedicate permanent physical blocks to an inactive operating system.
Think of it like working on a draft document using a transparent plastic overlay. You can write your edits on the plastic scratchpad without permanently altering the original textbook underneath. Virtual A/B uses the exact same concept for system updates. It keeps the original base system intact and records only the new changes on a temporary layer.
First, observe in the storage model below that the super partition contains only a single system slot. Second, notice the temporary COW file residing inside the data partition. Third, look at how the kernel combines these two sources to present a unified virtual block.
This unified block operates exactly like a physical partition to the running OS.
Warning: Do not confuse Virtual A/B with Dynamic Partitions. Dynamic Partitions simply allow resizing logical volumes inside the super block. Virtual A/B eliminates the second static slot entirely.
You can verify if a device utilizes this architecture by checking its properties. Run adb shell getprop ro.virtual_ab.enabled to see if the flag returns true. Now that we know where the update is stored, we need to understand how the system applies it without corrupting the running OS.
Copy-on-Write and dm-snapshot: Modifying the Matrix
When an Over-The-Air (OTA) update arrives, the system cannot directly overwrite the running operating system files. Doing so would immediately crash the device. Instead, the Linux kernel employs a driver called dm-snapshot to create a microscopic snapshot of the active partition. This snapshot acts as a frozen reference state.
This update engine then begins a process called Copy-on-Write (COW). It downloads the update payload and streams the block changes directly to a new file in the /data partition. If a user is playing a graphics-heavy game, this background writing process happens entirely unnoticed. The system simply writes the exact differences to the temporary COW file.
Soon after, the system reboots. During this reboot, the bootloader intercepts the startup sequence. It uses the dm-snapshot driver to virtually merge the untouched base partition with the newly populated COW file. The operating system boots flawlessly into the updated framework as if it were reading from a single physical block.
First, observe how the update engine initiates a snapshot request to the kernel in the sequence below. Second, notice how it streams only the modified blocks into the temporary data file. Third, look at how the system reboots and virtually merges both sources to load the new framework.
The entire process happens without ever touching the currently active system files.
Did You Know: The COW file never contains a full copy of the operating system. It exclusively stores the specific block-level differences between the old version and the new version.
Ultimately, the phone reboots smoothly, but the update is not entirely finished yet. The required data is still split between the base partition and the COW file.
The Background Commit and VABC
Relying on a split file system permanently would severely degrade read performance over time. The system must eventually consolidate this data. Once the phone boots successfully, a background daemon slowly merges the contents of the COW file directly into the physical system partition. This background commit process ensures that the permanent storage eventually matches the updated state.
After the merge finishes, the system deletes the temporary COW file. This restores the borrowed space back to the user data partition. However, storing even a temporary file in /data during the download phase could trigger a storage full error on constrained devices. To mitigate this risk, Google introduced Virtual A/B Compression (VABC) in Android 12.
VABC automatically compresses the update blocks before writing them to the data partition. Think of this like zipping up your scratchpad notes so they do not take up too much desk space before you permanently type them into the final document. An OTA payload that would normally require two gigabytes of temporary space now only consumes about nine hundred megabytes.
First, track in the state diagram below how the update engine creates and compresses the file during the download phase. Second, follow how the daemon merges it into the primary partition after the device reboots. Third, note how the system deletes the file to reclaim user storage space.
This lifecycle guarantees that no temporary files permanently consume the user data partition.
Performance Note: Because the background commit happens while the user is actively using the phone post-reboot, you may notice a slight degradation in storage performance until the merge completes.
Today, Virtual A/B stands as the culmination of years of OTA evolution, balancing safety with storage constraints perfectly.
The Elegant Compromise
Android updates have traveled a long road of architectural changes. The platform evolved from the risky days of bricked phones during standard recovery flashes to the massive storage waste of traditional dual-slot updates. Virtual A/B finally delivers an elegant compromise between safety and efficiency. It protects users from boot loops without stealing their precious storage space.
Every snapshot, merge, and block write we discussed requires precise orchestration. Some master process must fetch the payload, verify the signatures, and command the kernel drivers. That orchestrator is the Update Engine daemon, which will be our focus in the next section.