Hacker News new | past | comments | ask | show | jobs | submit login
Treble: A modular base for Android (googleblog.com)
419 points by chickenbane on May 12, 2017 | hide | past | favorite | 219 comments



Finally, can't believe it took them this long. The sorry state of the update situation is one of the worst things about Android. Next step would probably be to provide an API to the OEMs so they can add their "value add" functionality as apps, so Google can push updates to all phones regardless of hardware drivers and OEM modifications. And maybe make it possible to update emoji via the Play store, instead of needing a new system update. I don't like the blank boxes in messages from my iOS friends.

I wonder if this means that Google will lead by example and prolong the time they deliver updates to their own phones. They don't guarantee new updates to their current Pixel phones after October 2018 [0], which is not good enough.

[0] https://support.google.com/pixelphone/answer/4457705?hl=en


It is an illusion to think this will ever change, if Google doesn't make it legally binding to having updates in place to access Google Play Services for example.

There are no incentives in place for doing otherwise.

Already in the old days, Nokia was one of the very few manufacturers that bothered to provide firmware updates, and even then usually only once.


If Google makes it easier for manufacturers to make phones that can be updated OTA by Google than phones that can not (custom Android builds) most of them would probably do so. Have a hardware layer, an Android system layer, an OEM layer, and have a clear interface between them so they can be updated independently. Then Google should push updates themselves, they can't leave that to phone manufacturers or carriers, like you said, there's no incentives for them to do so. Of course, this has been an issue for Android since day one, so I wont hold my breath.

Are there any work done on a system similar to the one on PC, where software can enumerate available hardware? We have advanced computers in our pockets, but they can't be updated to a new OS version as easy as a 15 year old PC. It's ridiculous.


But "ease" isn't the problem - the issues OEMs have are because they literally go hack and fork the AOSP source itself (making upstream merges hard or impossible) for sometimes really dumb reasons. This is also the source of constant headaches for us app developers (like the recent case where Realm found out that Samsung broke memmove() on their devices!).

The other issue is that there's zero (0, no) incentive to update the devices. No matter how easy it is - the OEMs see that as a pure cost that won't be recuperated. For each of the (literaly!) 100 devices they churn out per year they need to get new drivers from the SoC manufaturer (and Qualcomm pretty much does not give a crap about SoCs of the previous year, especially lower end ones - which makes this process stop there), update the kernel and move all their specific hacks to it.

I don't see how these changes Google did will change incentives. The only way we might see a change in this field is by a few class action suites from users being left without updates or regulators putting down the punitive damages hammer. Everything else is just Google kindly hoping OEMs will stop being dicks from the goodness of their heart.

In car industry we have strong regulation which demands that your car is serviceable at least 5 years since last unit was sold (and that their security issues are fixed by recalls). We need that for arguably the most important electronic devices in our lives as well.


> No matter how easy it is - the OEMs see that as a pure cost that won't be recuperated

Treble removes much of the cause for forking, and removes the cost for OEMs that follow it's design.


Google can leverage a lot of control using Play Services. If, as gp suggests, they also create an OEM layer so the OEM doesn't have to fork Android and instead just builds on top of safe APIs, allowing Google to take over updates entirely, then Google can force OEMs to use it.


You pretty much made the entire thread superfluous. Very well articulated and I fully agree, the suits don't care if you reduce their expense if they can skip the expense whatsoever.


This is a bit above my pay grade so forgive me if I'm way off target but...

To some extent doesn't this make a case for (say) HTML# and browser based apps? That is the browser is a known sandbox of sorts. It's interface with the device (e.g., Phone app) is a known, and fixed. It has no care about what's on the other side of that wall. And the device OS more or less exists to run and support the browser.

But when the applications interface directly with the device, and there are countless device and OS, etc. combos there will always be a mess. Too many variables. Too many chefs in the kitchen if you will.

I realize I probably oversimplified. (Sorry.) I'm also outside my knowledge sweet spot, but am curious enough to want to learn. Please don't hurt me. Thank you.


It absolutely does. If webasm works out this is how I see things going. Android is already running things through a JIT.

I don't think users want dozens of apps installed on their phone, each with the possibility to be using up bandwidth, hogging resources, stalling programs and draining battery life, not to mention abusing permissions. If most apps can be done with webasm (and I don't see why the majority of apps can't be) then the only things that need to run in a more native context would be apps that use special features.


It also does AOT compilation with PGO gathered from the JIT.

Unless the browsers offer APIs at the same feature level as native OS APIs, web applications will always be a second class experience.


Only for apps that need those native features.


For example? As in, what doesn't Phone Gap offer access to?

