Ah, yes -- there it is: the familiar smell of Google's annual I/O developers' conference. It's definitely in the air, my friends.
Okay -- maybe that's just the musk from thousands of developers (and, let's be fair, quite a few journalists) descending into the Bay Area. But either way, it's a sure sign that we're about to hear oodles of info on the future of Android and other Google products.
On the Android front specifically, this year's a little unusual in that Google has already taken the wraps off its upcoming "N"-lettered release. We saw the first developer preview of the software back in March and an update to that preview about a month later.
So we already know Android "N" will introduce native support for a multi-window mode along with a fine-tuned take on notifications, some enhancements for quick settings, and several more subtle but no less significant improvements.
And who knows? There could be even more new stuff that's yet to be revealed. We'll find out for sure when I/O kicks off this Wednesday (as well as when Android "N" actually launches later this year).
The biggest challenge for Google, though, isn't about introducing new features into the operating system. It's about something far broader -- and far more difficult to achieve.
It's about getting developers to actually adopt and support the features it creates.
The Android adoption conundrum
We need only to look to last year's Android 6.0 Marshmallow release to see why this challenge is so critical for Google to overcome. Take, for instance, standardized system-level support for fingerprint security -- one of Marshmallow's marquee features. Its presence in the operating system allows developers to implement fingerprint security into their apps without much work and in a way that functions seamlessly across devices.
Seven months after Marshmallow's release, though, the number of apps actually taking advantage of that function is surprisingly limited. Even Google-developed apps that'd be obvious fits for fingerprint support have yet to get on board -- like Google Wallet, which requires a PIN upon startup, and Google Authenticator, which certainly should provide a security prompt when opened.
Then there's Android 6.0's custom text selection feature, which gives developers the ability to have an action from their app appear in a menu whenever a user selects text -- alongside basic text selection commands like copy, paste, and so forth. The idea is that such a setup could let you select text and then quickly perform a specific function with it, like translating the words into another language or looking something up in Wikipedia.
I wanted to do a roundup of interesting apps that supported that feature a while back, but the only prominent titles I could find that used it were Google Translate and Wikipedia -- the same two titles cited by Google in its own initial discussion of the feature. (A couple of very niche-level utilities have experimented with it since then, but not in any way that seems particularly useful for most people.)
Then, last week, a funny thing happened: Google released an update to Translate that downplays the feature and instead pushes users toward a non-system-level alternative -- a floating bubble that appears anytime you copy text and offers an on-demand translation. It's a workaround that, unless you find yourself translating text all the time, may be more invasive and unnecessarily in your face than what the native Android 6.0 method provides. The primary motivation for the change appears to be the fact that the new setup will work on devices running any reasonably recent version of Android -- not just those with Marshmallow or higher.
And that, I suspect, gets at the root of the problem here: It's difficult to get developers to embrace a new feature or standard when it isn't going to be relevant to the lion's share of their users. In the case of custom text selection, even Google's own launch example of the feature has now pivoted away from it, likely for that very reason.
Google can create feature after feature and standard after standard, and every new element can be absolutely fantastic in theory. Unless the company manages to convince developers to embrace those features, though, they remain meaningless and almost even irrelevant in the real world.
And suffice it to say, that's a serious issue for the platform's ability to evolve.
The big picture
Let's get some context for this discussion, shall we? As it stands now, Android 6.0 is on about 7.5% of active Android devices, according to Google's latest estimates as of this writing. Now, 7.5% of 1.4 billion (or likely even more than that, since that figure was from back in September) is certainly nothing to shake a selfie stick at -- but in the big picture, it's still a tiny minority of the total.
Slow rollouts of OS releases have been an ongoing challenge for Android, as I've covered extensively over the years. From a consumer's standpoint, the answer is simple: If fast and reliable ongoing upgrades are a priority for you, do your homework and buy from a manufacturer that provides them. As I've said countless times before, Android presents you with a lot of choices, and the ability to get fast and frequent upgrades is absolutely one of them. Like with any other device-specific feature, you just have to choose a phone that includes that type of experience.
But looking at the state of the platform itself, it's hard not to draw a connection between the slow OS rollouts by many manufacturers and the slow adoption of new features by many developers. And in a broad sense, that may be where this side effect of Android's open model stings the most.
Make no mistake about it: Google is well aware of the issue. In a recent episode of my Android Intelligence podcast, Android SVP Hiroshi Lockheimer readily admitted that the upgrade situation is "frustrating" from his team's perspective. He described it as a "painful reality" of how the mobile industry works right now and said he wishes every Android manufacturer could get new releases out as quickly as Google does with its own Nexus devices.
"That is not something that we want to be unique to Nexus," he told me. "[But] there's what we want, and there [are] the practical realities."
Lockheimer did say he and his team are constantly working with manufacturers and other relevant parties to try to push for faster upgrade deliveries as much as possible. Putting out the first Android "N" preview in March was part of that effort, he confirmed. And perhaps it'll help to some degree -- though the (slightly less) early previews of past Android releases didn't seem to light much of a fire under manufacturers' fannies.
(To be fair, with Android's open nature and the level of diversity that allows, OS upgrades could never be completely consistent across the entire ecosystem. But even within the realities of the platform's flexible framework, there is certainly room for improvement.)
One way or another, finding a way to get developers on board with new standards is going to be Google's next major hurdle. And Android "N," with its native multi-window mode, may be the biggest test yet.
Multi-window mode, you see, requires a specially optimized form of responsive design in order for apps to play nicely in its split-screen environment. Even just basic responsive design -- in which an app automatically adjusts itself to a device's size in order to take full advantage of any amount of screen space -- is something developers have been annoyingly slow to adopt on Android. But while an app not being optimized for a larger screen makes for a non-ideal experience in general, it could make for a non-functional experience when it comes to split-screen use.
However you want to look at it -- and whether or not you want to consider OS upgrades a part of the problem or a realistic part of the solution -- this is an issue that Google is going to have to get its mind around. The relevancy of Android's features and the platform's ability to evolve depend on it.
