Android Project Treble – Yellow brick road

Reply to this post

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.