Comment by sorenjan | Hacker News Reader

Comment by sorenjan | Hacker News Reader

Parent Full thread

I've had two Google Nexus phones and one Android Wear watch, and all three became e-waste before their time purely because Google stopped updating them. In the case of the watch Google actually started sending out "updates" to their own apps that removed functionality from watches with older Android wear, with no possibility to update. It had less features when I threw it away than it had when I bought it.

I'm using Android on my phone not because I want to use a Google made OS, but because it's unfortunately the best option available, since I have other issues with Apple. A Google OS will never be the best option for my real computer, at least I certainly hope so.

I find it slightly hypocritical that the company that deliberately stops updating their own phones and computers based on dates can claim to want to reduce e-waste.

"Each device has an Auto Update Expiration (AUE) date." https://support.google.com/chromebook/answer/9367166?hl=en

"Reduce e-waste and extend the life of your existing devices by transforming them with a modern OS." https://chromeenterprise.google/os/chromeosflex/

Not defending Google’s actions but it worth noting that not updating devices usually has to do with the SoC supplier ceasing support for the chip by not shipping BSPs which support new OS features. Yes google should have negotiated better support but it’s lack of support has to do more with inability to do so within reasonable means.

They have projects ongoing to decouple OS functionality from the base firmware (project treble and project keystone).

https://www.googblogs.com/tag/keystone/

This whole issue is probably one reason that Google went through all the trouble to first develop their own support silicon and then the main SoC (pixel 6).

> not updating devices usually has to do with the SoC supplier ceasing support for the chip by not shipping BSPs which support new OS features

I don't know what a BSP is, but why can I update linux (or indeed almost any OS) on my PC without any support from the motherboard vendor? What OS features need SoC support, and why can the OS not live without them, when it was previously able to do so?

This was the case before smartphones. It is not an advanced feature of linux, developed later, that Android failed to backport. I suspect they broke it deliberately.

To my lay understanding, phone hardware offers approximately the same features today as it did a decade ago - make calls, connect to the internet, interface with the camera and GPS. Occasionally a protocol might change (LTE, 4G, 5G..), but maintaining support for a slightly older, still-in-use protocol or hardware device, that serves the same basic purpose as its new replacement, is the bare minimum - it is not a radical divergence of architecture or functionality that would make maintaining old versions prohibitively difficult.

> I don't know what a BSP is, but why can I update linux (or indeed almost any OS) on my PC without any support from the motherboard vendor? What OS features need SoC support, and why can the OS not live without them, when it was previously able to do so?

Basically, PCs have 2 things going for them:

First, they use standardized, enumerable interfaces. You can boot an arbitrary Linux-based system and the kernel can ask the PCI bus "what hardware is installed?" using the same query on every machine, and get back an answer in the same format. "Embedded" devices don't have that, generally (ARM ServerReady does add this, and does create ARM-based hardware where you just stick in a random distro's USB stick and boot and it works).

Second, Linux on PCs tends to use upstream drivers. When you run ex. Ubuntu on a laptop, it talks to your ex. graphics card using a driver that's in Torvald's official tree. For... reasons... that I don't claim to understand but that probably involve cost-cutting, Android phones rely on drivers that are written by hardware vendors and then abandoned without any effort to get included upstream.

So the result is that in many cases you can boot vanilla Linux on an arbitrary phone or whatever, but it'll come up with access to the CPU, RAM, and USB (because that is still an enumerable bus using a standard interface), but it will have no idea how to query the rest of the hardware and if it did it wouldn't have any drivers to talk to that hardware with.

Edit: I should mention, a BSP is the ... "solution" that vendors use to pretend this whole thing is workable. It stands for board support package, which is a giant blob of source code that includes at minimum a copy of Linux with all their delightfully buggy custom drivers included and all the necessary hardware devices hard-coded so the system can find the hardware when it boots. And by find, of course, I mean "blindly assume it's there". On a good day this data is encoded in a device tree, which is a file format for "here's what hardware is in this system and how to talk to it (ports, memory addresses, whatever) ".

For Chrome OS not the problem a lot of the time, they drop support for devices using commodity SoCs that are still supported elsewhere... it's a quite hardcoded expiry date.

And they don't even drop support for all machines using a given SoC at the same time.

For Chrome OS updates are wholly owned by Google too.

I am more knowledgeable about the arm / android world.

I do wonder if for the chrome os world there are SoC+BSP vs ChromeOS feature requirements that cause this lack of ability to support (e.g. trust zone etc)

> (e.g. trust zone etc)

For chromeOS devices, the boot firmware (incl TZ) is owned by Google.

This is well known for Android devices.

If you look for "longest supported Android devices", you might find: - Nvidia Shield TV 2015: initially released with Android 6 and is currently on Android 11. It uses a CPU from Nvidia itself and is expected to continue receiving updates. - Nexus Player: initially released with Android 5, last updated to Android 8. It uses an Intel CPU and does not require special binary blobs to support newer Linux kernels required by newer Android versions.

Project Treble and Keystone are worthless, because they keep the reasoning that they aren't required for Android certification.

The traditional excuse is that Android is a rich ecosystem and they don't want to prevent partners from "innovation".

The mess continues as Google isn't willing to take a stand on it.

> develop their own support silicon and then the main SoC

Their Pixels don't exactly enjoy long support lifecycles, either.

Pixels use Qualcomm SoCs up through pixel 5

There is this thing called support contracts, maybe Google could try that out on their suppliers.

If I still had the option I would have kept using Windows Phone devices.

All my devices have had more updates during their lifetime than the Android devices I got from similar age.

Incredible how Microsoft managed to do something, that Google deems impossible in the Android ecosystem.

Lineage is always good for older (and certain new) phones.

Reply on news.ycombinator.com