• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

What are A-only GSIs used for? And why don't we just call these "Non-SAR"?

Search This thread
As far as I understand, in A-only GSIs the system partition (the GSI image) just contains the system files (the contents of $TARGET_ROOT_OUT in the build process). This whole partition is then mounted as /system in the OS.

By contrast, A/B GSIs have these same contents in the /system directory within the GSI image/partition. The root of the partition itself is then set as root (i.e. system-as-root, SAR) in the OS. As such, /system is not a mount point anymore, but a normal directory. The root of the image/partition (SAR) contains the init files etc. for booting (which in A-only setups reside on the ramdisk in the boot partition, so they are missing from an A-only GSI).

These are basically the only differences between the two, or rather: the former A-only GSI is for a non-SAR system; the latter A/B GSI is for a SAR-system. It is explained here, that these differences are minor and you can relatively simply convert a GSI image from A-only to A/B or back. (Back to A-only is even easier because you don't need all the root files.) Now, the manner in which /system is stored and where the root files are (SAR or not) does not seem to have anything to do with having a dual slot A/B system (for seamless OTA updates) or a single slot system (A-only). But apparently it does, since the names clearly say A-only and A/B. So let's find out where that comes from.

First of all about the SAR definition: Google's definition differs from what you'd expect. You can read about this in the Android documentation. New Android versions don't use SAR according to Google, as they do not first boot from the system partition. Instead, the new "method C devices" boot from ramdisk and then in a second stage boot the system partition; the older, "method B devices" boot from system directly and hence only those are called SAR by Google.

However, for all intents and purposes, SAR could just as well be defined as the system image/partition being the root partition, regardless if you boot from it in a single stage or not. Then, SAR corresponds to having a system image/partition like is done in A/B GSIs that you download from this forum, as mentioned above in the 2nd paragraph. We uphold this definition therefore, as does the documentation from the utility tool Magisk.

On this documentation page from Magisk it is nicely explained how the booting process and the partition structures evolved over subsequent Android versions. We'll recap a few crucial points, just to understand where A-only and A/B images are meant for:
  • Android 8 introduced project Treble for the first time and hence some devices should be capable of running GSIs. Booting was done from ramdisk (method A) and SAR was not a thing yet. Hence, devices running Android 8 (and possibly also some running Android 9 or even later(?)) that use this boot method need A-only (non-SAR) GSIs (if Treble supported). Seamless updates were not a thing with this method.
  • Android 9 introduced SAR which was necessary for A/B seamless updating. In the Magisk documentation this is called "legacy SAR" (method B). Hence, devices running Android 9 (and possibly also some running Android 8 or ones upgraded to Android 10 or higher) using this method need A/B (SAR) GSIs (if Treble supported), whether or not seamless updates are supported.
  • Android 10 introduced the ramdisk again due to support for dynamic partitions. 2SI made SAR possible (method C). Hence, Android 10 or higher devices (and possibly also some running an older version of Android) using this method need A/B (SAR) GSIs (if Treble supported), whether or not seamless updates are supported. Android 10 always uses SAR with method C (but perhaps devices upgraded from lower versions can use Android 10 without SAR and method A?).
It's clear that having a two slot A/B device (for seamless updates) or a single slot A-only device has little to do whether you need a A/B or an A-only GSI. The Magisk documentation defines four types of devices. Considering the above, only device type I always needs an "A-only" non-SAR GSI. Type II, III and IV always use "A/B" SAR GSIs, and indeed this type is independent of whether seamless updates are supported or not (a device with type III does not and neither does a device with type IV with a single slot system).

The reason we apparently still call the GSIs for these old non-SAR devices "A-only" and the other ones "A/B" is now also clear: at one time there was Android 8 which did not have seamless updates. Then along came Android 9 which had that option. So devices which had it were required to use method B (and hence legacy SAR), whereas non A/B devices that did not have seamless updates could also use the old method A (non-SAR). Even then, A-only devices were still able to use method B anyway. However, for some reason people decided that all method B devices fall under the A/B denominator and that the A-only name is reserved for method A devices (where the A of course has nothing to do with the A in "A-only"; I hope you can still follow along).

So my question is: why don't we call A-only GSIs non-SAR and A/B GSIs SAR? That seems much less confusing. This forum even has three sub forums for A, A/B and A / A/B GSIs. That seems a bit much considering that there is only a minor difference in partition layout. I think that a single forum could suffice. Indeed, we can see that mostly everyone publishes their GSI in the A / A/B forum. Perhaps it's a good idea to create two forums then, called "GSI development" and "non-SAR (legacy) development". Also, starting from Android 11 the boot process is similar and compatible to Android 10, so going forward this important distinction will die out anyway and every GSI should work on every phone.

What strikes me as odd still, is that even for Android 10 and 11 releases there are "A-only" non-SAR GSIs offered. (To see what I mean look for example here at builds provided by @phhusson.) But I thought that non-SAR images are for older Android versions using method A. So my second question is: can these "A-only" GSIs with recent Android >9 versions even run on non-SAR devices? Is the SAR requirement for Android 10 then not so strict? Are they indeed only meant for the method A / non-SAR devices which can actually boot Android 10 and higher using method A?

As a last note, what I also find weird is that Google itself has a confusing name for its legacy non-SAR build targets: they add the "_ab" suffix. However, this has again nothing to do with seamingless A/B system updates on two-slot devices. I asked about that here. Please post there if you want to give some input on that.

Any thoughts are appreciated, especially regarding the two questions I have.
 
Last edited:

phhusson

Recognized Developer
Jul 23, 2009
2,475
4,754
Paris
A-only/AB was used for historical reasons, because it was true on Oreo devices. But since then, Google calls Android 10 devices non-SAR (because they boot on initramfs, even though afterwards yes system is root), and sar property is set to false on those devices. So you can't just go around saying sar/non-sar, it'll a bit more correct, but still not correct. I could have switched to a "SAS" vs "SAR" naming convention (system-as-system VS system-as-root) but well I didn't have time

For your second question, yes that's the whole idea of "A-only GSI". No Android requirement is perfectly strict. Android requirements says you must have an x86 or an ARM, yet there are RISC-V Android. Android is opensource, you do whatever you want with it. Yes they are only meant for "method A" devices.

As for aosp_arm64 vs aosp_arm64_ab, the `_ab` refers to legacy ab devices, which have less requirements wrt properties
 
A-only/AB was used for historical reasons, because it was true on Oreo devices. But since then, Google calls Android 10 devices non-SAR (because they boot on initramfs, even though afterwards yes system is root), and sar property is set to false on those devices. So you can't just go around saying sar/non-sar, it'll a bit more correct, but still not correct. I could have switched to a "SAS" vs "SAR" naming convention (system-as-system VS system-as-root) but well I didn't have time

For your second question, yes that's the whole idea of "A-only GSI". No Android requirement is perfectly strict. Android requirements says you must have an x86 or an ARM, yet there are RISC-V Android. Android is opensource, you do whatever you want with it. Yes they are only meant for "method A" devices.

As for aosp_arm64 vs aosp_arm64_ab, the `_ab` refers to legacy ab devices, which have less requirements wrt properties
Thanks that clears up a whole lot. Except for the _ab part, but I guess we just have to view that just as a suffix for a legacy build target.
 
Last edited: