A partition is simply a discrete section on the phone’s internal storage where data is kept. What kind of data is kept on each partition depends on the hardware, operating system, and many other factors. The bootloader will have one, the system (Android OS) will have one, the user data will have one… and so on and so forth. When you see people talk about “/system” and “/cache”, they’re referring to the given names for those partitions. The OnePlus 6, for example, has 72 partitions. That sounds like a lot, but the OnePlus 6 is one of the devices that supports seamless updates which means many of these partitions are simply duplicates of each other.
Partial output of the partitions on the OnePlus 6. Some A/B partitions are underlined for demonstration purposes.
For the vast majority of Android users, the partitions that we mostly deal with are system, boot, recovery, userdata and more recently vendor and vbmeta.
Here’s a brief explanation of the purpose of each partition:
Device OEMs can change their partition schemes to use whatever layout they want. There are also a lot of extra partitions that may contain other system apps such as cust, product, and oem, and while these are safe to modify, it’s generally not recommended if you want to make it easier on yourself to return to stock. So where do A/B partitions play a role?
The very simple image below illustrates how an update is handled on a device with A/B partition support. The partition that is illustrated is the system partition, though other partitions such as boot and vendor may also be updated with any given OTA update from an OEM. This update process happens with not only major Android version updates but also security patch updates.
What are the benefits of this update process?
What impact does the A/B partitioning scheme have on the storage of a device?
Does the fact that seamless updates result in a bunch of duplicated partitions mean you’re losing a bunch of storage space? Not at all. Google says that devices with seamless update support should only be down about a few hundred Megabytes thanks to removing the /cache and /recovery partitions. Removing both balances the cost of adding a second set of partitions. According to Google, the Pixel’s A/B system image is half the size of the A-only system image. Most of the additional storage usage actually comes from the addition of a second vendor partition. That makes sense as the vendor partition houses all of the proprietary binaries used by OEMs (part of Project Treble), so it’s expected to take up quite a bit of space. While Google doesn’t recommend having A/B partitioning on devices with 4GB of storage (as it’s nearly 10% of total available storage), they do recommend it on devices with 8GB and higher.
Here’s a breakdown of the storage space used on a Google Pixel with and without A/B partitions.
To check this download an app called treble check from playstore.
When building a ROM, developers can make use of both partitions to test separate builds. If one doesn’t work, they can just revert back to the working partition and rebuild their ROM. Developers can also test for regressions by simply installing an update, switching the active partition, and comparing the two without having to wipe data. Here’s how the LineageOS team views A/B partition support:
“Many around the Android community have bashed A/B as being ‘hard to support’ and ‘not developer friendly’, when in fact, properly implemented it is easier to support and just as developer friendly.” – jrizzoli, LineageOS Changelog 19
The initial difficulty with A/B support for developers came from modifying their existing tools to support these devices. The developer of Magisk, topjohnwu, added official support for the Google Pixel a year after it was released—not because it was difficult, but rather because it took him a year to actually obtain the device to work on. TWRP support came pretty quickly on A/B devices after the lead developer, Dees_Troy, took a crack at it. LineageOS 15.1 now supports A/B devices after volunteers found time to fix their addon.d script.
A common misconception is that having Project Treble support and A/B partition support are related to one another, but that’s not actually the case. Having one does not imply the other. The Motorola Moto Z2 Force uses an A/B partitioning scheme but doesn’t support Treble. On the other hand, the Honor 9 Lite supports Project Treble, yet is an A-only device.
What are the benefits of A/B partitioning?
How do A/B partitions affect mods such as custom kernels, Magisk, or Xposed?
Does having an A/B partition scheme mean that I have reduced storage?
My device supports A/B partitions, does that mean I can make use of a Project Treble Generic System Image?
My device supports Project Treble, does that mean I have an A/B partition scheme?
Are there any dangers with A/B partitions? How does rollback protection affect things?
Solved! Go to Solution.