"can't" is such bs. Make it so that the kernel and OS can be fully updated independent of device drivers and bypass manufacturers for distribution. Why does nobody remember that Windows updates come directly from Microsoft and that third party webcams just keep trucking along?
The Linux kernel doesn't provide a stable ABI for modules so they have to be atleast recompiled each time. There are some workarounds such as DKMS to rebuild the interface when the kernel updates but I don't know if Android provides it.
Last I checked a big issue was Qualcomm doens't support their SoC for very long so manufactures have to tweak each devices 'tree' (it's unique kernel and drivers) for each kernel update.
The whole point of project treble was to disconnect the Android version from the kernel version so that manufactures could keep using the existing kernel and drivers and would only have to recustomize the new OSI to their liking.
Turns out a lot of device manufactures still don't see much value in providing timely updates since the general public doesn't even know what version their currently running and are just as likely to hate an update than like it.
Personally, I feel Google's sluggishness to enforce update policies or change how Android works is out of fear that Samsung will break completely and launch their own app store and not have the Play Store, or rather Play Services which is what Google needs if they want to power many of their online platforms (where do you think Google map road conditions come from?, Or that feature that shows how busy restaurants are?). Without play services on every Android device, Android looses it's profitability.
Yet Apple manages it, and they use Qualcomm components.
What happens to the Qualcomm drivers when Apple releases a new iOS version that works across multiple generations of devices, are they updated by Apple or does Qualcomm provide a new driver to Apple ?
I am not 100% accepting the ABI argument the drivers in the Linux kernel are not getting rewriting every release, sometimes there are changes and I don’t know if applying those changes to drivers is such a burden otherwise the kernel will be always broken
> I am not 100% accepting the ABI argument the drivers in the Linux kernel are not getting rewriting every release, sometimes there are changes and I don’t know if applying those changes to drivers is such a burden otherwise the kernel will be always broken
I think you may be mixing up “ABI” and “API”. If you change internal kernel APIs, you’d break a lot of code and have to go in and fix it. If you change the ABI, you just have to recompile. The ABI does change pretty often and as a rule of thumb there is no effort to keep it stable, the way you would if you were writing a shared library (which ideally has both a stable API and ABI). Drivers in the kernel are not broken because they are recompiled with the rest of the kernel. Kernel modules from different kernel versions ARE broken and this is why we have DKMS.
But just to talk about what happens here—Apple is the only developer of the XNU kernel, and they have a fairly short list of iOS SKUs in the history of iOS, and only a small portion of those get iOS 13 support—something like 12 iPhone models. So the support for all of these devices is right on the mainline kernel development tree.
This is not how Android development works. You generally have a bunch of different manufacturers, who get a team of engineers to get a fork of the Linux kernel working on each device, and then they drop it and move on to the next one. There will be various binary blobs involved, and integrating the changes back upstream or downstream ends up being a pain.
And just to return to the original point, the Linux kernel developers are actively hostile to any attempts to make the kernel ABI stable enough for binary blob drivers to work. This is not a question about whether it is technically possible.
My guess is that Apple writes the drivers themselves. That makes sense because iOS isn't like Linux or Windows where there are public resources on writing drivers. Because they write the drivers, it's very easy to port over to the next iOS version because all the expertise is already at Apple.
In contrast, Qualcomm gives the OEMs a copy the custom Linux kernel that works with their SoC[1]. The OEMs then use that source to build their kernel, probably making minimal changes to it. Once Qualcomm stops selling that SoC, they stop releasing updates to their custom kernel because there's no pressure from OEMs to keep it patched.
Microsoft bundles drivers for most of the popular hardware. I was able to stick a Windows 7 DVD in my Core Duo Mac Mini, install it and it recognized all of my hardware - FireWire, Ethernet, sound, WiFi, Bluetooth and it sort of recognized my IR port used for my Apple Remote.
> Personally, I feel Google's sluggishness to enforce update policies or change how Android works is out of fear that Samsung will break completely and launch their own app store and not have the Play Store, or rather Play Services which is what Google needs if they want to power many of their online platforms (where do you think Google map road conditions come from?, Or that feature that shows how busy restaurants are?). Without play services on every Android device, Android looses it's profitability.
Hasn't Samsung already tried that with Tizen (and didn't do well), which was also put on its Gear smartwatches?
> The Linux kernel doesn't provide a stable ABI for modules so they have to be atleast recompiled each time. There are some workarounds such as DKMS to rebuild the interface when the kernel updates but I don't know if Android provides it.
I'd expect it to be technically possible, and for Google not too difficult, to pick a version of the Linux kernel module ABI to define as the Android module ABI, and then for newer kernels with newer kernel module ABIs add an adapter layer that can translate from the old ABI to the new ABI.
“You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree.”
It is now the modern way to publish drivers for Android, either in Java or C++, implemented as kind of micro kernel architecture, where drivers get each their own process, and talk to the Linux kernel via Android IPC.
Classical Linux drivers are considered legacy on Trebelized devices.
The big problem is that in spite of having a standard ABI, Google does not require OEMs to actually push updates, so everything stands as before for consumers, while OEMs have even lower development costs.
As the article says, Google can't force manufacturers to follow strict update policies because manufacturers can just fork Android like Amazon did.
I can't think of any open source software vendor that is able to force its customers to accept strict policies, because forking is always an option.
Windows updates work for years because manufacturers maintain Windows drivers for their hardware. The Android ecosystem is more like the Linux desktop one -- each manufacturer sells a different Android distribution with their own custom stuff mixed in.
Windows has a relatively stable driver ABI. Old drivers can run on new builds of the system.
Linux doesn't. So OS updates leave behind old drivers.
So manufacturers don't have to do anything for their drivers to continue working on Windows, and it is often the case that updates will stop shortly after hardware is released.
“You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree.”
Redhat EL provides this. There are various engineering reasons for why they don't care for it in the Linus kernels. So it seems nobody wants to invest the engineering effort to do this for Android.
> manufacturers can just fork Android like Amazon did
This is a pretty weak argument against doing the right thing by taking control of system updates. Even stock Android devices stop getting updates very quickly because of how tightly coupled to the hardware drivers Android is. It doesn't have to be that way.
Android phones wouldn’t sell in the west without Play Services. Google has a lot of control over Android manufacturers. They were just forced into a consent decree by the EU - because they were forcing manufacturers to not sell non Google Android forks if they wanted to sell phones with Google Services.
Amazon is doing okay with cheap tablets but their phone was a failure.
Google can force a lot of things. Android manufacturers can’t realistically sell a phone outside of China without Google Play services. Google just got in trouble with the EU for strong arming Android manufacturers with respect to making Google the default search engine and not allowing them to both sell official Google Android phones and forks.
This is why it is so important to buy a device that has open source drivers. If your device can run mainline linux without any patches then you can be pretty sure it will be easy to update for a very long time.
The only phone I know which fits this description is the Librem 5. Unfortunately it would currently be a lot cheaper to just buy second hand android phones every 2 years than to buy one of these but hopefully they can get the price down later.
The postmarketOS project is working on mainlining drivers for other devices. They're almost done wrt. the LG Nexus 5, which is their current flagship (though mobile voice/data support is still problematic)
Well there is also the fairphone! And pinephone in the future (based on rk3399, so not bad mainline support). Peripherals are always iffy, but sometimes you need to make sacrifices.
Android kernels are routinely provided by the OEM and are usually an unholy cocktail of old Linux, with fixes backported from upstream. These kernels are checked into the Android source repo as binary files.
