[tadfisher]

Agreed, but let's point fingers at the whole stack if we want this to happen.

Treble [0] will finally add a HAL to the base system, so updates to the kernel and drivers should in theory be easier on devices that ship with 8.0 (of which there are exactly zero so far). So at least Google's on the right track.

But Google doesn't create the drivers and Google doesn't ship the board support packages which vendors build upon. And so we come to Qualcomm, Samsung, Mediatek, and whoever else is shipping proprietary drivers for their SoCs and radios, and who don't provide binaries for new ABIs.

The workaround is libhybris, which Ubuntu Touch, Sailfish, and now PMOS are using to support drivers built against Android kernels and its userspace, but that is so fraught with issues that it can't possibly be supported by Google or the vendors.

So we have Android 8.0 shipping with a 4.4 minimum to support the lowest common denominator of BSPs, and it kind of has to be that way until some market force changes the landscape. I don't have high hopes for either of the projects you mentioned, sadly.

[0] https://source.android.com/devices/architecture/treble

[richdougherty]

Agreed, it really is a shared problem. It seems like a kind of "collective action problem" [1], where coordination between different parties is required - but they all have different interests and they're not all interested in splitting the costs.

Google is in a difficult position. In order for Android to catch up to the iPhone they needed to encourage a wide consortium of vendors to adopt and sell Android hardware. Part of the way they encourage vendors to sell Android phones is by being very permissive about how vendors install, update and use Android. This helps Android by growing market share.

Unfortunately, it leads to a lot of variation and fragmentation in devices, which in the long term can hurt the Android ecosystem. I guess there's a balance that Google is trying to strike between being too permissive and too restrictive in how they work with vendors.

[1] https://en.wikipedia.org/wiki/Collective_action#Collective_a...

[pjmlp]

It worked for Microsoft to impose hardware designs on PCs, the big difference was that OEMs did not had the source code of MS-DOS and later Windows available to them, to do whatever they felt like it.

[thanksgiving]

OEMs can't do whatever they like with Android outside of China PR. They need Google play services.

[pjmlp]

Yet Google decides, sadly for us, not to use that as enforcement for the updates.

[mtgx]

Indeed. Google has the power, and that excuse that Android is open source and therefore Google can't impose anything on OEMs is getting a little old and tired.

If Google would have promoted Android the way it did with Chrome OS (and the open source Chromium OS), it wouldn't be in this situation, and we'd be getting updates often. But I guess hindsight is 20/20. I still wish they did more about the support of Android devices throughout the ecosystem, not just for the highest-end devices.

[petecox]

> we come to Qualcomm, Samsung, Mediatek, and whoever else is shipping proprietary drivers for their SoCs and radios, and who don't provide binaries for new ABIs.

Vote with your wallet.

The librem 5 mentioned this week uses a 'liberated' i.MX6 chip because they want a phone with an upstream kernel. Technology wise, it's a little long in the tooth, but they're emphasising it's possible to not reward vendors for bad behaviour.

With RPi providing resources to de-blob and upstream the Pi, perhaps some entrepreneur will get behind a crowdfunded Broadcom based phone, with work underway on VC5.

http://phoronix.com/scan.php?page=news_item&px=BCM7268-DRM-W...