But in any case, to your point, native apps should be limited to special cases (that can't be done via the browser). That's not the case ATM.


Which means any app that respects its users by providing a suitable UI/UX using the best features of the OS running on the device they paid for.


What does that even mean? Lots of apps don't need anything that isn't already exposed in newer web apis.


It absolutely does. I'm helping out on a bespoke app that needs to run on some discount Chinese tablets that are stuck on Android 4.something, and it's easier to target Chrome (which is still being updated) than the OS itself.


I am more optimistic than you two, i think for mide range and high range devices, there is incentive: competition.

But i have to agree, for low end devices, even from famous companies i dont think they will update their phone even with this.


I remember having to physically take my Nokia Communicator into a service center to get the firmware updated.


> Already in the old days, Nokia was one of the very few manufacturers that bothered to provide firmware updates, and even then usually only once.

When you put it that way, it seems like it's gotten a lot better.


Wasn't it Google's fault anyway. Without a stable ABI, updates will require SoC vendor involvement, which is a limited time affair.


That is what contracts are for.


So a Qualcomm refuses to sign such a contract. What are going to do, use Mediatek for your flagship?

On the Porters five forces scheme of things, the SoC vendors have much better bargaing power than device makers.


There is a free market out there.

Long time ago, people also though ARM was going to close doors.

If Qualcomm refuses, other would gladly do and eventually become good enough for Qualcomm to either change their mind or become irrelevant.


Talent and IP are in extremely limited supply. Your alternatives are mediatek and spreadtrum.


So be it.

The majority of my devices don't have Qualcomm.


Towards the end of the featurephone era it became more common.

And i think Nokia got into it because they had a very popular model that was found to have a nasty flaw. I still recall news reports about people queuing to get theirs flashed (this was back when GSM was the hot new system, and carriers were giving away phones if you signed up with them).


A stable binary device-driver API has always been resisted in Linux. I suppose that's what Treble is?


Not exactly. Treble is a stable API between userland and kernel. Userland can be quickly updated even if the drivers are not, and if the drivers are updated, userland can stay the same.

The long term plan smells of Magenta.

Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>.


> Treble is a stable API between userland and kernel.

Stock Linux definitely has a stable userland API, though I imagine that third party driver vendors don't know how to do stable userland APIs.

> Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>.

As for driver ABI compatibility, I know that almost all enterprise distributions maintain kABI compatibility for a particular release of their distribution (this is one of the selling points of such distributions). I believe there are also some community distributions with similar stability guarantees (for instance openSUSE Leap uses the same kernel as SUSE Linux Enterprise, so I would assume the same guarantee is provided).


"stable userland API"

Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability. Try the same with some Windows apps and compare and contrast.

API == ABI for stability purposes, and the kernel isn't the problem, otherwise things like docker wouldn't meaningfully work at all. It's all the auxiliary libraries, much larger surface area.


> Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability.

The issue is the dynamic libraries (which are handled by distributions in different ways). Try statically compiling a binary like that and you'll find that it will work between distributions and kernel versions.

> Try the same with some Windows apps and compare and contrast.

Because they include their dynamic libraries with their programs, which has its own tradeoffs (updating security issues in shared libraries is much harder, even if you had a package manager on windows -- which you don't).

> It's all the auxiliary libraries, much larger surface area.

Right, but GP's point was that Linux doesn't have userland-to-kernel stability and I was saying that's simply not true. It's true that there is no stable upstream driver API but there are also solutions to that problem as well.


Have you ever tried to statically link a program on Linux? I'm guessing not. Until recently it was more or less impossible because glibc cannot be statically linked. Nowadays you can do it with musl but it still takes significant extra effort.

It's not as simple as "windows programs include their dependencies". Windows has far better forward and backward compatibility than Linux (by which I mean Linux plus the required userland stuff - libc, ld, etc.)

That's kind of to be expected. Comparability is tons of extra effort that open source can't really prioritise, but don't just pretend that it is as good as Windows.


> Have you ever tried to statically link a program on Linux? I'm guessing not.

This is where autotools helps: ./configure --static. There are also equivalents for CMake.

Aside from that I also statically compile Golang programs all the time (specifically runc which is a container runtime that uses cgo and a bunch of other magic). If static compilation didn't work, neither would our releases.

Just because Rust only lets you statically link binaries if you use musl doesn't mean that nobody else knows how to link things statically.

> because glibc cannot be statically linked

This is patently false. It is true that glibc will make static linking _hard_ but it's definitely not impossible. You need to set some magic settings (that autotools does for you) which disables all of the dynamic loading stuff glibc does.

> It's not as simple as "windows programs include their dependencies".

But it is. If you ignore the core system libraries, and included all of the other library dependencies with programs, most of these problems would be fixed.

> Windows has far better forward and backward compatibility than Linux

glibc has symbol versioning so in principle (I have had to use this once or twice) you can use an older program (linked against an old glibc) on a newer glibc.


glibc-static works fine for my Golang programs that are being compiled on RHEL hosts in the CI and then shipped as Alpine-derived containers (which is why I need to link libc statically; ain't no glibc on Alpine).


The problem you'll have will be with the dynamic libraries, not the kernel. If you stay with statically linked binaries or you package your binary with its .so, everything should work fine.


If you link everything statically, you must (a) have the right to do so, and (b) you now subsume responsibility for security patches for all your dependencies. These are two very big asks.


Watch container based "solutions" to both sprout like wildflower...


Correct, the issue isn't in Linux itself.

It's in drivers, third party kernel modules, libraries, etc.

But that doesn't make it any easier.

On desktoo GNU/Linux or GNU/NT we don't have easy stable environments, and the fight between dynamic and static linking is always won by static linking. In the GNU world, that ended with snap/flatpack/docker/rkt/containerd


Only for those to introduce their own problems, like having some insecure lib sitting in a container somewhere...

I really wish userland devs would spend more time actually maintaining API/ABI stability, and less time reinventing wheels because they are not "perfect" (after whatever arbitrary marker for perfection they work with).


To be honest, Alpine Linux based containers on Kubernetes are so amazingly stable, and "just works", it’s amazing.

But yes. One issue anywhere, and I can upgrade everything again.


I just switched to iphone se 4 months ago, and I couldn't be any happier.

Tbh i did like android, but the only problem for me was 2 year only update. That is not enough. Not even close when similar products from apple get 5 year suppurt. Specially now, after passing a threshold, our phones SoC are capable of handling ordinarily jobs (like if you are not into playing AAA games) for more than 4 years, performance wise.

P.s. After using iphone for 4,5 months i have to say , their i products are awesome. Far superior than android in term of consistent performance and fps.


"device makers can choose to deliver a new Android Update" ... "can choose".

Preferably they shouldn't be able to choose. Google should be in charge of updates and manufacturers should have to make a special effort to prevent an update. i.e if they are certain that an update will brick their device they would then make a formal request to google not to send the update to their devices.


That's just not how businesses work. Companies that sell Android phones want to have control over their platform, and above everything "differentiate" themselves from other android-selling companies.

Also note that each company has different hardware, custom drivers, etc. ; those are often not compatible with new updates and they need to do additional work to make things work correctly, work which they might just refuse to do.

No hardware company is going to refuse to update Android "just because". With this modular base, they have no reason to not update.


This made me realize just how weird the phone business is. Because it's not how "businesses" work at all! It's just how smart phone manufacturers currently work.

Imagine if Microsoft couldn't publish security updates without going through Dell, HP, AND your ISP, and you start to realize how crazy the situation currently is.


The actual weird thing is the PC market, which is pretty much the only place where a third-party software manufacturer is not treated as a subordinate supplier by the hardware manufacturer of the device the software runs on.

And it's mostly a side effect of the missteps that IBM made in the 1980s because they didn't understand the market dynamics, which is why they aren't in that market, commodity manufacturers are, and Microsoft was the big winner, not any of the hardware players.


Well, Google could have just pulled an Apple and don't licence Android for manufacturers that allowed this. Can't tout "bigger install base than Apple" with that, though.


With this modular base, they have no reason to not update.

They do. It is not only a technical problem. If it was, they would be happy to roll out security updates for existing Android versions (without rebasing to later releases).

A large part of it planned obsolescence. Device makers and carriers want users to buy a new device every two years, to make money and tie them to a contract longer. A newer OS version plus security updates is a big selling point. Secondly, vendors and carriers just don't want to put in the development time and testing. Since most users will buy the hardware anyway, why waste money?

The only real solution to this problem is that Google would require minimum support terms in order to license Google Play Services. Or a change in consumer mindset.


Agreed. Updating the phone being easier won't solve the problem. The problem is a mismatch in incentives.

Manufacturers don't have an incentive to update older devices because (1) they don't want to put any resources into last year's phone and (2) they want their customers to upgrade to their newly released phone.


You know, one part of the Apple ecosystem dynamic I find interesting is the used market. Some people I know upgrade yearly, and because the used market for a 1 year old iPhone is pretty strong, they can sell their old one to recoup some of the cost. It's still a spendy endeavor, but a used iphone 6 goes for like $180 bucks, which isn't bad for a phone released nearly 3 years ago.

I'll let others do the math on depriciation rates, as the point is that Apple supports their phones. Hell, iPhone 5's got an iOS update last month, and that phone was released in 2012. If you buy an iPhone, you know that a) it will be supported for a good long while, and b) as a result, its resale value will be high.

Apple's trick is to realize that high resale values help sales, not harm it. It likely helps that they get a good slice of profit on app sales, but it's not clear to me that cheaper handsets would lead to proportionally more app sales. And it helps that no manufacturer can swoop in and release a cheaper iOS device to challenge the market for used iPhones. So it might not be enough to persuade rando Android handset manufacturers to support devices, but this might explain why the Nexus lineup was replaced with Pixels.


"Apple's trick is to realize that high resale values help sales"

I think that's only an extra. Their real trick is that they realized that, as long as each new generation of phone is a lot better than the previous one, they don't need to design mid-end phones, but can instead sell last year's phones as this year's mid-end phones.

Apart from the "don't need to design" part, that means they don't need to market those mid-end phones as much, as millions of people already walk around advertising them. Also, customers who buy such a phone do not look like mid-end device buyers; they look like premium device buyers who bought a new phone last year.


Still waiting for a phone brand to bite the bullet and offer paid updates. Because it's either that or no updates. I know what I would prefer.


It still won't solve the "Qualcomm won't update the BSP" issue, though.


This right here!

Closed SOC BSPs that are tied to android are the real problem! If google had stuck with the standard Linux APIs or added appropriate new one when they needed them and where more strict about open software we wouldn't be in this mess.


Not true. Witness the routers or another embedded devices, that are using standard Linux and yet are never updated.

Or worse, coming with obsolete kernel right at the release day.


What is this issue?



Good idea. It fits now more than ever. I have said this before. Right now SoC's are passed the threshold performance wise. For e.g if you are not into playing high end games your phone cpu is enough for 5 year if you only doing web browsing watching movies and reading mails.


The take rate on paid software updates probably wouldn't be good enough for that to be a realistic option.


If consumers actually cared about this the manufactuers would. However aproximately no one actually checks support cycle as a feature of the phone.

I do, and unfortunately that leaves me (and my family because I have convinced them) with Nexus, Pixel or iOS devieces. I can't find another device with any sort of update promise at all.

Until a significat number of poeple start to care about, and demand a well defined update policy this will not change. We need to create the incentive for the manufacturers.


Find something that's supported by LineageOS (or similar). That won't give you warranty, but it will give you updates beyond what the original vendor offers (or Google (or Qualcomm)).


Removing the burden of updates for OEMs makes it practical for an OEM to differentiate on update support. If any of them does that, it creates competitive pressure on others; and if users care enough to purchase based on support commitments, some OEM will have a strong incentive to be the first to differentiate that way.


And (1) is in part because they deliberately put in extraordinary effort to customize and break Android, increasing the costs of merging from upstream.


And Google doesn't really have a real incentive to fix the situation either. It's not really a "we need to fix this by next year or people will stop buying Android phones!" type of situation. They still make money on ads on Android, whether they are secure or not.

At least if you could adblock mobile ads to stop malvertising, as some already do on the desktop, Google may have had a bigger incentive to fix it. But they removed that incentive a long time ago when they decided adblockers aren't allowed in the store.


You can still get them on your phone, though. DNS66 on f-droid.


Google probably feels that they're not yet in a position where they force this. My money's on this being an intermediary step towards what you're asking.

Something like: 1-2 years from now Google will change the agreements with the manufacturers (probably when their current agreements expire). Under the new agreements, Google will publish a new version of the base, and manufacturers will have N months to update. After N months Google will just push the new updates even if the manufacturers do nothing about it.


This is missing the point I think. Google does not want to push updates because that requires them to do the massive job of verification and validation necessary to push new features to so many hardware variants.


Microsoft does it. Every Linux distros does it.

Assuming they can maintain compatibility with existing drivers it should be fully possible for them to just update a few relevant OS components, especially for security updates. Feature updates may pose a bigger problem, but aren't really a major issue in my view. Leave that for manufacturers if need be.


Microsoft mobile system runs on exactly one SoC. Even for that, the different brands of devices had different rollout dates.


I'm talking about their desktop OS, Windows.


Desktop OS has UEFI or BIOS available for boot and platform services, together with enumerable busses, so you can find out what hardware you have available. Such things are luxury in the mobile world, you need to know what hardware you have in advance, otherwise wrong poke and something will hang.


It's entirely possible to present a solid ABI that would allow vendor specific boot and hardware access. I can see no reason those can't be abstracted out.


Because it's the vendors, who are not interested in the first place. See also stock Linux, device tree, it's problems.


I believe that would be too much of a headache for Google to manage. E.g., having to deal with vendor push back. The liability ultimately lies closest to the end user, and for the device itself, this is the device manufacturer. Let them deal with the headache of forcing their customers to update. Of course, I could be wrong, but that is just my humble opinion.


This should usher in a new era of cheap phones that upgrade immediately to the newest version of the Android OS.

It lowers the price floor for a shiny new phone. All of these additional features are expensive to create but, they are differentiators. With this, Google has the ability to push more new features on the base OS. By conforming to this standard, Google make it easier for them to compete with all of these manufacturers' features.

Now it's up to them to make compelling reasons to upgrade their phones beyond apps. I see things like Google Assistant, Mapping, etc. being more integrated into the OS so that you are always in the Google system no matter what app you are currently in.

This is a big and brilliant win if they can first pull it off technically and then pull it off with compelling services. They certainly look like they are investing heavily in both.

I look forward to a $99 or $199 (or $49 if you can stomach sketchy Chinese phones) phone that just keeps getting better and better and better for free as long as the phone works. This also makes a very compelling thing to make the phone into a computer once the battery can't hold a charge, etc. Take the guts or use some kind of USB->HDMI out and make it into a TV app or a digital mirror or another internet station somewhere.

Brilliant move Google.


> I see things like Google Assistant, Mapping, etc. being more integrated into the OS so that you are always in the Google system no matter what app you are currently in.

No thank you. I use Android because it's a free and open system.


Given the lack of updates and the missing parts on AOSP source tree, that is a fallacy.


I am amused that their graphical representation of the Android version customized for a particular model of phone is "Android mascot dressed up in a really cool spacesuit looking thing" and not "Android mascot with bags of trash stapled haphazardly to him," which would probably be more accurate.


> really cool spacesuit looking thing

Look closer - its a fetching combo of fanny pack, boxer shorts, ice skates, ski goggles etc. pretty much the crap you wanted.


That's really awesome - thanks for making me go back and actually look at it.

Upvoted the grandparent, just to keep it high in the list so that your comment would stay near the top of the page...


Some of them are actually rather nice, I really enjoy OxygenOS for example (the vendor OS for OnePlus phones). It just seems that a lot of the awful OS' are delivered by the larger companies.


Do vendors actually want to let users update the software on their devices though?

I would have thought new shiny software was a nice incentive to get customers to upgrade to a new phone?


It's worth keeping in mind which vendors are being talked about here.

Treble fixes the problem of "manufacturer who didn't do any customization can't update because Qualcomm never updated their drivers & friends" by ensuring that the level that the Qualcomms, Nvidias, etc... build against is forwards-compatible. So small manufacturer can just take a new android source drop from google and plop it on top of the binaries they originally got from qualcomm or whoever and tada! done.

It doesn't help with the "OEM injected so much 'customization' that it's a disaster to move forward and will forever be abandonware"


If only a project existed to support devices beyond what the original manufacturers were willing to put out with singular consistent releases across all hardware.

Oh yeah, Lineage.

If only the company that made the OS actually supported the effort to perpetually support devices with a single OS the way Android should have been from day 1.


The problem is that you have to trust Lineage's (just an example) developers and release process. If you want Google Apps installed you need to trust another 3rd party like http://opengapps.org or https://microg.org/.

At this point I'm not so sure what's better: an updated OS or one full of known exploits.


Why wouldn't they be trustable? You always have the option of building it yourself. (disclaimer, I'm one of the leads & run their infrastructure)


