I finally have a phone (3axl) that didn't die in a couple years from accidents / abuse / going to the gym in my pocket, and Google is eol-ing it because they've cut off security upgrades.
My next phone will be an iphone.
It sounds like what you're saying is Google has only continued to shuffle ever more vital functionality into the Play store since I left Android, which negates the often claimed benefits of an "open source" operating system. If all the important stuff is in a proprietary blob attached to a proprietary platform, I might as well stick with the one I already know that's never given me any trouble. I'm not going to root my iPhone or install a custom OS, so that's irrelevant to me.
And just because they are applied by the play store doesn't mean they are closed source. The play store itself is closed source, but the security updates to the OS get published via the normal processes.
Android is open enough to allow competition, eg. Amazon's Android, Microsoft's Android runtime, etc. are all done without Google's permission.
To me, that's key, but I'm not trying to tell you whether open source should matter to you. I just wanted to clear up the stuff about the security updates because I think the Android way of doing it is now better than Apple's method.
I think it is a much better way to do security updates than the Apple model - security issues shouldn't have to wait for the next firmware update and for the user to apply them.
At least they fixed this with the pixel 6 with a 5 year upgrade plan.
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...
Same reason I switched to Apple last year -- after being android only since original Motorola Droid (2009).