> In two years, your average consumer probably doesn't care if their device is still receiving software updates. They'll jump onto a new phone plan, with a fresh, cool new mobile, with a better screen, newer software (features!), and a refreshed battery.

This might be true for the US, where 75% of subscribers are on post-paid (contracts). It's not true for the rest of the world.

* Europe: < 50% post-paid

* Rest of the world: < 22% post-paid

I'd also argue that Android users will be more likely to be pre-paid than post-paid customers (compared to iPhone users) in all of these regions, but I have no data to back it up.

Anyway, I agree that it's probably not very profitable, if at all, for android handset makers to support their devices for > 2 years. But I think many customers would benefit from it ...

[1] http://www.globalrewardsolutions.com/wp-content/uploads/GRS-...

I think the "post paid" connection leading to a 2 year lifecycle is suspect. There's a big after market repair industry in the US. Many people have a singular cell phone as their internet device - and it's often ancient by IT terms. 2+ year old hardware needs to be getting software/OS upgrades.

I favor the proposal of requiring a prominent "Best Before" date for new devices, indicating how long the manufacturer will guarantee the availability of security updates.

That's an SLA and we should all b getting them.

But it is not something related to 2 year upgrade plan. In EU phones have 2 year warranty, after that period most people would like to upgrade it. And more over in parts of the world outside US, the best phones are not always available on contract, you need to buy them on your own (e.g. Nexus line was mostly like that, Pixels probably too).

And more over cellular companies put a lot of bloat on the phones, some of them would make malware creators proud (e.g. an app that if you open it after 1 month trial period it will add a recurring cost to our cell bill).

Also we usually use the mobile phones until they die or get stolen, which is way more than just 2 years.

> I seriously doubt the Linux kernel is anything but a minor contributor to Android's update problem

The Linux kernel is at the very heart of Android's update problem - not because of "modularity" but because it lacks a stable ABI. Because of this, Android requires handset makers and SoC manufacturers like Qualcomm to provide updated drivers; these parties are perversely disincentivized to do so as they would rather sell more of their latest model/chip. If the Linux kernel's ABI were stable, Google could bypass the manufacturers altogether when sending out updates.

The Android ROM community struggles with this - you can update the userspace or overclock the kernel to your heart's content, but you will forever be stuck with whatever kernel version the OEM-supplied drivers support.

Edit: added ROM paragraph

Just like RHEL/CentOS, couldn't Google maintain a stable kernel ABI throughout a given android major release such that manufacturers could write a driver once, and have it continue working for the lifetime of that major android release?

I'm sure they could. Although it seems they would much rather move away from the Linux kernel altogether. Who knows what sort of ABI stability timescales they are aiming for in the replacement kernel.

The pertinent question is how Google think they're going to convince Qualcomm to write drivers for their new OS, and not just have exactly the same problem they have now. Qualcomm probably quite like the current arrangement where they get to deprecate everyone else's gear on their own schedule.

With wall street's love for next-quarter accounting, I'm sure Qualcomm will consider the offer, even if it's a one-time bump.

Qualcomm is dominating the SoC industry, in part due to how it uses its IP. Fortuitously, Qualcomm are being sued by the DoJ and Apple for anti-competitive practices in multiple jurisdictions and this might blow the SoC field wide open, depending on the rulings. If other chip makers can license Qualcomm's patents on a FRAND basis, Google could offer the deal to MediaTek if Qualcomm declines.

> The Linux kernel is at the very heart of Android's update problem - not because of "modularity" but because it lacks a stable ABI.

What are you referring to when you say the Linux kernel ABI is not stable? I ask because the A in ABI means application, and Linux has maintained a consistent ABI for decades.

I have a suspicion that you're trying to suggest that in-kernel interfaces be kept rigid and unchanging to satisfy some unspecified number of out-of-kernel driver developers. The simpler solution would be for out-of-kernel driver developers to get their code up to quality and merged into mainline so that they'd be ported automatically whenever there's an in-kernel api change.

> The simpler solution would be for out-of-kernel driver developers to get their code up to quality and merged into mainline so that they'd be ported automatically whenever there's an in-kernel api change.

Or we could drive linux into irrelevance and not have to worry about that anymore. Windows and MacOS users do not have to suffer from this, why should users of an open source operating system? I for one welcome Google in cleaning out this mess with a competing kernel. You know your suggestion will never happen, you know some hardware manufacturers will never open their drivers, and some just can't be avoided (people doing GPGPU work will not switch from NVIDIA, most gamers won't switch from NVIDIA, NVIDIA is owning the GPU market for the purpose of machine learning with their SOC and is working on a lean vulkan driver for linux for things like Tesla's self-driving cars).

