Whenever Apple releases a major OS update, as it did last Monday with iOS 17, iPadOS 17, and watchOS 10, developers – both large but especially indie – release a slew of day one updates to support the latest platform features.
[…]I understand how the Android update model is inherently different from Apple’s. Namely, updates start out only on Google’s Pixel phones, which have a relatively small market share, while Samsung’s lion’s share of Android phones are typically weeks or months behind. Third-party Android developers don’t have an incentive to update on day one as the majority of their users won’t be getting the new OS for quite some time.
It really depends on what kind of applications you’re looking at. Yes, the popular applications from big players like Facebook or Spotify are terrible at adopting new Android features, but there’s definitely a vibrant community of developers who care these days, and it’s entirely possible to use only applications that follow the latest features and visual style of Android.
It’s definitely not as good as it is on iOS, and it surely takes a bit longer, but it’s also not nearly as bad as some make it out to be.
Hello.
I still have the crazy opinion that part of the problem it is related to the kernel. If devices were able to update like magic to Android 14, it will solve a lot of this problem but that does not happens. We blame manufacturers, but that is only partial. Windows PCs and Linux PCs does not have many of those problems because they are stuck to a x64 processor architecture, while Android devices has a variety of processors architecture and a little twist… the “monolithic kernel”.
My opinion is that the monolithic kernel, where you have to compile all the system drivers with the kernel, with the problem of the manufacturers only care about selling more hardware and not updating it’s software, are the cause of the Android fragmentation issue (not only manufacturers as people say). Just think how do you upgraded from Windows 10 to 11 or how you upgraded Ubuntu on your PC and think on how can you upgraded Android on your phone, car radio or TV.
This is why I still want to see the open source hibrid/microkernel kernel that can compete against the linux kernel. (Zircon?)
That’s not what a monolithic kernel is. A monolithic kernel is one that has «everything» running in kernel space, be it compiled or from loadable modules. The real issue of Android (which also affects desktop GNU/Linux, although a lot less) is that the Linux kernel doesn’t maintain any sort of KBI stability.
Parodper,
I care more about what it means for android users than for the semantics. I think both of you are right. The fact that linux allows drivers to be loaded as modules versus linked into the kernel doesn’t help us get kernel updates when those modules are locked to a specific kernel. Even many of us using lineageos forks are stuck with OEM kernels that aren’t getting updates. Regardless of who we blame, there’s no denying android has been falling short of idealized FOSS values for decades now. Continuing down this road indefinitely won’t solve anything.
martini,
I’d like to see more competition too. However 1) the barriers to market entry are very tough to overcome, 2) there’s no guarantee industry won’t just ruin things again with more vendor locking. There is a lot of overlap between the set of companies that would be powerful enough to make meaningful inroads in the mobile market with a new kernel and the set of companies benefiting from vendor locking.
It’s not a matter of semantics. Having drivers built with the kernel or loaded as modules doesn’t change anything (and has nothing to do with microkernels). The interface is still the same, and can break in both cases. What I think you meant was «in-tree» versus «out-of-tree» drivers. In-tree drivers are kept compatible with their kernel version by the Linux developers.
In a microkernel, on the other hand, you wouldn’t have builtin or modular drivers. All drivers would run in userspace. The only advantage a microkernel would have in this case is that userspace interfaces are usually more stable than kernelspace ones.
The same could be said of Linux, though. I would obviously prefer only free drivers, but that’s a red herring. The real issue is the lack of a stable driver interface. Everything else, including Linux’s in-tree drivers, is just a workaround (or a lack of) around that issue.
There’s certanly going to be a inflection point. Phones no longer do such jumps in power to justify buying a new one every year. People are going to hold to old phones a lot more, and with the EU mandate batteries are going to be less of an issue.
Parodper,
That’s kind of the point though. It’s a semantic difference in terms of the terminology we use to talk about it, but it doesn’t change the problems for users as martini and yourself have mentioned them.
No actually. I didn’t mean that at all. In tree versus out of tree only changes who’s responsible for doing the work, but the kernel design itself (stable API & ABI in particular) changes whether the modules could be compatible across different kernels.
Yes of course, I think we’re all saying this same thing.
To be honest I have a hard time seeing this inflection point. I will be surprised if ARM chipmakers and manufacturers back down on their stance with drivers and I will also be surprised if the upper echelons of linux back down on their no-stable-abi policy. I could be wrong of course, but to me it looks like a long term stalemate that is in balance. I expect it to last many more decades.
As far as consumer sustainability does, the normal laws of supply and demand apply. If demand drops, then manufacturers will need to drop back to saner levels to the point where consumers will start buying them again.
Cannot edit…
“If demand drops, then manufacturers will need to drop prices back to saner levels to the point where consumers will start buying them again.”