Google shows its hand
Put simply, Google has a problem.
Seven months after the first Nougat phone shipped in volume, 92.8 per cent of the installed base still runs software from 2015 or older. A year after first being shown to device makers and software developers, Android Nougat runs on just 7.1 per cent of Android devices.
Barely 40 per cent of the installed base runs the 2015 version of Android, Marshmallow. The rest runs code from 2014 or before. Only a tiny fraction of phones receive the annual platform updates – and when the big annual release does eventually appear, it’s in a brand-new device. Since we’re hanging on to phones longer, the problem for Google is getting worse.
By contrast Apple can count on over 50 per cent of its installed base using a new release within two weeks or so.
What this means is that developers don’t use APIs for years after Google makes them available as many choose to write for the lowest common denominator. And all because phone makers chose when you could install a big platform update. Over the years, Google has been pushed more and more into Google Play Services binary, but there’s only so much you can put in Play Services.
Google’s latest attempt to fix this may be the most significant platform news this year, eclipsing even the next version of Android, Android “O”.
Curiously, Google chose to disclose Project Treble quietly last week. Essentially the new distribution process gives Google greater control over pushing out OTA (Over The Air) updates.
“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,” writes Iliyan Malchev, Project Treble team lead.
In his post, Malchev hopes that more phone-specific code – from phone makers – will find its way into the AOSP open-source base. But analyst Richard Windsor sees it as a step in the opposite direction towards a proprietary Android.
Last year Windsor tipped Google to make a major break with tradition, in response to a settlement for Oracle in the long-running intellectual property case over Java.
“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,” Windsor explained yesterday. “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.”
The problems, Windsor thinks, are with the new Vendor Test Suite. Phone makers with unique features like the squeeze gesture on the new HTC flagship may not choose to add them to the open source base. Google could then “fail” the phone maker, denying them Google Play services – but this is a risky tactic in markets where competition authorities are watching Google closely.
How phone makers and Google resolve this will define the future of Android. Google has promised more details soon. But the stakes are high, as Windsor reminds us: “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.”
Of course, taking Android proprietary is far from the easiest or most likely option. Google’s Android successor has heaved into view – and that, presumably, will not come with unresolved IP issues, and have a new distribution architecture for platform updates.
So, about Android O
The new O update itself is almost a footnote, but here goes. Android O – it has not been christened yet – is largely about battery life and performance. The most noticeable addition is contextual popups, such as notifications, from the app icon. It’s a feature borrowed from Apple, who made a great fuss about its introduction in 2015. But since Apple’s implementation requires Force Touch – additional pressure on the screen – it hasn’t really caught on, and for a very familiar reason. App developers couldn’t count on the device supporting Force Touch so didn’t bother. Because few apps have useful (or any) Force Touch menus, the users didn’t bother. ®