During the early days of constant wifi APIs churn within the kernel, there were many, many out of tree drivers that ran perfectly fine but took a very long time to get mainlined because hey the kernel devs have """standards""" as they like to call it. I couldn't use a distribution that was prone to upgrading its kernel version, like Fedora, because those out of tree drivers broke on a regular basis. One of Ubuntu's major advance in its very early days was to provide fresh software every 6 months while keeping a kernel that was in sync with all those drivers and they integrated said drivers into the distribution. That gave a middle ground between using something like Fedora/debian unstable with constant breakages, or suffering the glacial pace of debian stable.

... until I discovered NDISWrapper. An implementation of the Windows API for network drivers. Yes, really. It worked so good, and because it was a well maintained project, it quickly got updated to new kernel APIs and allowed anyone with any of the working windows drivers to be freed from this suffering. It was great. Nowadays the linux kernel has support for most wifi chips in-tree (Broadcom is still a problem though) but in those days it was truly liberating to be able to use Windows drivers in linux.

Talking about wifi drivers, the Windows XP driver for my first usb wifi adapter still worked in Vista and 7 despite the manufacturer never updating it. Identical driver binary working on 3 OS generations. Talk about commitment to not breaking things. NDIS 5.1 was "deprecated" for NDIS 6.0 but MS kept the support for it for as long as reasonable for the age of the hardware.

> Or we could drive linux into irrelevance and not have to worry about that anymore

I know this is going to sound flippant, but believe me it's not: who's "we" in your sentence? Google? Because I wouldn't want to see Linux "driven into irrelevance" unless it gets replaced by another free software OS which works and is not completely owned and controlled by a single corporation. Actually, I'd rather see Linux's problems fixed or improved rather than adopting Google's brand new OS.

The problem with lack of stable driver ABI in Linux will not get resolved as long as Linus et al. are calling the shots. They are fundamentally opposed to the idea, and there's nothing you can do about it.

There's not much I can do to influence Google's vision either. At least Linux is Free software (note: I'm equally fine about other pieces of software which are not Linux but are Free software).

The Linux on a standard distribution and Linux on an Android device aren't the same thing.

The one on the Android device is a fork with quite a few APIs trimmed off, like for example UNIX V IPC.

I think he is just making it up as he goes along. If you look at the fuschia docs or newsgroups all it says is that it they are working on this OS and intend to combine it with flutter to make a fast platform.

Nobody says anywhere that it will replace android. It looks just like a lot of these other Google projects. They put people on it. If turns into a contender then they might use it but if in the meantime android introduces features that make it more competitive then maybe they will throw fuschia away. That's my understanding anyway.

Also: "I have very strong reservations about Dart as the language of the primary platform API" and then later... "I am not a programmer"

Also, the customers that do care basically don't have much choice. With the Nexus line gone, you have to spend a lot of money for a Pixel to get a decent chance of having updates for a few years.

For the past year I've been every now and then looking for a mid-level Android tablet and I've always given up, since they all ship already with an outdated version of Android and slim chances of even getting an update to the current one (let alone future versions)

> Maintaining existing software for customers costs handset manufacturers $$$, and disincentives consumers purchasing new phones (their cash cow).

Maybe Google should split play store/app ad income with manufacturers, adding some incentives (50/50 profit split for phones on latest Android, 20/80 for one trailing major version - and then nothing. Or something along those lines).

That might have the added benefit (for Google) that manufacturers would have a stake in a healthy play ecosystem.

It's the ability to impose a private tax on ads and software that's supposed to be the monetizing strategy for walled gardens, isn't it?

If hw is commoditized - manufacturers need another leg to stand on.

Unintended consequence #1: phones that are too slow to adequately run the latest version will be force-upgraded Windows-10-style even if it degrades the user experience.

Well, maybe be more lenient on trailing versions if, and only if there are timely security updates?

I'm not sure the alternative is much better - lots of unpatched insecure phones in use?

> In two years, your average consumer probably doesn't care if their device is still receiving updates

Well, that's exactly why I've bought an iPhone this time. Exactly €1000 lost for the Android ecosystem, just because I want encryption. I know, Android 6.0 has encryption by default, but 4.4 doesn't, and that's the point. The whole story displays a lack of professionalism, in my opinion.