Google should revise its Android update messaging strategy

Samsung and Verizon have finally gotten on the same page and pushed out the long-awaited Android 6.0 Marshmallow update to Galaxy S6 handsets — my own included. Only two weeks prior, I had rhetorically questioned the status of the update on Twitter, only to receive a canned response from Verizon support informing me how exciting these upgrades truly were.

https://twitter.com/VZWSupport/status/712641047235534848

But Verizon support was wrong. The update isn’t all that exciting. Featurewise, the transition from Lollipop to Marshmallow is a fairly minor one (except for the battery-saving Doze feature, which implements a reduced power sleep state when devices are idle). This trend towards a lack of marquee new features each year should make Google consider ways to better manage user expectations with respect to the update cycle.

Maturity and fragmentation

I should not have been surprised. Not only had Marshmallow been out for six months (and previewed for nearly 11 months) by the time Verizon and Samsung got all their ducks in a row, but Android itself is, at this point, a fairly mature operating system. With Google’s mobile operating system now on its 23rd major version (in terms of the API levels that correspond to each release), we’re no longer seeing the race for feature parity with Apple’s iOS that defined its early years.

And yet I have fallen into the same behavior pattern as many enthusiasts, and even some casual users: Google announces the next dessert-themed Android release, and the clock starts on an often impatient wait for our devices to get upgraded to the latest and greatest software.

Never mind that we’re already running a version of the platform that seemed perfectly suitable to us when we purchased our devices, and with which, in most cases, we’re still quite content. The bottom line is that something new — and therefore better — is available. We don’t yet have it, and so we want it.

Android has a well-deserved reputation as a fragmented platform, because the millions of devices already on the market are running a handful of different versions of it at any given time. According the latest breakdown of version distribution, as reported by Google using Play Store app data, there are currently six major versions that each continue to power 2 percent or more of in-use devices: Gingerbread, Ice Cream Sandwich, Jelly Bean, KitKat, Lollipop, and Marshmallow.

The largest preponderance of these devices, around 35 percent, run either the 5.0 or 5.1 flavors of Android Lollipop. About 33 percent are on KitKat, with the rest powered by either an earlier version or the latest version, Marshmallow. This latter build, six months post release, still powers less than 5 percent of handsets on the market.

Contrast that with Apple’s tightly integrated ecosystem, in which nearly 80 percent of in-market devices were running the latest iOS 9 about six months post-release (and 75 percent after just four months). It’s a rather huge disparity, and thanks to the Android business model, it’s not likely to alter significantly in the foreseeable future. Unless some radical changes were to be made to the way in which new Android versions meander through the hands of several actors before eventually being pushed to devices, the status quo will persist.

A long and winding road

The largest roadblock exists because, unlike Apple, Google does not manufacture its own devices (even the Nexus line of “pure Android” devices are designed and built by third-party manufacturers). Since original electronics manufacturers (OEMs) like Samsung, HTC, and LG are the ones who license Android and utilize it in products sold to end users, they are also the ones responsible for updating consumers’ phones and tablets.

But OEMs can’t even begin to determine which devices to update before their own vendors — chipset makers like Qualcomm, Intel, and Mediatek — decide which of their systems-on-a-chip will support a given Android version. The vendors must then provide the OEMs with the driver packages that allow a device’s hardware components to be controlled by the Android software.

Adding yet another layer of complexity to the situation are devices sold through cellular carriers. Those carriers must work with OEMs to create special builds of new Android versions that conform to their network specifications and also contain applications specific to the services they offer — often derisively referred to as “bloatware.” Each of these actors must put the upgrades through rigorous quality assurance testing before they are suitable for commercial deployment.

It’s a bit of a mess, at least compared to the Apple model (which makes the hardware, the software, and even the chipsets used in its iOS devices), and there’s little room in the complex process for more efficiency to be injected. Google has made certain strides in this direction by moving some aspects of the platform to a so-called Google Play Services layer, allowing these software components to be updated directly by Google through the Play Store. But major version updates continue to require significant work by its partners, over whom it has little control.

Changing the message

We’ve established that not much can be done to speed up the rollout of updates, especially to people who bought their devices through their cellular service provider. But that doesn’t mean there’s nothing Google could do to alter the status quo, to alleviate the impatience felt by users as they wait weeks and months to finally see that update notice in their notifications panel.

I’ll suggest that the most significant change Google could make would be to alter the messaging, both explicit and implied, inherent to each major version release. Specifically, instead of holding widely publicized launch events and giving each version a catchy name, it might be beneficial for Google to dial back the fanfare surrounding these releases.

By detailing the brand name and new features at big events like Google I/O, the Internet giant is sending the implied message that each Android version change is something quite special — a Very Big Deal. And for a long time, that was true, with each new release bringing major new features and UI refreshes.

With maturity comes stability, however, and most of the new features post-Lollipop (in Marshmallow and the unreleased Android N) have been rather granular and tightly focused. Were Google to start releasing Android updates to its partners in a more low-key fashion — and without the dessert-themed monikers — it would go a long way in dialing back the frustration and impatience that currently plague the upgrade cycle.

An imperfect solution

Of course, with any change may come negative consequences, and in this case those would seem to threaten the realm of marketing. Make no mistake: The dessert-themed brandings help manufacturers sell devices, and simply advertising a product as having “the latest version of Android” isn’t nearly as memorable or effective as declaring that it’s powered by the sweet treat du jour.

Unfortunately, it’s a trade-off that’s almost unavoidable when it comes to downplaying any branding, but the upsides here make it worth fully considering, I’d argue. Android is a juggernaut with a huge slice of market share, and the versioning disparity has created a lot of intractable problems. There are no simple technical solutions to fragmentation or upgrade anxiety; both are issues that exist as a direct result of the platform licensing business model.

Changing the way updates are deployed is not really feasible with the many moving parts that make up the Android ecosystem — but changing expectations would be entirely possible, assuming that the negative repercussions were acceptable to Google and its partners. The less Android focuses on which dessert is on your plate, the less tempting the treats on other plates look, too.