Hacker News Reader

Comment by pedrocr | Hacker News Reader

One thing I'd really like to see Google try and fix is upstream kernel support for the phone platforms. Right now there's no chance for an open-source project like LineageOS to be able to support all devices properly when each and every single device is stuck on an old kernel often with a bunch of important CVEs unpatched. It's as if Ubuntu needed to do independent development for each and every laptop. Without something like that buying an Android phone is a mine field of various states of broken software provided by phone manufacturers. It's like trying to buy a consumer wifi router without the knowledge that if it's supported by OpenWRT you can just ignore whatever broken software the particular manufacturer put into it and will never support going forward. The first rule of hardware is that hardware makers can't do software and Google seems to have mostly given up.

View on HN

https://source.android.com/devices/architecture/treble

This is Google's attempt to do this, in a sense, but as the sibling post points out, vendors are so resistant to adoption that it's just slowing Oreo uptake. And yes, Treble just abstracts the framework from the kernel - but it requires a much more modern baseline and the common HAL interface should make kernel front-porting much easier and therefore allow manufacturers to ship less broken kernels.

That's only a way to get shiny new Google stuff over the supplier's extremely crappy base that will be even less likely to ever get upgraded. The fact that people point it out every time I mention the mess we're really in shows how it's a step back because it takes weight off the issue.

I see what you're saying - that having a common HAL interface will allow Google to ship newer Android over the same broken kernels. However, the base requirements for the Treble kernel and certification require a level of quality beyond what most manufacturer kernels currently offer, so I think it's at least a step forward before it's a step back.

My point is that if it's indeed a small step forward, which is highly debatable, it's a huge step back from actually solving the underlying issue. Lenovo doesn't ship a half broken Linux kernel every time they release a new model. New stuff just gets rolled into upstream and then hardware gets support for close to forever. I bought an Android phone 4 months ago, selected specifically to be supported by LineageOS and in the top 20 in terms of usage. As it turns out support will not be added to the next Android version because specific kernel support would be needed and there's just no reasonable way of achieving it.

It's a fairly big step forward for the common user. There are two parts to it. The kernel used by OEMs is now mandated to be an eLTS version, which is 4.4 now, and the kernel will get backports for another 3 years I think. Treble makes porting new AOSP versions easier. It doesn't affect the kernel version too much directly, AFAIK. However, with 4.4 and treble, every device should get updates for another 3 years. And 3 years is better than 0. So there's that. About your phone purchase, there is no other manufacturer that has done a better job than Google so far. So if you care about these sorts of things, just buy whatever Google sells.

Google sells at outrageous prices for everyone on 2nd and 3rd tier countries.

Additionally it isn't even available in most of the world.

>The kernel used by OEMs is now mandated to be an eLTS version, which is 4.4 now, and the kernel will get backports for another 3 years I think.

That's only true if someone is willing to actually apply the changes over the hacked up kernel the manufacturer shipped. Even well organized projects like LineageOS don't manage to do that:

https://cve.lineageos.org/kernels

Not upstreaming changes is the issue. That's what makes you stuck on an insecure kernel, not the particular kernel version. Having an LTS kernel will help but it doesn't solve anything.

>However, with 4.4 and treble, every device should get updates for another 3 years. And 3 years is better than 0.

Maybe most devices will get an update of the Google shipped stuff for 3 years. Most will not get things like Spectre mitigations in their kernels. And because Treble will be an argument for why this issue is fixed the long term outcome keeps getting worse and this will never get fixed.

>About your phone purchase, there is no other manufacturer that has done a better job than Google so far. So if you care about these sorts of things, just buy whatever Google sells.

For what I want, a proper upstream kernel that has a chance of being supported going forward, Google phones are no better as far as I've seen. They're just subcontracted phones to one of the manufacturers anyway.

Just rhetorically, if it's the response to your concern every time you write a post, then you need to incorporate why it's not a solution in your original post. I assumed you hadn't heard of Treble and was just about to point it out to you.

You're right I should have mentioned it. I thought about it but the text was getting too long already and I was in a hurry.

Not really, it would a real attempt if it was actually enforced, but given that Nougat updates to Oreo don't require Treble certification, and the OEMs are the ones expected to deliver any kind of updates, it is pretty useless to change the current state of affairs.

