Basic Understanding#
We can directly understand the v-a/b partition as follows: when you use your phone to perform a system upgrade, the upgrade content will be stored in the A partition, while you continue to use the B partition. The "V" in front stands for virtual. The upgrade is performed without affecting your use during startup, eliminating the complex operation of upgrading in the rec partition.
Detailed Understanding (My Opinion)#
First, let's talk about the structure. In the traditional structure, there are the rec, boot, and system partitions. In the V-ab structure, these three partitions are abandoned and replaced by boot_a, system_a, boot_b, and system_b. This is v-ab.
First, let's introduce the Δ (delta, lowercase δ) file. The Δ file is a copy-on-write (cow) file, literally meaning. For details, you can refer to the explanation on Wikipedia. Then, let's first open Google's official documentation: https://source.android.com/devices/tech/ota/virtual_ab#device-mapper. Please take a look at the "super" partition mentioned in it.
This partition is used to store Δ files. So, when performing some larger upgrades, the Δ file may be relatively large, and there may be insufficient space in the pre-allocated super partition. At this time, the excess files will be stored in /data. This situation mainly occurs in Android 11 because Android 10 reserved twice the logical partition space. The VAB partition of Android 10 itself is not native but modified based on dynamic partitioning.
So, when you perform an upgrade on an Android 11 phone in the on state, where can you view the files? You can check the following path: /data/gsi/ota, where there are a series of .img files with "cow" in their names. As for where they exist, it depends on the logical space size allocated by the system for the "super" partition.
Now let's look at the official documentation again: https://source.android.com/devices/tech/ota/virtual_ab#dm-snapshot-overview, specifically the DM Snapshot Overview section. It states:
Snapshot devices are created using the snapshot target. Writing to a snapshot device will write to a COW device. Whether reading from a snapshot device reads from the base device or the COW device depends on whether the snapshot has modified the accessed data.
This explains why after generating the cow file, the system changes the merge status of bootControl.hal to "snapshoted". If you are currently using the A space, the system will change your current system partition from system_a to system_a_cow when you switch to the B partition. At this point, you can still use your phone normally, but there may be a slight lag during the switching process.
After generating the cow file, the system prompts us to restart. We find that even after restarting, there is still a waiting time, similar to the previous rec reading cmd installation. So, what is the system doing during this time?
First, let's assume that you were using the A partition before the upgrade. After you power off, because the previous hal file has been changed to "snapshoted", at this time, the system will merge the corresponding old system partition with the Δ file. However, at this time, it is only loaded into memory and not a merged binary file. If the restart is successful at this time, the system will secretly merge the remaining binary files after booting up. At this time, the merge status of bootControl.hal will be changed to "merging". If there is a boot failure, the system will directly read the old system files for rollback (actually, it's not a rollback, just directly reading). The merge status of the hal file will be cleared only when the boot is successful, waiting for the next upgrade.
Seeing this, you may ask, this logic is actually similar to the previous reading and flashing script upgrade. The biggest difference here, besides partition upgrade, is a powerful point: when the status of bootControl.hal is "merging", you can restart your phone freely. Only when the status of bootControl.hal is "merging", it is considered a real system upgrade state. Next, let's explain why many phones still seem to have a similar effect to the previous phone upgrade. In fact, many manufacturers may add animations to this merging process... making it look like your phone has not entered the system, but in fact, the phone has entered the system, just without starting the desktop, showing you the merging progress. If you restart at this time, after the restart, the phone will continue to merge the remaining files, reducing the chances of crashes. Even if there is a crash, the phone will directly read the old system files, and you can re-upgrade!
Conclusion#
This is just my simple understanding. I have also read some articles online. Because Google's description of v-ab is basically non-existent... After reading the explanations of the experts, I realized that this thing is actually quite confusing (the part where the system replaces the system partition names...), but also quite powerful, reducing the possibility of system crashes caused by upgrades once a month, and gradually abandoning bl...
The only thing I feel sorry for is the flashers, as the learning cost of flashing has increased again...