I would have thought new shiny software was a nice incentive to get customers to upgrade to a new phone?
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.
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.
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.
i don't think this is necessarily true.
That said, Treble looks like a good step in the right direction. Maybe things will improve in the future.
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.
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 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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
When you put it that way, it seems like it's gotten a lot better.
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).
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>.
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.
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.
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.
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.
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.
* 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.
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...
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.
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.
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.
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.
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. "
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...
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.
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.
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.
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.
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?
