@simonjust

(Hopefully this helps explain why things seem so fragmented, sorry for the wall of text)

doing actual virtualisation is out of the question on most devices since we don't get EL2 (hypervisor) level access to the system, it is already running a proprietary hypervisor which is needed for functionality like audio or wifi (yay DSPs and firmware signing)

For many if not almost all of the phones in our main and community categories the only real blockers to having generic images are the limited bootloader machinery (no dynamic devicetree selection means the android boot image has to be specific to the device to load the correct drivers) and that they require kernel patches and drivers which aren't in the upstream Linux kernel.

The former I'm actively working on solving for the Qualcomm based phones with U-Boot which I originally talked about over a year ago at FOSDEM https://archive.fosdem.org/2024/schedule/event/fosdem-2024-1716-u-boot-for-modern-qualcomm-phones/

this work is still ongoing (and getting close to the point where we'll start publishing images and getting the necessary distro changes in). This will let us have a generic image for e.g. all the SDM845 powered phones, one for all the SM7150 phones, etc. Since U-Boot can pick the right DTB for us (though it's important to note that the U-Boot build is still device specific, but at least it's a one time thing now)

This just leaves the kernel, which is unfortunately a much bigger problem. Since many devices rely on drivers for the touchscreen, speaker codec, haptics, and more which are pulled directly from the vendor kernel. Rewriting them to be suitable for acceptance into upstream can be a huge amount of work since they must be reverse engineered from crap vendor code and rewritten. And even when that process is "done" the actual process of getting them merged varies from doable, to tedious, to outright blocked, especially when maintainers ask questions that the developer can't answer due to missing documentation.

This process is getting better in recent years, but it's really hard to invest the time when it's volunteered time and could be less frustratingly spent fixing bugs for users or enabling new features.

From the distro side, I can potentially imagine some ways to de-dup these kernel forks internally, but so far nobody has tried taking the leap of faith. Hopefully once we get automated hardware testing up and running on enough devices this will be something worth looking into more seriously, but we'll need some way to support holding back upgrades for a single device if it introduces regressions...