I mean, Google are requiring it for all Oreo launch devices, which they all must be after the P release (you can't get certification for Nougat after P releases).

It's at least something that'll work long term.

Still if the updates aren't enforced, all we will get are Oreo devices without updates, Treble or not.

Once you have Treble you can get third-party updates (e.g. LineageOS).

That doesn't work for regular phone users.

Regular phone users don't care, which is why we're in this situation at all.

They do care on iOS.

Eh, that might be true today, but I doubt we'll see flagships shipping with Nougat still by the end of the year. I certainly won't be buying any like that primarily for this reason. OEMs will catch up sooner or later. It's a slow process, but don't write off the long game for the short one.

Once P is released they won't even certify Nougat devices anymore.

Experience tells me OEMs won't change their behavior unless legally forced to do so.

Aren't they contractually obligated to comply with CTS / VTS in order to get the Google Play stuff? The Chinese OEMs and Amazon Fire line opt-out, but pretty much the rest of the Android ecosystem opts in.

They are. Even to call their OS 'Android', not just usage of the Google Play Store.

Nowhere in Amazon Fire tablet's page does Amazon use the term Android to describe the device.

CTS/VTS does not require providing updates.

I work at a hw vendor that builds android for our SoC and we're still on N, but it's not because we're resistant to adoption of treble.

Treble has been more like the straw or boulder to break the camels back. Not only is it a lot of work on its own, it has also triggered a bunch of refactoring.

People are actually excited about Treble and how it should make kernel and android updates easier in the future. It's just a lot of work in the short term.

There are two issues here really:

1.) Android kernel patches are pretty extensive and Linux folks (understandably) don't want to integrate several of them. Some powersaving things, binder and a few others are pretty Android specific and very intrusive, so the mainline kernel folks don't want to accept them in the current form. I doubt there's a business payback of rearchitecting the core of the OS just to mainline those patches.

2.) SoC manufacturers refuse to opensource drivers and refuse to support their chips for longer than a year or two. Treble should help a bit with OS updates/LineageOS but at the end of the day, you're at the mercy of the guy building your sillicon. And currently they have all the leverage since there's practically no market competition.

Actually the baseline patches are perfectly fine and most of them are integrated (in staging) already. Only cpu governor is not and it is not really required.

What is not is obtuse patches of chipset manufacturers. These are really low quality...

> "when each and every single device is stuck on an old kernel often with a bunch of important CVEs unpatched"

As an iPhone user, I've heard about how one of the benefits of Android is that it's built on OSS, so that if you wanted to have a fully secure phone, you could just download the latest kernel and patches and software and install it yourself. Is this actually possible for Android users?

Phone manufacturers always buy the drivers from chip manufacturers, and under closed licenses. The source is rarely ever published, you can't download the kernel patches and do anything. Often you'll wait months or years to get the kernel the manufacturer used, and it will have been so old that none of the drivers will work on a recent linux kernel anymore at all.

The situation isn't exactly great. And torvalds believes it to be more important to talk nice to these companies than to enforce the GPL, so nothing's been moving in the past decade at all.

Yeah, the only hope we've got is to move to a more Windows-style driver model, which is what Treble attempts to do, abstracting the HAL from the kernel and application software. This is already shipping in Android O and new devices on O or P must be Treble certified to ship Play Store, so we should see this improved greatly in upcoming devices.

If only OEMs weren't the ones expected to do Treble updates....

If they are fully compatible it means community updates can work better too - not needing to worry about the HAL as much.

Yes, Google might need to take one more step of saying "and we ship the security updates" before the average user benefits - but that can be done down the line if the situation merits it. Developers and power users will be able to take advantage of it even sooner. A single codebase for LineageOS? Yes please!

Community updates don't count for regular users, nor does LinageOS.

> Is this actually possible for Android users?

Not even close. Android security is a joke. I don't even like to login to my email from it.

Are you sure it isn't iOS security that's the real joke? I mean, just do a search on YouTube for all of the lock screen bypasses. And then there's Cellebrite and their ability to unlock any iOS device for the relatively paltry sum of $1500 or you could just wait for a 2 for 1 special and do 2 for $750. The Pixel phones are virtually unhackable and not one has ever fallen at a PwnToOwn event. iOS devices, on the other hand, always fall at these events.

To an extent. You'd have to be pretty tech savvy and fairly involved in both ecosystems to actually run your own android builds and stay on top of security.

I know of one example of an Android OS which is focused on security and privacy. Check out CopperheadOS [0]. Their technical overview [1] details some of the improvements.

* Possible disclaimer? I run CopperheadOS on my old Nexus 5X.

[0] https://copperhead.co/android/

[1] https://copperhead.co/android/docs/technical_overview

The irony being that in 2018 most new devices are being released with Nougat, with eventual update to Oreo, if at all.

Why? Nougat devices don't require Treble certification.

