Android, like many other operating systems, uses the open-source Linux kernel. There are several different types of Linux kernel releases, but the type that’s most important to Android is the long-term support (LTS) one, as they’re updated regularly with important bug fixes and security patches. Starting in 2017, the support lifetime of LTS releases of Linux was extended from two years to six years, but early last year, this extension was reversed. Fortunately, Google has announced that moving forward, they’ll support their own LTS kernel releases for four years. Here’s why that’s important for the security of Android devices.
Mishaal Rahman at Android Authority
I fully support the Linux kernel maintainers dropping the LTS window from six to two years. The only places where such old kernels were being used were embedded devices and things like smartphones vendors refused to update to newer Android releases, and it makes no sense for kernel maintainers to be worrying about that sort of stuff. If an OEM wants to keep using such outdated kernels, the burden should be on that OEM to support that kernel, or to update affected devices to a newer, supported kernel.
It seems Google, probably wisely, realised that most OEMs weren’t going to properly upgrade their devices and the kernels that run on them, and as such, the search giant decided to simply create their own LTS releases instead, which will be supported for four years. Google already maintains various Android-specific Linux kernel branches anyway, so it fits right into their existing development model for the Android Linux kernel.
Some of the more popular OEMs, like Google itself or Samsung, have promised longer support life cycles for new Android versions on their devices, so even with this new Android-specific LTS policy, there’s still going to be cases where an OEM will have to perform a kernel upgrade where they didn’t have to before with the six year LTS policy. I wonder if this is going to impact any support promises made in recent years.
Doesn’t this only mean Google (as an OEM) are doing what every OEM is being forced to do?
I doubt this will benefit any other OEM much unless they use the same hardware as Google in the Pixels
We have generic computers that can be supported by generic operating systems for well over ten years (and without the manufactures involvement, yay!). The reason mobiles fail at support is because the support model is terrible. Rather than having to support old/ancient kernels, it would be much better to have mainline drivers such that the user doesn’t have to be stuck on an old kernel. This approach has a proven track record on PCs. Alas too many mobile devices are crippled by manufacturer dependencies. To a manufacturer EOL is not a problem that warrants fixing, planned obsolescence and short lifespan are a feature
This is why, decades after we’ve identified the issues and talked to death about how to fix them, we’re still suffering the same forever-problems on mobile. The corporate profit motives don’t align with consumer interests on this. Our throwaway gadget trajectory has no end in sight.
There’s some hope that RISCV devices will fix these problematic support issues, but I’m afraid that if we give manufacturers too long a leash they could ruin that as well by repeating ARM’s failures.
100%
I think this might slowly be coming to an end though.
Just as the race for moar-faster! pcs ended with consumers not caring any more about the cpu/ram they get, as it’s always more than enough anyway (and in recent times even accepting smaller and smaller ssd, having bought in in the cloud-is-your-storage model), so it is happening with smartphones. I just bought the same previous-gen Galaxy I had bought last year, after it got stolen, as its current-gen sibling has no discernible improvements and actually removes one feature I need. We are at the inflection point where the majority of phones gets replaced when either their battery has degraded too much, or they get lost/stolen/dropped-in-water.
gggeek,
I agree with your point: for many of us the need for the latest and greatest is marginal. I don’t think it addresses the long term hardware support issues though. An old phone might have perfectly good specs and be in good condition, but if if the software can’t be updated that’s a problem. Our acceptance of old hardware doesn’t negate the need for new & up to date software.
Agreed on the cpu, but RAM? I can never have enough. 32GB is my minimum. Which some people see as extreme, but they don’t run multiple IDEs & VM’s. Maybe the cloud would be cheaper one day, I thought it would but cloud prices have stopped decreasing.
Bill Shooter of Bul,
I thought we were talking about phones.
My computers have 64GB for similar reasons as you. I tend to provision VMs with more ram than they strictly need. The disc caching helps and the ram also keeps them from having to swap and reduces network delays.
I have a work provided laptop for visual studio with 16GB ram and to be honest that’s just not enough to run it smoothly anymore. IMHO it should be enough, but with the amount of bloat these days it could use more to avoid thrashing..
Terenie aren’t mainline drivers on PC. They work because Old drivers work on new systems/kernels. God, once driver from XP dated on 2002 worked on Windows 10 and that’s cool.
Marshal Jim Raynor,
I have no idea what “terenie” is.
If you’re talking about a stable ABI, I agree that’s definitely another aspect of the problem. Having mainline FOSS drivers would be best, and barring that having a stable ABI would at least let us keep using old drivers. But when we have neither mainline drivers nor a stable ABI to load old drivers this sets the stage for unsupportable hardware
I don’t get it. Firefox providing support to a Windows version that is 14 years old is good. The linux maintainers moving from 6 to 2 years is also good? I think is horrible that we cannot have a system for at least 5 years.
There is always a bit of double-think when it comes to Windows.