It’s that time of the year again: Google unveiling some initiative or whatever with the aim of improving the horrible Android update mess. None of them really panned out, but I begrudgingly have to admit that the project they just unveiled – Project Treble – has some more meat to it than the vague promises and alliances they usually peddle.
The basic gist here is that Google is splitting Android in twain, so they end up with the Android OS Framework and the vendor implementation. The latter – the part that’s the reason why so many Android phones don’t get updated – can remain the same across operating system updates.
Today, with no formal vendor interface, a lot of code across Android needs to be updated when a device moves to a newer version of Android.
With a stable vendor interface providing access to the hardware-specific parts of Android, device makers can choose to deliver a new Android release to consumers by just updating the Android OS framework without any additional work required from the silicon manufacturers.
This seems like a good idea, but sadly, it won’t be backported to older Android versions. Treble will be part of Android O later this year (it’s already available in Pixel developer previews), but existing phones won’t benefit from it at all. In other words, it’ll be a few years before the full effect of this project can be measured.
As a sidenote – and you guys will have to help me out on this one, since I’m not knowledgeable enough to determine this – could this mean it’ll be easier to replace the Linux-based vendor implementation with something else in the future? If so, that might be something Google is potentially perhaps maybe possibly interested in.
Google blog post is scarce on implementation details.
Specifically it do not state weather kernel is below or above VTS (both are possibilities).
So for now we do not know weather it would be possible to swap whole Linux kernel for something else. It will be easier though, as VTS will add robust layer of compatibility.
Would like to think of it as HAL, among other possibilities, from there Up. Vendors coders to comply with.
First, I agree that Tremble only starts with Android O, and for effect we will have to wait for Android O+1
However it’s still good news. Device oems do not need to wait for drivers vendors to finish their new drivers, to release their new versions of Android.
Custom ROMs scene will not have to wait for never-to-happen release of some binary-blob-only drivers for new Android, before they can claim stable release of new version of ROM.
Smaller OEMs may decide that cost of update is finally acceptable for them.
Google can use VTS as a stick to force higher quality of drivers (or else no VTS certification, and hopefully bad PR in industry press).
Quality of drivers is I think biggest news here. Fragmentation may or may not decrease. But quality of drivers will go up.
PS Fun fact, in order to enforce workable OpenGL ES 3 drivers Google engineers had to revert to using as much of that API as possible in Android itself. Otherwise handsets would ship with “claims of support” but with totally unworkable implementations. Situation is that f***** **
Edited 2017-05-13 16:02 UTC
Agreed, this is a complete sop to chipmakers. Google could just as easily have mandated 100% mainlined drivers, unlocked bootloaders, and use of Device Tree for Android certification, and accomplished the same thing without fucking over everyone else.
The unfortunate fact is 100% mainlined drivers currently not always possible due to patents with license causes of don’t release source to anyone. Yes those drivers normally contain wrappers and binary blobs and are quite problem causing.
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.
Treble also contains this as notice so its not just hey you can write any binary driver you like.
Personally I see Fuchsia as a stick that Google is threatening hardware vendors with. Being you don’t merge stuff or use uniformed interface we will be forced to go microkernel where you will have no choice.
This would not be the first uniformed driver interface under Linux. People forget vesa video drivers under Linux. Also forget https://en.wikipedia.org/wiki/Uniform_Driver_Interface
Please note UDI died due to lack of vendor support and vendor complaints about lack of performance.
UDI support was mainline in the Linux kernel at particular points in history and was removed because nothing was using it.
This is why I get annoyed when people say Linux kernel need to provide a binary ABI for drivers. Linux kernel has and no one used it.
Maybe google has enough force to land a binary ABI for parts that cannot be legally open sourced by vendor. Remember some of those things can be like radio configuration for different countries and patented code sections by third parties.
Of course those using the binary ABI are going to have to live with the unavoidable overhead. Vendor interface has to be a wrapper and wrapper code always comes at a performance cost.
UDI did not have a stick to threaten hardware vendors with.
Yes the bluez and other items pulled from Android show how much hardware vendors go for NIH syndrome.
Now making Android being able to update on a common driver base will not make hardware vendors happy because they depend on people having to replace hardware to get the newest OS.
Google is in for a hell of a battle to get Treble past hardware vendors. Treble merging mainline linux should be possible with UDI history. Doing Treble will be lot less of a battle than doing Fuchsia.
Attempting Treble of without the Fuchsia threat would be another UDI of doomed.
This has been the problem with those thinking of Fuchsia as a Android replacement. Fuchsia is need good enough to demo it possibility as effective threat.
The stuff below the VTS interface will likely include the kernel, OMX video encode/decode, OpenGL ES. This is not a hard line to draw in Android.
BT is messed up because Broadcom is externally supplying the stack. BT needs to be part of the Android core. Of course Bluez was there until Broadcom demanded its removal because it was GPL.
Getting rid of the GPL in Android will only strengthen the monopoly hold of chip vendors like Broadcom and Qualcomm. Do we really want to make each vendor of a BT chip provide a different, complete BT stack? Of course these monopoly oriented vendors don’t want to participate in sharing.
If this helps with the embarrassing situation of Nexus phones not receiving upgrades after a mere three years, it is good.
People with OEM-customised phones knew what they were getting, but I find it annoying Nexus phones stop receiving upgrades after such a relatively short amount of time.
Well the good news is that the Nexus update problem is going away. The bad news, is that its because Nexus is going away.
Engineering wise. Congratulations to Android Teams 🙂
If your phone maker did update the old versions device specific code to treble, then that would make them able to deliver O. So if they were going to go to the effort of doing this for your phone they’d probably just push out an O version anyway.
The interesting point is just because hardware vendor makes a new soc chip does not mean they use all new parts inside.
There have been a interesting set of power management modules entering mainline Linux kernel recently. So this plan of google has more legs than you think.
Lot of SOC chip reasons in phones/tablets for not working at least what with mainstream Linux kernel is lack of support for the power management system that charges the battery. Vendors don’t make a new copy of this silicon design with each new soc chip.
If google plan works this will have a lot of interesting effects.
Oh I am not rubbishing the plan. It’s cool and exactly what is needed. I just don’t see the point in backporting it to previous android versions. If a phone maker, like Samsung, is going to make a device of theirs work with Treble then why would they ship the Android M or N userspace ontop of it when they can just ship O, which is the entire point of the move to this architecture.
Backporting the interface could be for like the recent broadcom wifi universal hack. The issue is in the soc chip is not always one hardware vendors intellectual property.
So devices that shipped with Android M or N or what ever if the mainline kernel for those has the feature added.
Treble support in the older android kernels could allow carriers and device builders to go-to soc chip IP providers directly for drivers in case of security issue.
The path in the google diagram of progress misses a bit.
Under silicon manufactures there should be IP providers these provide the designs to the blocks in a SOC a silicon manufacture uses. Some of these IP providers work with upstream Linux kernel and some don’t. Basically treble could open up that broad support package has multi-able direct sources of parts instead of coming by one middle man.
Some of the IP blocks from phones SOC chips from 10 years ago are still in brand new made SOC chips not all this has been mainlined.
Do also remember a old SOC chip may not have all it old parts supported by the treble and what is mainline. But if treble backported allows it to be more updated that it is today its a good thing. Also backporting treble take workload off those who decide to support treble making it more cost effective to support it.
Basically backporting treble to older versions of mainline android would be:
1) Offering a carrot to those who do maintain older hardware and reducing workload for them when supporting older devices that don’t support current android.
2) Give device makers more options to source drivers for older hardware they have decide to maintain.
3) At times allow vendor to jump over carries maker to SOC or IP vendor directly to update a binary driver on a older device instead of being stuff with a wrapper that don’t work.
Do remember device makers do go out of business and carriers in some countries are left holding the bag attempting to maintain those devices. Being able to go straight to the IP vendor or SOC chip maker in those cases can be important.
If google does not backport treble I see it as a mistake and weaken the odds of treble success. You want carriers and device makers demanding treble as a feature out of SOC and IP vendors.
Dost we talketh in thee olde Englishe tongue from hence forth?