Like I said, it was just an example. I don't have the time or knowledge to review an entire custom ISO and after that another ISO from the Gapps provider that I choose. I'm sure there are some tricks to cut down the review process time but anyway.

It's a trade-off. I'm installing custom software to improve security, but at the same time, can I trust that this solution won't be a source of malware?

I hope this didn't came out as accusatory, I was just trying to show another aspect of using custom ROMs.


It didn't - I'm mostly curious what people's thoughts are on things.

For what its worth, the mirror selection software we're using [1] won't send you to a mirror that has a modified file. If a mirror is doing something malicious (and that doesn't catch it), builds are signed and can be verified [2]. Obviously there's some level of trust involved (build infrastructure isn't auditable, android builds aren't reproducible).

[1] https://github.com/etix/mirrorbits [2] https://wiki.lineageos.org/verifying-builds


I think you're the only one that got it. If the goal is to be able to update the Android OS without the carrier or device manufacturer having to do any work, the CTS would no longer be necessary because Google would control everything that the CTS tests.


Not every vendor has an 18 month refresh cycle -- not everyone is just selling disposable phones and tablets

A lot of people want longer Android support -- especially enterprise installations, which want to pay for software on 4-8 year hardware cycles, but the short length of Android's current support prevents them from doing this.

There are lots of Qualcomm / Freescale chips running Android inside Airplane Seatbacks, and Hotel Kiosks, and Business Wall Signage, and more that simply will not be replaced for many many years. Today, Board OEMs are essentially forbidden from updating these, even if they want to (since Qualcomm / Freescale won't release the tools they need). After Treble, OEM Vendors will at least have the option of updating these devices, even without Qualcomm / Freescale / etc's permission.


Yes, enterprise-size companies want this, especially with regards to security. But companies of that size buy Samsung or/and Apple (in general, I'm sure there are exceptions).

Now, with the prices of these devices they are not exactly what I would call 'disposable', but (for Samsung at least, I can't say for Apple) update availability is highly dependant on the network carrier.

I think Google needs to somehow force the availability of updates, regardless of whether the vendor wants to use updated software as a selling point for their latest phone - maybe Treble is a step towards that.


> But companies of that size buy Samsung or/and Apple (in general, I'm sure there are exceptions).

That's not really what I'm talking about. I'm not talking about corporate issued Samsung Galaxy Tablets. I'm talking about Android embedded into other products. Companies, of any size, don't buy Samsung or Apple for this because neither of those companies really exist in those markets at all.

I'm talking about devices like the Delta Kiosk you use to print your Airline tickets. The self-service checkout machine you use at WalMart. The LCD panel in the wall of an corporate HQ that shows all Outlook meetings scheduled in that room. The newer Smart TVs in Hotel Rooms that let you order pay-per-view and food to your room's bill.

Many of those devices also run Android, and have no upgrade path even though their OEMs desperately want one. Project Treble helps them out, even more so than it might for smaller phone companies (like say HTC).


Apple does not let carriers have any say over software updates for the iPhone.


8 year hardware cycle for phones? You'd still be on an iPhone 3G. That's crazy.


It's because phones were still in an extremely quick development cycle. Think about normal PCs, 2009 would still give you a reasonable PC with Windows 7.

Phone hardware upgrades will become boring like PCs at some point.


> Phone hardware upgrades will become boring like PCs at some point.

I'm not sure that's true. Portable computing can differentiate in many different ways. Consider how broad wearables could be, and that each of these could replace your phone, in principle.


We'll find out when the first vendor inevitably abuses a feature in the interface to specifically make their phone un-upgradable.


> un-upgradable.

I believe you mean "differentiated" :)


Product differentiation is an underestimated evil of our time.


Some would argue it was what killed Nokia, too. It chose to go with Windows Phone to "be different", even though Android and iOS were already established and WP didn't have much of a market share.


It was pretty much what strangled the community efforts surrounding Maemo as well. Core pieces of early Maemo, like power management, was closed source, for "differentiation".


VTS is meant to address that concern.


Companies are incentivized in the long term to make good products. This incentive usually eclipses incentives that our (often justified) anti-corporate suspicions invent.


I'd like to believe that. But profits rule.

Smartphone usage must be pretty close to saturation point, in the developed world at least. Samsung, Apple etc release a new, expensive device every year, and it's natural that they are going to want existing customers to upgrade.

I think the only way Android users (of non-Google devices, that is) are going to get software upgrades is if Google somehow forces vendors to do it.


It might be enough for a single vendor to "break ranks" and go with treble to have a decent effect. Xiaomi did so with their large batteries, for example.


I'm more an Android guy, so I don't have an iPhone (except for testing on mobile apps I'm working on), and so I don't know what the update situation is like. But my (limited!) understanding is that when they release new iOS versions they are available at least a couple of generations back - is that correct? Or if you buy a network locked phone is it up to the network?


Depending on the nature of the update, iPhone updates are generally 3–5 generations back. Just on the iPhone side, iOS 10 has some level of support on the iPhone 7 (current generation); iPhone 6s (-1 year); iPhone 6 (-2 years); iPhone SE (slightly updated iPhone 5s); iPhone 5s and iPhone 5c (-3 years); and iPhone 5 (-4 years). That’s five generations of support for iPhone.

They are a little more aggressive with iPad and iPod touch deprecation, but I think that’s because some of those devices were built underpowered anyway.


iOS updates are pushed directly by Apple. There's also "carrier updates", which I believe are also pushed by Apple, that update network settings and enables certain features when the carrier support them (VoLTE, Wifi-Calling, etc).


> Companies are incentivized in the long term to make good products

i don't think this is necessarily true.


Agreed. Seems to me they are incentiviced to offer the minimally viable product at the highest markup they can get away with. Then it is up to competitive forces to convince them otherwise.


Judging by the sheer number of devices running outdated Android versions and the consumer unfriendly tactics such as locked bootloaders, carrier-locked modems, bloatware, and sometimes even tracking software (fair to call this spyware?) employed by carriers and manufacturers I'd say that incentive to produce good products rarely eclipses these supposedly "invented" negative incentives.

That said, Treble looks like a good step in the right direction. Maybe things will improve in the future.


> Do vendors actually want to let users update the software on their devices though?

Apple does because they can still generate revenue off old devices via AppStore sales and services. Also used / hand-me-down iPhones expand their user base by serving the low-end of the market.

Android OEM's on the other hand get basically nothing from Google and don't want desirable used / hand-me-down devices devaluing their own low-end models. They can't even try to negotiate a more sustainable arrangement with Google because there's no viable alternatives to Android.


If we look back through history, we'll see Compaq computers with awful software pre-installed... even bundles including ISP software (AOL, Juno, anyone?) But then we started to see Signature edition computers without bloatware (and Microsoft moving to make it easier to remove the extra software.)

We can only hope that phones follow this trajectory. And maybe more quickly, as they can learn from the past.

Sure, computer manufacturers liked new versions of Windows pushing computer purchases, but now we're at a point where Windows 10 exists, and updates are something not even the consumer can block.


A "Signature Edition" of Android would be interesting.


They did that for a while with Google Play Editions...


Indeed. And supposedly, the Android Silver program was going to continue this [1], but failed.

[1] http://www.androidcentral.com/android-silver


Didn't last very long, unfortunately. I think it's because the average consumer doesn't even know what Android is and a lot of folks buy their phone at their carrier's store.

In other words, there wasn't enough people that cared about this stuff to be viable.


Isn't that Nexus/Pixel?


What I meant was phones from LG, HTC, Samsung shipping with Android without customization and updated directly by Google. Also, the possibility to install this "Pure Edition" if your phone didn't shipped with it would be great, like MS does with their Windows 10 ISO tool.


They definitely want to be able to do so in a fast, cheap way. Another thing is whether they will actually be fair with the updates, but I'm sure that Project Treble will reduce Android's fragmentation.


customers would be more inclined to buy from a vendor that does use Treble


Would they? Or would 99% of them not know about this kind of stuff until it was too late?

A huge percent of people with Android phones think they're Google phones (not Motorola or Huawei or Acer or whatever), so if they decide to avoid their old 'brand' wouldn't they try to avoid Android?

Of course if they know they have a Samsung they can avoid that, but...

This is what, the third or fourth try at fixing this problem? It needs fixing, but I'm rather skeptical at this point. Just because the hardware interface doesn't need to be re-created doesn't mean the vendors will ship updates. It will just be waiting on something else like vendor/carrier software customization that they're not going to bother with because they'd rather work on the new model.

Good luck Google. This would be a great thing for everyone. I just don't hold much hope.


By this logic, shouldn't the Nexus/Pixel phones be a lot more popular than they are?


End customers don't even know that Nexus/Pixel phones exist (because you mostly cannot buy them everywhere) and they don't know the benefit from such devices and they also don't care deeply enough.


I agree that the Nexus phones are advertised poorly, but the Pixels have a lot of advertising in the carrier's stores here in Canada.

The Rogers where I got my last phone, for example, had a dedicated display in the middle of the store for the Pixel phones.


And Google can't keep up with demand for Pixels: http://www.androidpolice.com/2017/03/14/nearly-5-months-goog...


There's also the issue that the Nexus line were perfect budget phones, while the Pixels are high-end. So even with much better advertising, cost becomes the Pixels barrier to entry.


Totally agree with this. Nexus was good performance for an affordable price. Pixel is so much more expensive that Nexus owners are likely to balk at the price tag.


The way people buy phones is a lot more complicated. Most people pick a carrier first, and then the phone; and most people buy their phone from their carrier store (or a carrier booth at a place like Costco). Thus the consumer choices are controlled by the carrier. If a carrier doesn't want to sell a Pixel phone, then few will be sold, regardless of what consumers might 'want'.

Apple is obviously an exception to this due to their own advertising and stores.


Not in Europe, generally.

Most countries have more pre-paid users than on contracts, so we get our phones from computer or phone stores instead of carrier stores.


I haven't looked at the numbers, but they're unavailable in a lot of countries, and are kind of expensive since a few generations.


They can't become popular if they're difficult to buy.


exactly


Even Google abandons their products after a couple of releases. Perhaps better supported than other manufacturers but I'm running 7.1.2 on a Nexus 4 only through Lineage OS.


They might be, if people actually knew that they existed...


Maybe we can benefit from this in 2 or 3 years? I'm very pessimistic... it takes LOOOOOOONG before vendors will look into Android O and the interfaces and the first generation benefiting from this will be earliest Android P updates. And do not forget: This whole process does not reduce testing time and the carriers might also look for long testing on updates ;)


It sounds like the vendor abstraction layer will make things a lot simpler for manufacturers and vendors, so the cost savings alone should tempt them.

I'm not sure, but couldn't this benefit vendors/manufacturers/users upgrading to O?

Also, remember that manufacturers have probably known about this for a while.


An improved vendor abstraction layer might make porting easier but it still doesn't provide any incentive for vendors to actually update old devices. :(


If Google actually implements a way of pushing those underlying Android updates directly to the phones then I think they might actually be successful. If Google end up still relying on the manufactures and carriers to push those updates out, then what incentive will they have to keep the phones updated?


If we're lucky - consumer pressure.


An almost nonexistent percentage of users know what version of Android they have or if it's the latest, in the grand scheme of things. In the tech bubble, it's hard to imagine, but I'd go so far as to suggest most Android users don't know they run Android.

If people realized how many security risks they open themselves up to by running old Android versions and that the "your phone is up to date" line in their Settings app is basically a lie, Android would not be the dominant platform on earth.


You are, sadly, entirely right. But we can all do our part in educating users. Friends don't let friends use unpatched software...


By contrast many iOS users do know which version and the media reports on releases.

One could argue that this is the power of releasing to millions of devices concurrently, as opposed to spread out over sometimes years like Android.

Windows Phone had issues but updates was not one of them and you knew which release you were on them too.


I don't think most iPhone users DO know what version they have. But they update pretty fast.

Apple pushes users to update with notifications on the device. They add things people really want (there was an article last year or so that the releases with new Emoji get adopted much faster, iOS stickers caused a big push). Plus you get the network effect of someone telling their friends there is a new version. If none of that works, apps requiring new versions of the OS push some people.

Android manufactures may not make new versions for old phones, may not push the notifications about them, and there are lots more kinds of Android phones so just because Jim got the new version doesn't mean Barb can because she has a different OEM. Plus because so many Android devices ship with old software apps are often designed to run on very old releases so they wouldn't push people to update nearly as much (and that's if they can update, you can't be sure a new version is even available for your customers).

This problem is a LOT harder the way the Android ecosystem is setup.


Of course Windows Phone had update problems. Carriers would hold back or not even release updates. And then there was Microsoft who was osborning their OS's and phones.


The point here is that Windows Mobile has already solved this problem: All Windows 10 devices receive OS updates directly from Microsoft servers, as a requirement of using the platform. (Even in 8.1, if you were on Developer Preview, you got updates straight from Microsoft, apart from carrier/OEM channels.) Drivers/firmware are pushed separately.

This appears to be where Google is perhaps finally heading. Once Treble is out there, Google will change their contract terms to mandate control over OS updates for all devices which license the Play Store.


No Windows mobile has not solved that problem. Any updates involving firmware are still controlled by the carriers. It's a rather moot point as windows phone is dead anyway.

>The new process still does not provide firmware updates, as far as we know, so carriers and their bottlenecks will still be involved in upgrading phones.


> By contrast many iOS users do know which version and the media reports on releases.

Because Apple pours millions of dollars in marketing and advertising. They have to, considering their ever shrinking market share.

Google never advertises anything Android related because they don't need to.


This removes one of the main excuses various vendors use for not providing Android updates. I truly hope this works in helping users always be up to date.


It is my opinion that Google does not view Android as simply "an operating system for phones". Android has tremendous application in IoT devices and appliances. The lifecycle of many applications is quite a bit longer than the cell phone.

As we see an increase in the diversity of applications using Android, this upgrade path will be very important. Just wait until you see your first ATM or POS system "Powered By Android ©".


The only two reasons people put up with android on phones are

1) it's the only choice if you want something small with a cell modem

2) it's the only choice if you want to run Snapchat

Android is incredibly aweful. It's actually impossible to write apps for it that won't crash. If you're writing firmware it's even worse! Have you ever tried to build it? It's a nightmare! The source for a basic system is over 60GB and has a crazy number of dependencies.

For embedded systems/IOT you're thousands of times better off just using buildroot or an RTOS.


Which is why I cannot understand what Google is expecting people will do with Android Things, given the boards it runs on.

A general purpose GNU/Linux distribution, with <place your favourite language here>, is a much saner approach for any developer.

It is even possible to run with Java 9, something that Android (or its Things variant) probably will never support.


Well, is it really much worse than Windows CE?


That's like comparing shooting yourself in the foot to shooting yourself in the head. There's no reason for either!


is this a hypervisor ? I'm kinding of wondering about the abstractions here... is this replacing the bootloader with a kind of bootloader+hypervisor and the actual OS loads on top of the hypervisor ?

Their abstraction with the camera2 and hal3 was a small step in this direction. any camera with these abstractions would be able to use RAW imaging.


Nope, they've introduced a HIDL for defining hardware interfaces. See https://news.ycombinator.com/item?id=13928385 which I posted back in March.


So this will get users on to the next Android Framework version but if there are security bugs in vendor implementation or underlying firmware it'll still continue to be problematic for users. But it will solve the PR problem for Google if OEMs and Carriers update the framework version quick enough - the question raised mostly by tech pundits - when am I going to get the next update to Android - will have a satisfactory answer.

Not to say this isn't a huge step forward from status quo - if vendors contribute features and fixes to MediaServer and everybody uses the same implementation it will be much easier to update it for all vendors.

What still sucks is this is not going to be Google that will update the Android framework - it's still OEMs and the carriers.


This would seem to allow security updates at a faster rate, but the linux kernel will forever be abandoned to hardware vendor whims aka still on 3.10.X


It seems they're making the vendors push their kernel patches into AOSP.

From TFA:

" In addition to the architectural changes, we're working with our silicon and device partners to take their code changes, such as features for a carrier network in a specific country, and move them into the common Android Open Source Project (AOSP) codebase. For example, Sony and Qualcomm contributed dozens of features and hundreds of bugfixes to Android O so they no longer need to rework these patches with each new release of Android. "


So is this a way around mainlining all of the silicon vendor's various kernels? I have heard that each vendor just hacks their hardware into the 3.10.X and then just keeps a repo of it to meet open source requirements. Because they are unable to make the quality requirements to get their code upstream.


By the time anyone can get all the code required to support a modern SoC upstream in Linux, it's already obsolete.


Perhaps it's time for a Halium/libhybris approach. If I understand correctly, Ubuntu Touch and other GNU/Linux platforms would use an upstream kernel (4.x) to boot a device and delegate to an lxc container to pull in only whatever binary-blob hardware support from a 3.10 Android kernel was necessary.


For someone that is considering Android, coming from iOS, this is a brilliant idea that should have been implemented long ago.

For example, a lot of Android phones are running 4.4 and 5.0 in this part of the world. Those versions are pretty bad and the people that bought Android 4.4 and 5.0 actually do not know what they are missing and how to actually update their OS since there is no way for them to do that for now.

I hope that with this Treble, there will be a lot more Android phones(from Chinese makers) that can update base Android OS to the latest one much more frequently.


"...they'll be no [Treble] at all!"

-- Scotty, in The Trouble With Tribbles

What was the previous "vendor integration" initiative? How long did it last? Two years? Or was it one.

Lack of vendor buy-in. Combined with Google's ADHD project support.

Nice idea, but color me skeptical.

I don't see anything that hints at a change in the fundamental cost/benefit that's driving the current mess.

Maybe I'm just projecting cynicism, because I'd actually like to be proven wrong. And bad press seems to be the only external influence on Google, that actually gets through.


Would this help projects like LineageOS (formerly Cyanogenmod) maintain ongoing support for older devices?


If all the vendor crap and secret drivers are abstracted out sufficiently, yes.


The bottom diagram suggests that the 'Android OS framework' could be made device independent, with Lineage OS only responsible for maintaining the 'Original vendor implementation'.

A 'ROM' could then be split into 2 - the core system and the userspace running on top, with potentially the latter maintained by Google's AOSP across all devices.


Hopefully. A lot will depend on the license around the test suite. This held back alt-java for a long time.


I discovered this back in March. This is pretty exciting!

Now all we need is to have Google distribute the framework over the Play Store instead of relying on OTAs, and all will be right with the world.

https://news.ycombinator.com/item?id=13928385


speaking of Android: How about switching to the JVM/OpenJDK to keep pace with modern Java? Maybe deliver CDI as a standard feature?

Also, how about using cgroups instead of the custom security model? Maybe we could get reuse out of Google's security patches for Linux, and they could benefit more from the community.


> speaking of Android: How about switching to the JVM/OpenJDK to keep pace with modern Java?

They did that already. https://arstechnica.com/tech-policy/2016/01/android-n-switch...

Well, they switched the library to OpenJDK. The runtime is still ART, but that's probably for the best as the runtime balance decisions made by hotspot are definitely not suitable for phones, and ART is pretty good these days anyway.

And you can use Java 8 stuff: https://developer.android.com/studio/preview/features/java8-... some of which is even fully backwards compatible (like lambdas)

> Also, how about using cgroups instead of the custom security model? Maybe we could get reuse out of Google's security patches for Linux, and they could benefit more from the community.

Android has always used cgroups. cgroups are not a security mechanism, though, it's for resource allocation.

Regardless Android makes use of cgroups, cpusets, selinux, etc... That's all unrelated to the permission model, though, which more or less doesn't exist on desktop platforms.


Actually the reality is a bit different than those marketing articles.

They started to cherry pick library implementations from OpenJDK, but achieving feature parity is certainly not something they care about.

Anyone can easily check the AOSP commits to see exactly that.

https://android.googlesource.com/platform/libcore/

https://android-review.googlesource.com/#/q/status:open+open...


> but achieving feature parity is certainly not something they care about.

[citation needed]

what is missing?


So many things.

- Swing

- JavaFX

- NIO and NIO2

- invoke dynamic

- method handles

Are a few that come to my mind, but basically besides from what was left out of Java 6 libraries, almost everything that was introduced in Java 7 and 8.


Swing & JavaFX are not part of the JCL. Those are addon libraries.

NIO: https://developer.android.com/reference/java/nio/package-sum... "added in API 1"

As in, it's been there since forever. What are you referring to specifically?

NIO2: https://developer.android.com/reference/java/nio/file/packag...

Invoke dynamic: is a runtime/bytecode thing, not part of the library. The actual feature, lambdas, works just fine on Andorid

Method handles: https://developer.android.com/reference/java/lang/invoke/Met...


I think this will be pretty successful. Ultimately the manufacturers want to do as little software work as possible. If Project Treble gives them easier/less work to do, then they will adopt it quickly.


One potential side benefit of this type of work: vendor kernel drivers tend to be insecure buggy pieces of crap. Vendor Treble drivers will surely still be insecure buggy pieces of crap, but they might be sandboxable. If Google really has its eyes on the Magenta kernel, I imagine that Treble will be runnable in user mode, so I bet it really will be sandboxed. This would be a huge win.


Android finally adapted the approach of Windows on PC - OS maker dictates the software pieces on all devices, the device makers only create the hardware and write drivers (optionally, some bloatware). I believe this is the right/better approach, and it solves no only the Android update hassle, but more importantly the fragmentation issue.


Neat, Google has release this years fix for Android updates. I can't wait to see what next years fix looks like.


I wonder if this will make it easier to circumvent the vendor layer entirely--jailbreak without replacing the OS?


How much of the update problem is due to vendor customized UIs and apps, and how much is due to not upstreaming driver support for their hardware?

Which of these problems will Project Treble solve? Eg, have they actually added a stable driver KBI? Or pushed drivers to userspace? Or is this just about GUIs?


Took them long enough.


You can't fix a business/greed problem with technology.


This is true, but Google may have more leverage than they think. If the phone vendors don't like the direction of Android what are they going to do, switch to Windows/Tizen/webOS/FirefoxOS?


Only it the technology pretends that business/greed somehow does not apply. Google could make selling updates on the Play store an optional part of treble, problem fixed.


You are wrong. Sometimes it is possible, sometimes it is not.


that's cute. It's like Google doesn't get that hardware manufacturers need to sell you hardware... Am I missing something?


I assume you are implying that if the software can be updated, there would be no need for new hardware. Yet, for Apple, the opposite seems to be true :)


Apple is an edge case in so many ways that Android OEMs differ:

* Apple has a greater following of "must have the latest" consumers than most Android OEMs put together

* Apple makes money from the app store. Both selling apps and developers submitting apps that expose cool new features in iOS.

* Apple can release iOS updates that coincide with newer handsets but with software features only exposed in the newer hardware. Which also helps with the adoption of newer hardware.


Apple is smart -- they sell one version of their phone -- all the price differentiation comes from continuing to sell last years model (and the year before that, and so on).

Compare that to Samsung: they have high end phones, mid-range phones, and low-end phones in addition to last year's model.


to be clear I don't agree with this hw manufacturers. Yet they assume what you were implying. And their products are not the same as apple's


Yeah, repeat and new customers buying your products because you support them and having existing customers recommended them to their friends and family.


It's incredible to me how long it took Google to realize this was their fault. A lot of people here have bought the "blame the OEM" nonsense for a really long time, and you can see the comments here reflect that.

But in reality, there's a huge expense to all the work of updating devices to support Google's rapid change cycle for dozens or hundreds of different models, and the problem stems first and foremost from that lack of abstraction layer.

This is likely a first step to finally catching up to Windows Mobile: Making the core OS upgrade come straight from the actual OS developer, so that the company that writes the code is actually the one that updates the code.


Well I can blame OEM because I never asked for special features and skins on top of Android. I want stock Android and stock should be easier to update. Speaking about testing of updates: I'm sure this abstraction layer will not reduce the testing time and it will only slightly reduce the release time of new version.


> I want stock Android and stock should be easier to update.

That's not actually true, unfortunately. The BSPs are where the majority of the work is, and zero percent of that work is different between "Stock Android" and "Weird OEM Customized" Android.

If you look at what it takes to get "Product X" from an existing Android version, to a new Android version, very little of that time is updating the crapware everyone hates, and the vast majority of that time is updating the BSP + drivers needed to get any Android working properly at all.

For instance, if you build a product, you might buy a board from a random OEM, and that board might be built around a Qualcomm SOC on it. If Qualcomm doesn't support "the next android" for that particular chipset, your basically stuck unless you re-invent all of the Qualcomm-specific drivers and tools yourself. Since Qualcomm isn't supporting it, the OEM you bought your board from isn't either, and the product itself gets stuck on old Android.

ocdtrekkie is getting downvoted for this, but he's mostly right. Google could easily solved this problem years ago by letting Android devices reuse existing BSPs, and it looks like they are finally doing exactly that.


> Well I can blame OEM because I never asked for special features and skins on top of Android.

Did you buy an Android phone? Then it wasn't enough pressure.

There simply aren't enough people in the market who care about this to put much pressure on phone companies. Basically EVERYONE has a phone, and since almost none of them know about this issue they'll always make the purchases of people who do care a rounding error on the books.

Just like the 'I need a removable battery' or 'I want a hardware keyboard' people. They're real groups, but they have little sway in the market compared to the people who are indifferent (or at least willing to accept the trade-off grudgingly) so they don't get much traction.


There's no such thing as "stock Android" from an update distribution view. Each Android release, currently, has to be custom-fitted to each given hardware model. That is the problem being solved here, and it's not the OEM's fault, it's the architectural design of Android itself, which is changing.


It's not just Android design's fault though. ARM does not have the equivalent of Bios for hardware discovery and initialization. So you can't have a generic OS image to be installed on any device.


> This is likely a first step to finally catching up to Windows Mobile:

Do you remember the same Windows Mobile that I do? In version 5 or 6 they had a "Windows Update" control panel which I basically never saw work, and that wasn't for lack of builds coming out of Redmond. In that time I had to illegitimately re-flash to get any updates.

Or perhaps you mean Windows Phone where zero devices got upgraded from 6.x to 7, zero devices got upgraded to 8, and a bunch of phones never got 10. And late in that game there was effectively one hardware vendor plus some rounding error.


Windows Mobile was technically capable of all this; custom versions of Windows mobile back-ported to older phones were far more prevalent than custom versions of Android are now despite Android being open source and based on Linux.

This should be a cautionary tale for those thinking that this technical initiative will have huge benefits for consumers -- it didn't work out well for Windows Mobile users because the manufacturers and carriers are still the gatekeepers. Just because they can more easily produce new versions doesn't mean they will.


It's also incredible that you still don't comprehend that Google cannot update an OS created by another OEM. When you allow an OEM to create their own OS only they can update it. Your Windows comparison is also flawed because OEM's do not build the OS - they're given the binaries from Microsoft and cannot change them.


Of course you can, you just need to add required updates to the endless list of legal clauses required to access Goggle Play Services.


How does your required updates idea work with the carriers? Are you going to add a legal clause for them too?


The courts are quite good sorting out those issues.


Are they? And what about courts in other countries? Are they also good at sorting out those issues?


Other companies seem to be able to handle international law.


This is, as with every time you've posted it, a complete fiction. Android doesn't become "not Google's OS" because of the shoddy distribution method in use, and Google still does dictate to OEMs what does and doesn't qualify for release, as Google still has effectively complete control of the ecosystem via the MADA/Play Store license.


Your reply doesn't make sense and you have not answered how it's technically possible for Google to update an OS created by another OEM. Google does not have the source code for the OEM's changes so to expect Google to update their OS would be impossible. It's like asking Debian to update Ubuntu.


The solution is for there to be no OEM changes, just like Windows.


So the solution is for Android to be closed source? I'm not sure I agree with that.


Android, as distributed, isn't really "open source" in the way you seem to be defining it already: It contains proprietary packages which contain spyware, and OEMs are beholden to Google's requirements with regards to what they can and can't do with the platform. And it is possible for something to be open source (i.e., the source code is public), and still only permitted in an unchanged fashion.

As it is today, Google requires Android devices pass the CTS, or Compatibility Test Suite, in order to be eligible to have their proprietary apps, like the Google Play Store, on the device. In the future this will likely simply be another requirement to pass, that Google can push their own updates to the OS layer.

The reality is, the idea that someone like Google can write code, and then be unable to push security fixes to it, is patently insane. In 2017, this is completely unacceptable. The idea that an OEM or carrier should be responsible for, or able to interfere with security updates to the OS developer's code is simply not okay.

I am a big fan of open source software and customization, but the current situation, where 0.5% of Android devices run the latest version of the OS, is completely unacceptable, and any compromise or cost required to fix that is justified.

There's a reasonable chance Android will lose some OEMs over the change, and that is fine. Google needs to focus on security over profit here, and accept that they might lose a little market share to do the right thing and protect their customers' safety.


This is all true, and it's weird that you are getting downvoted for saying it.


No, what he has said is not true, starting for the farcical claim about spyware and ending with the little fact that the OP was talking about Android and ocdtrekkie mixed the proprietary Google apps


> No, what he has said is not true, starting for the farcical claim about spyware

Uhm, have you heard of SafetyNet? Even if you ignore the stuff Google is doing, we know for a fact that all cellphone basebands contain code to turn them into listening devices and have universal backdoors.

Ever since Snowden blew the lid on this stuff you can't claim that any of this is "farcical".


Safetynet is not spyware

> Even if you ignore the stuff Google is doing, we know for a fact that all cellphone basebands contain code to turn them into listening devices and have universal backdoors.

What has to do that with the OP claim that Google puts spyware?


> Safetynet is not spyware

All of Google Play Services qualifies as spyware, but SafetyNet is the most obvious example. It literally does "diagnostics" on your phone and uploads them to Google so they can track information about your phone. Under what definition of the term "spyware" are you operating. I mean, they constantly upload your current location with the greatest accuracy we have ever invented for GPS for pete's sake.

Just because your vendor installed it for you in the first place doesn't stop it from being spyware. And just because Google are portrayed as the "good guys" doesn't mean they're immune from doing incredibly scummy bullshit.


Google Play Services meets all the definitions of spyware. It's built to collect data on your usage and track your location and report it to a third party for their own interests. It's nearly impossible to fully remove, and it has replaced critical parts of core applications so you can't remove it without crippling your own ability to use the device.

I get that you're a fan, but it's impossible to define it any other way.

And as always, remember that any data Google can collect, the government can collect through them. They have no legal ability to resist those requests. So, your precise location history at all times? Yeah, that's an open book.


I agree.


Seems like Google is trying not to lose Samsung: https://9to5google.com/2016/06/13/report-claims-that-samsung...



That article is nonsense.

Google is doing what they can to clean up the code base and separate concerns. Clearly many vendors have a technical problem merging their own changes with updated versions, and we've seen time and time again that vendors make promises -- they have the will -- that they don't live up to because they don't have the means.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: