[Magisk] pndwal:
That was the change where Magisk began creating ramdisk cpio from scratch if checks indicated generic ramdisk was missing...

Yup, I'm not sure of this either, but seems it should be empty (block exists, size 0)...

Yup... The logic clearly gives Ramsisk = No simply if A-only and Legacy SAR exists...

John simply knows that OEM has not included a recovery ramdisk in /boot that can be hijacked for booting system with Magisk as no Legacy SAR devices use ramdisk to boot system.

Kernel directly boots system so there is no boot ramdisk in /boot... BOARD_USES_RECOVERY_AS_BOOT := true in A/B devices and recovery-ramdisk is present but used only to boot into recovery; it is eliminated in A-only devices as these have ramdisk in /recovery for recovery booting...

Nb. This bad situation for Magisk changed again in Android 10 as with 2SI a 'hybrid' (for devices like OnePlus 8T with a and b recovery partitions) or recovery ramdisk always exists in /boot... BOARD_USES_RECOVERY_AS_BOOT := true and now recovery-ramdisk is used to boot into both recovery and Android.

So an understanding of Android 9 architecture is clearly enough to extrapolate the Ramdisk = No indication without polling a "ramdisk block", and to narrow down affected devices to all 2018, 2019 A-only first generation SAR models...

Further, as I've said, this "No" indication remains true if we realise that it indicates only that no factory ramdisk in /boot was supplied and does NOT indicate that a Magisk-added or other manually added ramdisk won't exist. As such it continues to be the best indicator for Magisk that the bootloader likely doesn't support ramsisk/Magisk in /boot.

Nb. The various other ramdisks that exist in Android can also confuse users and Devs alike. For example, vendor ramdisks were seperated out from /boot partition with Treble GKI introduction in A11 to vendor_boot.img... Android 12+ devices w/ boot image header version 4 support multiple vendor ramdisks in /vendor_boot partition. The vendor ramdisk fragments are concatenated one after another in the vendor ramdisk section. The bootloader must load the generic (hybrid or recovery) ramdisk into memory immediately following vendor ramdisk and after the kernel decompresses, it extracts the concatenated file into an initramfs, which results in a generic ramdisk overlaid on the vendor ramdisk file structure. (Because the generic ramdisk and vendor ramdisk get concatenated, they must be in the same format; GKI boot image uses lz4-compressed generic ramdisk, so GKI-compliant devices must used lz4-compressed vendor ramdisk)... There is also ramdisk in RAM to distinguish further...

The Magisk Devs themselves were confused about these architectural changes for a while too. For example, earlier they were saying that ramdisk didn't exist in /boot as it was moved to/vendor_boot even though 'generic ramdisk' was still present in /boot (and it wasn't even hiding! 😜 )...

It turned out that patching was now failing simply due to compression format mismatches breaking ramdisk concatenation (explained above) and worked fine for patching at least once ramdisk compression formats were aligned in a Magisk fix and Magisk's manually-add-missing-ramdisk parts (originally only for A only legacy SAR devices) function kicked in for GKI devices too... Since this we understand that in late devices the generic ramdisk in boot or init_boot must be patched, not vendor ramdisk in vendor_boot, and Magisk has been fixed to add the missing generic ramdisk parts...

Well I hope this helps... 😜 PW