Linked by Thom Holwerda on Sat 13th May 2017 15:36 UTC

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.

Permalink for comment 644219
To read all comments associated with this story, please click here.
Member since:

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.

Reply Parent Score: 2