[Treble-Enabled Device Questions and Answers] Quigley:
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 below (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 with non-SAR but method A instead?).

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 with whether you need an 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 means the kind of image needed 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 SAR ones "A/B" is now also clear: at one time, at the time of Android 7 and 8, many devices did not have seamless updates, which was a new feature (the Pixel was the first two slot device). So devices which had it were required to use method B (and hence legacy SAR), whereas single slot non A/B devices could also use the old method A (non-SAR). Even then, single slot A-only devices were still able to use method B anyway, if implemented that way. However, because then it was mostly true that single slot devices used method A and the dual slot devices used method B, people decided that all method B devices (be it single or dual slot) 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) GSI development". Also, with Android 11 and higher 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. (Unless yet another incompatible"method D" comes along.)

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.