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.<p>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.<p>[0] <a href="https://support.google.com/pixelphone/answer/4457705?hl=en" rel="nofollow">https://support.google.com/pixelphone/answer/4457705?hl=en</a>
"device makers can choose to deliver a new Android Update"
... "can choose".<p>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.
This should usher in a new era of cheap phones that upgrade immediately to the newest version of the Android OS.<p>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.<p>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.<p>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.<p>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.<p>Brilliant move Google.
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.
Do vendors actually <i>want</i> to let users update the software on their devices though?<p>I would have thought new shiny software was a nice incentive to get customers to upgrade to a new phone?
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 ;)
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?
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.
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 ?<p>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.
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.<p>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.<p>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
For someone that is considering Android, coming from iOS, this is a brilliant idea that should have been implemented long ago.<p>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.<p>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!"<p>-- Scotty, in <i>The Trouble With Tribbles</i><p>What was the previous "vendor integration" initiative? How long did it last? Two years? Or was it one.<p>Lack of vendor buy-in. Combined with Google's ADHD project support.<p>Nice idea, but color me skeptical.<p>I don't see anything that hints at a change in the fundamental cost/benefit that's driving the current mess.<p>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.
I discovered this back in March. This is pretty exciting!<p>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.<p><a href="https://news.ycombinator.com/item?id=13928385" rel="nofollow">https://news.ycombinator.com/item?id=13928385</a>
speaking of Android: How about switching to the JVM/OpenJDK to keep pace with modern Java? Maybe deliver CDI as a standard feature?<p>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.
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.
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?<p>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?
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.<p>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.<p>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.
Seems like Google is trying not to lose Samsung: <a href="https://9to5google.com/2016/06/13/report-claims-that-samsung-is-considering-moving-all-of-its-devices-to-tizen/" rel="nofollow">https://9to5google.com/2016/06/13/report-claims-that-samsung...</a>