How Google's Project Treble will help fix one of Android's oldest problems

In March 2016, when the Android N developer preview was released, we noticed something was different. With Android Marshmallow, Google had inserted a new partitioning structure that included a vendor partition. This held some files that had previously lived in the "regular" core OS folders in the system partition, as well as some files from the company who made the phone itself. But in the Android N developer preview, things changed even more and there were also files in this new partition that duplicated and overwrote pieces of the core OS when the phone was booted up.

At the time, we put our heads together and did some extra digging and came to the conclusion that this was the first step towards making Android easy to update by giving companies like Samsung or Qualcomm a place to call their own and splitting the system into two parts: a vendor area and an Android core area.

Project Treble splits Android into two parts: The Google part and the hardware support part.

Google announced Project Treble today, and everything has come full circle. This is exactly what that vendor area is for, and we get to see just how it can change the problem of phones not being updated fast enough.

The Vendor Interface and VTS (Vendor Test Suite) are coming with Android O, and it looks like this will take away any excuses for being slow with the updates. It's a fairly technical thing to describe, and if you're technically inclined, you should have a look at Google's blog post on it all, but we can break it down so that everyone can understand what this is and why it can make a big difference.

We all know Android comes from Google. Plenty of other companies work with Google to make Android better (and Google has invited companies to do even more of this), but the code is finalized and hosted by Google. Anyone can download it and build it into Android, but this Android on its own is not a complete phone operating system.

To get Android to do anything, you need support from companies like Qualcomm, Samsung, and every other company who makes the individual parts. The software that makes those parts work is separate, and the way things are before Project Treble mean that those parts need to be built into Android's code when the companies making a phone build the operating system. Each time Android is updated, whether it be a full platform update, like the jump from Marshmallow to Nougat or a security update that only affects a few parts of the system, the parts that make the hardware work need to be incorporated.

Android itself is not a complete operating system. You need support from hardware vendors to do anything.

That slows things down considerably. Instead of Google being able to send a single update for every phone running Android to the companies that make them and have it work, they send a non-complete operating system that needs the rest built into the new base, then it needs to be compiled and tested. Samsung (for example) needs to do this for every model of the Galaxy S8 they make before they can even think about sending that update to you.

With the new system, Google's portion of Android can live in its own space and the parts from Qualcomm and Samsung and HTC and everyone else can live in their own space. In theory, the update is already tested and will "just work."

That's what the new VTS is for. Think of the VTS as the rulebook about how to make Android. If everyone follows these rules, the changes Google makes and tests will work exactly the same on every phone running a particular version of Android. And with updates easier to build and send to us users, most new phones will all be on the same version. This is great for us, and it's great for the companies involved because it lets them work on their area of expertise while someone else works on their stuff.

The Vendor Test Suite is designed to make sure every company builds Android the same way.

To check that the rules work and everyone is following them, a series of tests can be done on a new device before it goes up for sale and each time the system is overhauled. These test will make sure that Samsung's TouchWiz Android and HTC's Sense Android both work with Google's Android the same way and a single update from Google works on both. This is how things are done to make sure all the apps in Google Play will work, and, for the most part, it's a great system.

We don't have the full details yet, but we're told that everything will be published and pushed to the open source code for Android once Android O launches later this year. This will make for a very interesting time at Google I/O, and we'll continue to check out this new way of doing things and what everyone else involved in making the phones we love is doing with them.

Jerry Hildenbrand
Senior Editor — Google Ecosystem

