This XDA blog How A/B Partitions and Seamless Updates Affect Custom Development on XDA has some Q&A's, of which :

  • My device supports A/B partitions, does that mean I can make use of a Project Treble Generic System Image?

Not necessarily. Project Treble and A/B support are unrelated. The Motorola Moto Z2 Force doesn’t support Project Treble, yet it supports the A/B partition scheme.

  • My device supports Project Treble, does that mean I have an A/B partition scheme?

This is not always the case. The Honor 9 Lite is a prime example as it supports Project Treble yet does not have an A/B partition scheme.

(Emphasis added)

I thought Treble and A/B devices are synonymous in the sense having one implied other. That's not the case

Why is this? What are the differences?


2 Answers 2


Both technologies have nothing in common, really, so everything is unrelated:

The A/B partition technology is the horizontal separation in the following image, whereas Project Treble defines the vertical separations inside each partition.

enter image description here Project Treble diagram source

A/B partition scheme

Basically the A/B partition scheme for "(Seamless) System Updates" is nothing more that two operating systems installed side-by-side, each in its own system partition. The unusual part (compared to e.g. having multiple OSes installed on a PC) is that both OS installations use the same user data partition. Also, when installing updates the active OS installation applies modifications to the other, inactive OS installation, instead of to itself.

The A/B partition layout does not make any assumptions about the OS that is installed inside the partition, hence it does not matter if the OS is Project Treble compliant or not.

Project Treble

Project Treble applies to the internals of each OS installation and how the different layers within the OS communicate with each other. Hence for Project Treble it is totally irrelevant if there are one, two or many OS partitions. The A/B partitioning scheme is compatible with, but separate from, Project Treble, and vice versa.


Operating System on Android devices consists of two major parts:

  • The generic Android code (AOSP) and
  • The code specific to hardware, provided by OEM/SoC vendor (mostly based on AOSP reference implementations).

Project Treble is targeted to separate AOSP code from vendor code so that each can be compiled and updated independently. HIDL (the communication layer between both code layers: HALs and AOSP framework) was specifically designed to achieve the goal. So now we have necessarily separate system and vendor/odm partitions. It resolved (or tried to resolve) the problem of delayed or no OTA updates from OEMs after device release.

A/B partitioning puts AOSP + vendor code on two identical pairs/slots of partitions (including boot, system and vendor). So that if OTA update fails on one slot, the other one continues to work. Also it makes updating the inactive slot possible while OS (active slot) is running, so doesn't affect user's work flow. This approach encourages OEMs to send more frequent updates, without any fears. As the official documentation states:

This approach reduces the likelihood of an inactive device after an update, which means fewer device replacements and device reflashes at repair and warranty centers.

At design level both are independent of each other (except that both involve partitions). Treble is relevant to OS (mostly userspace) i.e. how running processes from AOSP and vendor interact with each other (includes IPC based on binders). While A/B partitioning replaces the OTA update phenomenon which was previously based on recovery and cache partitions. So it involves necessary changes even to bootloader i.e. the logic: how it boots from different boot/system partitions, particularly after a failed OTA update. Once OS is loaded, A/B isn't of much concern (except when OTA update occurs).

So both innovations address different but somewhat related problems to achieve the same goal: more OTA updates. Also they collectively set the ground for dynamic partitions which let OEMs resize system/vendor/odm/product partitions during OTA updates as the AOSP and vendor code grows or shrinks.

  • 1
    Thank you for adding inputs and clarification. I liked the linkage to dynamic partitions. These are the kind of answers that enhance value of site content :-)
    – beeshyams
    Apr 14, 2020 at 17:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .