Android Project Treble – Yellow brick road

Reply to this post

RFM AvatarSmall






Yellow brick road that leads to a fully proprietary Android OS.

  • The launch of Project Treble sees Google finally moving to address the Android updating problem but it also quietly paves the way for Google to take full control of the Android software.
  • It could also cost the handset makers more of the precious little differentiation they have left.
  • I have long believed that the inability to update Android OS is one of the biggest problems that Google faces with its ecosystem on Android (see here).
  • This has meant that whenever Google makes an innovation that requires any changes to be made to the OS, it takes around 4 years to arrive on the majority of Google ecosystem Android devices.
  • In contrast iOS takes a matter of weeks to update almost everybody.
  • For example, as of today, despite being available for over 6 months, less than 7% of all Google ecosystem Android devices are running the latest version (7.0 Nougat).
  • This is because Google has no control over the updating process for all of its devices (except Pixel and Nexis) and must rely on handset makers and operators to do it.
  • The problem here is that handset makers have little incentive to make their devices updatable and most of the time are quite content just to sell a new handset instead.
  • Project Treble aims to fix this by abstracting the hardware vendor’s modifications from the underlying OS such that the OS can be updated independently.
  • The way it works today is that Google passes the code to semiconductor companies who modify the code to ensure it works with their chips and release it to the handset makers in the form of a board support package (BSP).
  • The handset makers take the BSP and then modify it to meet their own requirements such as functionality or new hardware.
  • It is at this point that their modifications must pass the compatibility test suite (CTS) in order to able to deploy Google’s App store: Google Play.
  • Problems begin when Google updates Android OS as the manufacturer has to ensure that all of the modifications it has made will work before distributing the new Android code to its devices in the hands of users.
  • This process can be so arduous that many handset makers simply do not have the resources or the incentive to redo their modifications meaning that the update stays on the shelf.
  • Project Treble aims to fix this by adding in an abstraction layer between the Android OS and the vendor modifications such that the underlying Android OS can be updated without the manufacturer losing compatibility.
  • This is being referred to at the Vendor Test Suite (VTS) and while it looks like a great idea, it will have a number of problems.
    • First, differentiation: Most Android handset makers differentiate themselves through hardware innovation.
    • For example, Samsung’s iris scanner and HTC’s edge sensors on the U11.
    • This sort of differentiation may require the handset maker to put changes into the Android OS that go beyond the VTS interface that Google has defined.
    • Modifications beyond the interface obviate the whole point of the VTS and so Google updates would be back to square 1.
    • Second, control: The VTS will be like the computability test suite (CTS) which is a series of tests that the software must pass in order to ensure that apps from Google Play will run properly.
    • Modifications made beyond the interface are likely to result in a failure to pass the VTS test.
    • Hence, in effect, the VTS is another level of control as I suspect that handset makers that don’t pass the VTS will not be able to use Google Play or Google services.
  • Hence, the VTS could further limit the small amount of differentiation that the handset makers have left, further increasing their commoditisation.
  • However, for Google its all good as handset makers will no longer have any excuse not to update the Android OS, thereby ensuring that Google’s innovations in the OS come to market much more quickly.
  • However, this does nothing to address the fact that a large number of handsets are not updateable which has been discussed here.
  • This also paves the way for Google to:
    • First: take control of updating the Android OS separately from any modifications that the handset makers have made.
    • Second: move the remaining parts of Android OS out of open source and into Google Mobile Services (GMS).
  • It has long been my opinion (see here) that this is what Google must do to fix the inherent problems of fragmentation and software updating that continue to plague the platform to this day.
  • An easier to use and more consistent platform would most likely increase traffic generation and therefore Google’s revenues which on Android remain half of that generated on iOS.
  • I continue to think that Alphabet remains fair value and I would continue to steer clear of the handset makers whose differentiation looks like it may take yet another hit.


4 thoughts on “Android Project Treble – Yellow brick road

  1. Project Treble does not lead to a proprietary Android. It does lead to solving the update problem. No one at Google wishes to make Android proprietary, at all.

    Other errata: The word you’re looking for was “Nexus” and not “Nexis”.

    There are a few things you don’t seem to understand about how device updates work, and why there’s been such a roadblock to get updated devices into consumers’ hands. It isn’t falling apart for lack of motivation on the handset manufacturer’s part – even when Lenovo wanted to keep the Moto E updated, and promised that they would, they ended up breaking their promise and not shipping updates to US consumers. They did manage to ship updates for the same device to non-US worldwide consumers. How does this happen?

    When you’re a handset manufacturer, you not only have to take BSP and recompile it for your handset, you have to get it through several approvals. Here’s the steps: CTS, which you know, is about delivering what was originally called the “with Google Experience” but we know as Play today. It doesn’t end there.

    If you ship a phone in the US market, you have to get it qualified initially at the FCC, and then separately at a lab that partners with the carrier you wish to sell the phone through. This has a testing cost, and it’s not inexpensive. When you want to ship an update to the phone over the air, because it’s changing in a material way, it has to be re-qualified. The carriers are deathly afraid of putting a handset on their network that will harm their network in some way. Apple gets around this by releasing the betas to developers at the same time. You get to do this re-qualification testing for each handset you wish to update, and each carrier you wish to sell through. It snowballs dramatically.

    If you’re a Samsung or Motorola, you have to keep a stockpile of old phones in order to develop, test and requalify for the network. It’s a huge imposition. It’s not that the process is arduous to test updates – that’s relatively simple compared to the cost of maintaining old phones and paying to test them for each update x5 major US carriers. And that is how worldwide versions of a Lenovo Moto E got updates and the US version did not. Most phone manufacturers simplify this and simply decide if they aren’t going to do it for the US market, they won’t do it worldwide.

    “Project Treble aims to fix this by adding in an abstraction layer between the Android OS and the vendor modifications such that the underlying Android OS can be updated without the manufacturer losing compatibility.”

    Not the purpose of Treble, but a good side-effect.
    What Treble does is change this landscape. Because the vendor specific bits don’t change, they won’t require requalification for the carriers. By splitting it out, the Android frameworks can update leaving the vendor implementations the same. That doesn’t make Android proprietary, and again, that’s no one’s goal. Treble makes it unnecessary.

    The modifications for HTC’s edge sensors are a lot like the modifications for Samsung’s bixby – they run in an app, and are updatable, just as Samsung took away the ability to change the settings for the button that launched Bixby recently. These sorts of additions should not break the VTS as you suggest. They’re essentially apps that talk to the OS, not changes to the OS. You can modify beyond the paint on the interface (remember, interface is how you interact with it, not just how it looks) provided you aren’t altering OS frameworks that are going to be replaced with updated versions. As it is, you’re suggesting that Samsung Iris scanner equipped devices won’t be possible for Android O (developer preview already is using Project Treble).
    I don’t believe that will be the case.

    VTS doesn’t limit the differentiation, it just pushes it as a separate blob of software from Android OS updates, and if the handset provider wishes to update their implementation, that’s going to have to undergo all the carrier testing.

    “An easier to use and more consistent platform would most likely increase traffic generation and therefore Google’s revenues which on Android remain half of that generated on iOS.” – This is more a problem with Material Design and less a problem of OS skinning that you’re talking about. A better question is, what is it about Material Design that causes as much as half the use for some use cases? What are the engagement actions people do on iOS that they don’t do specifically on Android, and what are the root causes for that? I suspect it isn’t OS Skinning that’s the root of the problem, but instead, Material Design assumptions and app interfaces that are the problem.

  2. In fact, Google is using Treble to cement themselves even more in the open source world, rather than go proprietary:

    “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.”

    That is, for things that would have potentially broken in the VTS, they ask the vendor to contribute it to AOSP so it can be updated as a part of the Treble frameworks updates – that is, everyone gets the vendor contributed work. Treble pushes everyone to be less proprietary, not more.

  3. Pingback: The real battle of Android's future - Daily Business World

  4. OK sorry its taken me a while to address this..

    First and foremost, I think that what Google wants is irrelevant. If it wants to fix the endemic fragmentation and the software update problem, a greater level of control (going proprietary) is required. If it doesent go there problem not fixed. Desire does not come into this, its a necessity.

    Furthermore, for a company that doesent like proprietary code it certainly seems to have a lot of it including:
    1) GMS the scope of which has been getting bigger and bigger over the last few releases rather than smaller. An Android phone today is far more proprietary now than it was 5 years ago.
    2) Android Wear
    3) Android Auto (for headunit)

    VTS adds another control point on top of CTS for GMS. Anyone who creates GMS for Android will tell you that the CTS is used by Google to ensure that its services and not those of competitors are front and centre of the device. This is how Google generates revenues, the good of the open source community does not come into it. That bit is just marketing garnish albeit a very successful one that keeps developers happy.

Comments are closed.