Google “upgraded” to less than any other mainstream computing platform. Windows gets about 10 years of security updates for each major version, up to 15 if you pay extra.
Hardware wise, you can easily pull out 20 years or longer simply by constantly bumping up the OS version.
They release a generic template, other vendors then apply platform kits for the SoCs they use and they release the operating system for their devices. Google has no idea what it runs on, or what is needed to make it run on specific devices. It is the vendor's task.
Mobile devices have no UEFI, no bus enumeration, so the OS image has to be taylored for each device. It is similar to Raspberry or Odroid or similar SBCs: althrough both are arm, you cannot use Ubuntu (or other disto) image intended for one on another.
> Mobile devices have no UEFI
Since the Snapdragon 835, Android devices with Qualcomm processors use UEFI all the way to the kernel.
However, custom UEFI binaries aren't part of the boot flow, with an Android UEFI boot application running instead.
> no bus enumeration
It's device tree instead of ACPI, but apart from that the situation isn't _that_ different from PCs today. We aren't in the ATAGS era anymore. The reflashing interface nowadays is standardised through fastboot too.
> so the OS image has to be taylored for each device
Thankfully a lot of progress has been done on that.
Since Treble, the BSP proper has been untied from Android releases.
Since devices shipping with Android 12, a Google-built kernel with a stable kernel module ABI has been shipping (for a given major kernel + Android version release combo). This allows kernel security updates to be identical across the whole ecosystem.
> althrough both are arm, you cannot use Ubuntu (or other disto) image intended for one on another
That used to be true, but across the whole Android device fleet (even between SoC vendors) it's not true anymore.
However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those.
More info on generic system images: https://developer.android.com/topic/generic-system-image.
This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so.
> However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those.
> This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so.
So assuming my bootloader is unlocked, have a GSI compliant phone, what is the remaining work I would need to have done in order to get it working under linux (and by working I mean all devices - including cameras and etc)?
A good chunk of the Linux community on phones didn't want to have to rely on binary drivers for non-technical reasons, and that's one of the reasons why it isn't exactly well taken care of today.
For Ubuntu Touch specifically:
https://docs.ubports.com/en/latest/porting/introduction/Intr... for Ubuntu Touch.
https://github.com/ubports/porting-notes/wiki/Generic-System...
An upgraded Halium (https://github.com/Halium) image on a can work unmodified across the whole ecosystem of Android devices.
However, the latest currently developed experimental Halium works on an Android 11 base at most, so that devices launched with Android 12 might be using drivers too new for it at this point in time.
(https://gitlab.com/ubports/community-ports/jenkins-ci/generi...)
This can be fixed with an engineering effort to do so to make it work on devices launched with Android 12. The Linux on phones community is very small and that causes problems in this case.
Together with the unified kernel image (GKIs) on Android 12 which allows to have kernel image binaries built with GNU/Linux-specific features that work across the whole fleet, a full straightforward experience can be made possible. This would fill the last chunk of custom per-device bits.
I wonder how big the audience would be for such a project though. :)
https://arstechnica.com/gadgets/2018/06/talkin-treble-how-an...
https://arstechnica.com/gadgets/2020/12/qualcomm-promises-th...
https://arstechnica.com/gadgets/2020/07/android-10-has-the-f...
At least they fixed this with the pixel 6 with a 5 year upgrade plan.