Hacker News Reader

Comment by mmastrac | Hacker News Reader

It will be interesting to see what Project Treble brings to the table w.r.t. long term support for Android devices. It should help with the bitrot problem, though it pushes a bunch of stuff into blobs instead of creating long-term maintainable kernel source code.

View on HN

Google has been promising to 'solve' fragmentation and long-term support for almost a decade, and it doesn't seem like there is any real solution.

If you interested in long-term updates, the answer is simple: buy an iPhone.

We agree that Google hasn't completely solved the support problem, but it's not to say Treble hasn't improved things.

Android Pie: https://www.androidauthority.com/project-treble-2019-1045370... Android 11: https://9to5google.com/2020/12/16/android-updates-4-years/

For the lucky ones buying flagship phones, it has hardly changed in the traditional models used by pre-paid customers.

> If you interested in long-term updates, the answer is simple: buy an iPhone.

I would, if apple wouldn't dictate what i can and cannot install on my phone.

Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates?

> Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates?

A touchscreen notebook with a GSM/LTE modem and a decent microphone running Linux is the closest you can get today as far as I know

Or, you know, almost any Android phone from a reputable brand like Oneplus for example.

cheeky comment considering the premise was long-term updates.

while there are android phones that are supported by custom rom's up to ~5 years (exceptions even longer), the majority isn't.

meanwhile a 5year old iphone se is seamlessly supported by the manufacturer and probably will be for a few years to come.

Longterm official updates? Not that I've found. Your best bet is likely to buy a high-specced device that allows root + unlocking the bootloader and flashing a custom ROM. That's probably what I'm going to do (minus rooting), even though I'd greatly prefer manufacturer support.

The answer is a monolithic GPL kernel that forces manufactures to publish driver source code but they don't want to admit it.

Or a Windows-style stable ABI with drivers remaining closed-source. That's what Google are doing with their new Fuchsia OS and Zircon kernel, which is expected to replace the GPL-licensed Linux kernel on Android and ChromeOS devices.

Basically their moving away from the copyleft Linux kernel.

Given Google's awful track record with Android and security updates, and their lack of ability to force companies like Qualcomm to provide longer support windows, I'm not sure their new strategy will be successful.

Inevitably they'll be severe vulnerabilities found in the drivers including eg, Cellular radio / baseband drivers, Bluetooth driver, Wifi driver, and the vulnerabilities will never get patched.

Hopefully Google's capability-based microkernel approach with Zircon will stop this ever happening. But again, given Google's atrocious track record with Android and security I highly doubt it.

Even Windows doesn't support eg, i586 and i686 CPU architectures yet the Linux kernel does, so it seems like copyleft drivers are the only way to get security updates decades later.

This will allow the same blobs to keep working but won't get those blobs essential security updates.

This isn't a technical problem, it is an economic (and social and legal) problem.

Well it is a technical problem: it can be solved by reverse engineering and re-implementing every driver.

But yes, it's an economic problem because that's pretty expensive (but has been achieved before eg, nouveau driver)

Google could easily use their monopolistic position to force all SoC vendors to provide greater software support.

Heck, Google could even simply pay every SoC vendors to open source their drivers. It's unlikely to even cost that much.

But today's Google is simply too incompetent to ever fix Android's security update problem. They've been making silly excuses for decades.

> Hopefully Google's capability-based microkernel approach with Zircon will stop this ever happening.

Just a correction, I meant "Hopefully Google's capability-based microkernel approach with Zircon will reduce the incidence and severity of vulnerabilities being exploited once they are inevitably discovered".

Hasn't treble been around for years now?

I, as an OSS community contributor, have been using Treble for years now, and I have devices who got let down by their OEMs on Android 8, that I pushed up to Android 11, and that's been pretty cool.

I, as an OEM, am still NOT allowed (by Google) to use Treble to provide upgrades. This "legality" issue is being fixed ( https://android-developers.googleblog.com/2020/12/treble-plu... ), but its effect won't reach users for at least 2 years.

I don't see anything in your second link that explains what the "legality" issue is, could you clarify that for me, please?

The idea of Project Treble is to separate drivers from Android, and also to version drivers. When you receive a smartphone running Android 10.0, you also receive drivers "targetting" Android 10.0. With Treble, you can replace that Android 10.0, and bring it up to Android 11.0, while keeping the drivers targetting Android 10.0, and this pretty much works.

To release a smartphone with Google apps, an OEM must adhere to some requirements. One of those requirements, is that if you provide to customers an Android version X, then you must provide drivers targetting this version. You are not allowed by Google to provide an Android version 10 with drivers targgeting Android 9. This is true even across updates: if you release the smartphone with Android 9, then upgrade it to Android 12, then the Android 12 upgrade must include drivers targgetting Android 12.

The change that is coming, is that for Android 13, OEMs will be allowed to keep the drivers they made for Android 12.

I wonder what the motivation was initially, to implement a glue layer that let you keep older drivers functional, only to also require the drivers be updated in lockstep. (Specifically the benefits of the lockstep update policy, not Treble in general, I grasp that.)

Reply on news.ycombinator.com