Hacker News Reader

Comment by matt_wulfeck | Hacker News Reader

>If we look at the newest Android release (8.0, 8/2017), it looks like you’re quite lucky if you have a two year old device that will get the latest update. The oldest “Google” phone supported is the Nexus 6P (9/2015), giving it just under two years of support.

And 2 years is the best-case scenario. Compare to nearly 5 years for iOS devices (which, as far as I can tell was prompted only by a move to 64-bit SoC). It's beyond me that Google hasn't taken a more extreme approach to keeping their devices up-to-date.

View on HN

My Nexus 6P is eligible for 8.0 under the beta program, the last time I checked, 8.0 was still not available for it in the official channel so I had to switch to the beta program to try out 8.0 on a device.

8.0 has officially been available for the Nexus 6P since August.

Thanks, exiting the beta program to see what happens now.

Outside the US? My 6P got official 8.0 non-beta in September, I'm pretty sure. OTA, the whole nine yards.

Inside the US. I push the check for updates button in October and it told me no. I might have declined once, though.

I bought a flagship device, a Motorola Droid Turbo (1). They finally got android 6 on it a few months ago. Even better is it's so locked down that I have no choice. This is a $1000 phone, why can't I install what I want on it?

They aren't Google devices. They're phones made by companies who downloaded and installed Android on them.

The Nexus 6P was developed and sold directly by Google: https://www.google.com/nexus/6p/

Yes, I understand that Google do make some phones. I own one. But, the vast majority are not created by Google.

The Nexus 6P was made by Huawei. Also usually it is not the manufacturer, but the carriers that hold up or stop updates.

Even if this were true (it's not) that was a conscious choice by Google to capture market share.

This issue was predicted (and observed) years ago, almost since the release of Android in fact, and is only getting worse.

That is all due to Google's own choices.

The real problem with it is Linux. Here's a few facts:

The Kernel has no stable ABI for drivers.

Manufacturers only ever develop a driver for their chips once, and then send that to the OEM. They never update.

The Linux Kernel LTS gets 2 years of updates, Google's fork about 4.

From the day a Kernel is released, to the day it ships in a phone, usually 2 years are spent integrating the blobs and code drops from the chip manufacturers.

On every kernel upgrade that breaks the ABI, those 2 years would have to be redone from scratch.

Linux can't mainline support for every exotic piece of hardware that ever shows up in a device.

Manufacturers can't keep maintaining several developers to update every single chip they release.

Google can't keep Android on 6 year old kernels forever.

Now combine these facts, and you'll see the issue.

That's only a problem because they're keeping driver support closed. If they contributed a driver for their hardware upstream it would be maintained (by others) as the internal interfaces and standards change.

Whenever a security issue or design change happened, their driver would also get updated and fixed with the rest of the kernel.

What the hardware manufacturers SHOULD do is create hardware with a well defined control interface that they CAN make public. Any 'secret sauce', uploaded firmware blobs, etc, should be free to re-distribute since they were too cheep to ship a ROM or EEPROM with the firmware for their device with the device.

That's often not that simple.

For example, SAMSUNG might build your device, and get all of their own code openly.

But now for the US model, due to CDMA, they need to use a Qualcomm processor.

That needs a blob, and Qualcomm won't release that under an open license, nor update it.

So the OEM can either just not have CDMA support, or accept foreign blobs.

It works like this all way down the stack, down to even camera chips.

And then these devices all have custom hardware. Often hundreds of customly designed parts, with custom drivers, only ever for a single device.

Think of the Moto Z Play, withthe replacable components. Samsung phones with facial scanners. LG phones with 3D display.

One-off features that'd never get mainlined.

Apple has the same issues, yet they keep their devices updated and secure for 5+ years.

Well, Apple completely controls the XNU kernel and its I/O Kit framework. By contrast, Google--and especially phone manufacturers--don't control development of the Linux kernel.

My understanding about the US side of this is that the software defined radios and FCC compliance are a major portion of the problem.

STILL, that stuff should be equivalent to a firmware blob that should have been baked in to a ROM or EEPROM. The actual driver controlling it should be able to be open, and for regulatory compliance should use 'magic numbers' as specified for the configuration; which as a fact of how to use that device must be configured already /not/ be covered by copyright (in the US at least).

Well that’s not actually a problem if Google controlled the hardware (or a hardware standard, at least).

But they don’t.

So while you’re absolutely correct from a technical perspective it’s still a consequence of Googles strategy, and a problem for us all.

Android device vendors are Linux distribution vendors, and could support their releases for 5-10 years for a given device generation, like many other Linux distribution vendors are doing. (Or outsource it)

Yes of course it's not free and you can save money by leaving users stranded. But it's myopic to claim it's the fault of Linux.

That’s not really possible.

Let’s imagine you try to build a phone.

You buy an SoC, and you get a single kernel build. If you’re lucky, you get a few binary kernel modules.

These will never be updated.

You will always be stuck on that kernel version.

No manufacturer of ARM SoCs for phones currently provides ever updates for these.

Linux LTS Kernels get 2 years of support.

Now, tell me, how do you support a kernel that was dropped by upstream, with proprietary drivers that you can’t do anything about? I’m not sure if you’ve ever tried porting a custom ROM to such a device, I have. By the time Android was on the 3.11 kernel, I had a device still using kernel 2.6. It was insanity, half the functionality wasn’t working, we were reverse engineering and hacking together the rest, and still barely got anything working. It’s impossible to use a decade-old kernel with modern Android userland, yet that’s what you ask for.

You can support that kernel version, like distributions do now with back port etc work, or you can prefer SoC vendors that promise updated driver support. If the latter was happening, the problem would be fixed by now. So essentially phone vendors have been voting with their dollars for lack of driver updates.

But even for the self caused major version jam, the "get 2 years of support from upstream" is a heavy understatement and even after the n years of community LTS support ends, it's just the baseline you get for granted and you can diy more.

Maybe Fuchsia is an effort to solve such issues? But it won't see the day of light for at least 2 or 3 years.

The official Kernel.org LTS support is 6 years from the Linux devs, some vendors support theirs for longer.

The Kernel.org LTS support was 2 years until a few weeks ago.

Due to Google’s pressure, it’s now 6 years.

http://web.archive.org/web/20170812023641/https://www.kernel... says previously's been 2-6 years for the various LTS releases. But it's always been open to more sponsorship of course.

Reply on news.ycombinator.com