Treble: A modular base for Android
android-developers.googleblog.com
android-developers.googleblog.com
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
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.
When you put it that way, it seems like it's gotten a lot better.
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 i have to agree, for low end devices, even from famous companies i dont think they will update their phone even with this.
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.
Treble removes much of the cause for forking, and removes the cost for OEMs that follow it's design.
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.
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.
Unless the browsers offer APIs at the same feature level as native OS APIs, web applications will always be a second class experience.
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.
On the Porters five forces scheme of things, the SoC vendors have much better bargaing power than device makers.
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.
The majority of my devices don't have Qualcomm.
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).
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.
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>.
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).
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.
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.
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.
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.
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
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).
But yes. One issue anywhere, and I can upgrade everything again.
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.
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.
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.
Or worse, coming with obsolete kernel right at the release day.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No thank you. I use Android because it's a free and open system.
Look closer - its a fetching combo of fanny pack, boxer shorts, ice skates, ski goggles etc. pretty much the crap you wanted.
Upvoted the grandparent, just to keep it high in the list so that your comment would stay near the top of the page...
I would have thought new shiny software was a nice incentive to get customers to upgrade to a new phone?
The Rogers where I got my last phone, for example, had a dedicated display in the middle of the store for the Pixel phones.
Apple is obviously an exception to this due to their own advertising and stores.
Most countries have more pre-paid users than on contracts, so we get our phones from computer or phone stores instead of carrier stores.
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.
That said, Treble looks like a good step in the right direction. Maybe things will improve in the future.
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.
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.
i don't think this is necessarily true.
I believe you mean "differentiated" :)
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"
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.
At this point I'm not so sure what's better: an updated OS or one full of known exploits.
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.
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
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.
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.
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).
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 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.
In other words, there wasn't enough people that cared about this stuff to be viable.
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.
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.
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.
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.
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.
>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.
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.
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.
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 ©".
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.
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.
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.
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.
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. "
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.
-- 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.
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.
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.
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.
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.
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...
[citation needed]
what is missing?
- 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.
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...
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?
* 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.
Compare that to Samsung: they have high end phones, mid-range phones, and low-end phones in addition to last year's model.
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.
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.
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.
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.
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".
> 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?
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.
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.
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.
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.
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.