Jerry is an amateur woodworker and struggling shade tree mechanic. There's nothing he can't take apart, but many things he can't reassemble. You'll find him writing and speaking his loud opinion on Android Central and occasionally on Twitter.

  • Isn't this the original concept of Android?
  • I get it now! Android "O".
  • "Android zero" sounds great
  • I have two questions:
    1) Will any device updated to Android O support Treble or will it only be for devices shipping with it?
    2) Will this actually change anything? It seems like our OEM overlords still need to approve and push the update. That's the key problem.
  • Regarding your first question, to me it sounds like any phone on Android O regardless if it's updated to it or shipped with it.
  • I think, devices shipping with android lower than O will probably not get this feature as it requires separate partition scheme.
  • Yes, but hasn't this partition scheme been around since Android M?
  • Taken from the developer blog "Project Treble will be coming to all new devices launched with Android O and beyond".
  • Reading the second question, yes and no. Yes the phone was purchased from the OEM/carrier and it's their responsibility to push it to users, but no, the amount of work OEM/carrier have to put into making this happen with Android O dropped to something as simple as 'git rebase' and execute the VTS (tests) to make sure everything went fine.
  • This sounds very promising. I have a Galaxy S7E running N and with the April security patch. I am really hoping to buy an unlocked (carrier crapware free) Note 8 at the end of the year. How nice would it be to have Treble up and running in O(reo?) and then get it onto an unlocked Note 8. Android dreams...
  • Sounds great in theory, but I'll reserve judgement until I see some results. If it were that easy, wouldn't they have done this a long time ago? You'll still have to deal with slow OEMs and slow carriers.
  • Google should be able to update this partition directly, as they do with Play Services now.
  • So all skins and carrier bloatware will never need updating for new Android versions? Seems doubtful.
  • That is simply impossible. How would google access a device made by Asus to make such root level changes? And even somehow it was possible, what's the guarantee that it won't break some functionality on the phone?
  • No one said it was easy!
  • [sarcasm]Verizon will still find a way to disable it on phones they sell. [/sarcasm]
  • No need for the [sarcasm] tags. And it won't just be VZW.  
  • True but if that's the case, best then to lock them out of it in the first place. Make it so the update doesn't need oem or carrier blessing before going out. Now will this work? That's to be seen.
  • Ye I live in the UK and from what I see your networks are complete dicks writing there names on every phone and disabling features I feel sorry for you no offence
  • Now I'm wondering if that means the possibility of running an Android OS mostly free of customization of the user wants it (ie: No TouchWiz, etc).
  • This system won't necessarily give users the ability to remove a customized UI. We're talking about the underpinnings of Android being updated independently, not Google shipping a complete "stock" UI underneath whatever the phone maker is including.
  • Great idea but I am sure like everything else the carriers will screw it up.
  • So true. Google really needs to punt the carriers out of the update process entirely.
  • No!
    Leaving the carriers in the update process is how Google will shame them into quickly updating.
    If everybody has the same underlying code the OEMs will have it ready for their devices quicker.
    Next comes the carrier bloat. So in the end it's each individual carrier being the holdout, and not Google or the OEMs Example.... Google makes Android ready and give to Samsung. Samsung makes update for all GS8s and gives to carriers at once. Each carrier proves who is the slowest sending the updates to their version of the GS8. This is when we learn which carrier cares about our security.
  • Which seems pointless
    Let's say Verizon is the slowest
    Google shames them
    Then nothing changes
    Completely removing the carriers would be the best idea
  • Sorry, I misspoke.
    In simplier terms Google lays down the foundation. OEMs defines the various states of devices it's to be introduced to. Then carriers (Verizon) introduce it to the stated devices. This shaming comes into play when the period of time between being OEM introduction and carrier distribution is observed.
    There in, the slowest carrier shames themselves with their own customer​ base. This is how you get users to know that Google's Android doesn't have a fragmentation problem. The customizers and carrier device sellers do.
  • It can sound simple to just switch to a carrier that pushes updates in a timely manner but it never is that simple for a few reasons (network coverage being the main one). That means nothing will change and removing the carriers' input entirely is still the best option.
  • Microsoft manages this with win 10 mobile so for sure Google should be able to pull it off too you would think.
  • This doesn't sound anything promising as the update(s) still requires the OEM's approval and not coming directly from Google.
  • Finally, now show me some phones with O
  • Totally pessimistic on this. VZ will mess it up somehow.
  • I will believe it when I see it. The road is littered with broken promises.
  • Hahahahahaha! Too many cooks in the kitchen for this to work out. I'd put good money on carriers ruining this.
  • Indeed. This reads like so many other good ideas by Google that never actually amount to anything.
  • Because this still leaves much in the hands the OEMs and Carriers with emphasis on Carriers. it would seem the best practice would be for the OEMs to put the devices in a 'Carrier Neutral" state. This is give the phone all of the LTE/GSM/CDMA radios and frequencies needed to literally be placed on ANY network just by the insertion of the SIM for that carrier. The SIM could activate radios and frequencies that are specific to the SIM operator, then point to a ROM partition specifically for a carrier that chooses to um, offer a unique customer experience. Absent data in that partition the phone acts like an unlocked carrier neutral device. The SIM only gives carriers access to the partition their SIM points to and a user can clear that partition similar to clearing system cache. The OEM could then deliver their update independent of the carrier. If there's an aspect of the new OS update that clashes with the carrier's software, the customer would have the option to clear the carrier cache making the phone a 'Bring Your Own Device' phone somewhat like bringing a Pixel you didn't buy from Verizon to Verizon's network OR say screw the carrier and insert a different operator's SIM card. This would be a win on multiple levels and finally tilt the playing field in the customer's favor. It would be a win for the OEM as they could simplify their product line. This would also create transparency as far as who's dragging their feet on updates allowing customers to vote with their feet ...or wallets.
  • Great idea but I am sure like everything else the carriers will screw it up.