Hasn't this been a thing since forever on Android? People are always lamenting that uptake of the newest version (or newest 2 versions) is slow.

Do you actually have evidence that the uptake of this specific version is slow? Otherwise I don't see any reason to believe this is out of the ordinary for Android.

I remember when it took forever to go from Donut to Eclair on my T-mobile MyTouch device... when the newest version was already Froyo.

Yes, the evolution on dashboard, currently at 1.1% about two months away from Google I/O, probably one of the lowest numbers so far.

https://developer.android.com/about/dashboards/index.html

They'll have to move at some point. If the transition is painful/long, so be it. The affected companies is why we're in this mess in the first place. Now Google enforces the new rules about the platform compatibility, so let's see how it plays out.

There is no enforcement being made by Google, OEMs get to decide if they ship any kind of updates, even with Treble.

The enforcement is in Treble. The first OEM to embrace it will be able to advertise as more up to date than competition. One is all it will take...

> The first OEM to embrace it will be able to advertise as more up to date than competition.

Except I don't know how much this will matter, given that the average user doesn't know or care about any of this stuff.

We're at the point where not much matters anyway. The phones we have are amazing. Sure, it doesn't make much difference, but it's a selling point.

Other advertised features which don't matter to most users: the notch, AR, full size display, active display on edges, assistant updates, AMOLED, app privilege restrictions, curved displays, ... They're all good for advertisement and gimmicks. They may improve the phone a little bit. They're not needed and almost everybody cares only because they were advertised. (If they care at all)

It is not.

Treble does not require OEMs to push updates.

This has been clearly explained on the ADB Podcast and nowhere to be seen on the certification requirements.

Are you able to see something I can't? I get a few pie charts showing current use in the last seven days, but I can't see any evolution (e.g. I might expect some kind of line graph with time along the x axis, proportion on the y axis and separate lines for each version; or maybe a 2D table with again time as an axis).

Or perhaps you're just accustomed to monitoring this? With respect, I don't think that constitutes (neutral, inspectable) evidence, but rather witness testimony.

Anyone used to do Android development checks those charts regularly.

But that is also pretty typical. It moves really slowly, and then a few major new devices are released and others almost simultaneously get updates.

Hey look, the S9 and S9+ are launching with Oreo, the S8 is steadily getting it, and the Note 8 will be getting it realy soon!

Not everyone is using expensive Samsung devices.

I'm waiting for the relatively more reasonably priced Nokia 7 plus (or another Nokia model with AndroidOne.)

I'm not sure how that is related to my point? I don't use expensive Samsung devices either and won't be updated to Oreo any time soon.

But Samsung does have a large market share and them moving to Oreo right now will make the numbers start to shift pretty quickly.

Basically, Android adoption tends to be glacially slow for quite a few months (~2% total), fast for the next few (up into the 20% range), and then the growth slows again for the next year or so with no single version ever quite hitting 50%.

So then how is it Google's fault? They introduced a way to sold this, and now manufacturers are the ones holding back...

Google already has a few contracts in place for validating OEMs access to their services.

They just keep "forgetting" to include updates on the requirements clauses.

There's a predefined window for when a device can be certified for release with a particular Android OS version. I don't know what the current window is, but devices that are shipping now (Q1) likely got certified some time last year in Q3 or Q4, well within the window for N.

It's significantly harder to enforce things like update requirements after a phone ships - for one thing, it's not entirely up to the OEM in many cases, it also depends on getting carriers to certify the upgrade.

Right now in Germany, the majority of supermarket handsets are still being sold with 4.4 and 5.0, without further updates.

Once a device is certified, a manufacturer can keep selling it indefinitely, I believe... and/or those may not be actually Google certified devices. (Especially with very low end / no-name handsets.) When I referred to "shipping" devices, I meant new devices coming to market.

> Right now there's no chance for an open-source project like LineageOS to be able to support all devices properly when each and every single device is stuck on an old kernel often with a bunch of important CVEs unpatched.

No even if this was fixed it still wouldn't be possible. For those outside of this US a fix would helpful, but a fix really wouldn't be that simple. For those in the US most phones bought by major carriers have both locked boot loaders and are locked to a specific network. The Pixel being sold by Verizon has a locked bootloader despite it being Google's own branded phone.

That's only a problem if you choose to make it one. I buy my phones unlocked from retailers and ignore the carriers.

It would be simpler just to tell OEMS that they can't distribute computers where the user is locked out of the machine. Safety oriented exemptions may be reasonable but it needs to directly speak to consumer devices first and foremost.

Reply on news.ycombinator.com