Tech

Android Wear, Auto, and TV save you from skins, and OEMs from themselves

For Android’s second act, customizability takes a back seat to consistency.

Andrew Cunningham – Jun 28, 2014 1:58 pm | 74

Two watches and two OEMs, but one operating system and one interface. Credit: Andrew Cunningham

Our full Android Wear hardware and software reviews won’t run until next week, but now that we’ve spent a couple of days with Samsung’s Gear Live and LG’s G Watch we have a better idea of how these watches are going to look and act.

One thing about both of them sticks out: their software behaves pretty much the same way no matter which device you have. There are small differences that Google has outlined here, but interacting with each watch is exactly the same, and digging down into the settings shows that they’re both running the exact same Android versions and build numbers. This would be unusual for Android phones or tablets, which generally come with OEM-controlled UI skins, hardware and software flourishes, and pre-installed apps.

Talking with Google engineering director David Burke confirmed that all of the new Android initiatives announced at the keynote this week—Android Wear, Android Auto, and Android TV—will have user interfaces and underlying software that is controlled by Google, not by the OEMs.

“The UI is more part of the product in this case,” Burke said to Ars of Android TV in particular. “We want to just have a very consistent user experience, so if you have one TV in one room and another TV in another room and they both say Android TV, we want them to work the same and look the same… The device manufacturers can brand it, and they might have services that they want to include with it, but otherwise it should be the same.”

Burke also told us that Google would be able to manage software updates for these various products directly. With Android TV, the goal is to make those updates automatic and seamless, “more like Chrome on the desktop,” and the plan is to do the same for Android Wear and Auto. A little over a year after Sundar Pichai took over as the head of Android, his influence on the operating system’s direction is obvious.

For Android enthusiasts and others who prefer Google’s (increasingly confident and distinct) aesthetic vision for the operating system, this is good news. You’ll be able to pay more attention to picking the hardware you want, without having to worry about oddball software choices. The flipside of this is that the Wear, Auto, and TV components probably won’t be things that people can download source code for and build on top of. If you want to build an Android watch or a set-top box of your own design, you’ll have to do what Samsung did with the first Galaxy Gear or what Amazon did with the Fire TV—take the standard Android Open Source Project code and do all the UI work and form-factor-specific optimization yourself.

You just don’t need UI skins anymore

This strategy is very different from the one Google used to spread Android to phones and, later, tablets. Earlier in its life, Android was a playground for OEMs. They could buy into an ecosystem that they benefited from—it had an app store and big chunks of its code were developed by Google—while still making and selling their own hardware.

And yet as Android grew, this freedom became a double-edged sword. OEMs took the Android code and piled new features, skins, and apps on top of it, and cellular carriers added even more. At first this was done out of necessity—as more OEMs rushed to release Android handsets, they needed to find an obvious way to differentiate their phone from the phone sitting next to it, made by a different company but running the same software. And yet, as anyone with a bloatware-packed Windows laptop can tell you, hardware makers often aren’t great at making compelling, well-designed software.

Earlier Android versions also weren’t really finished, at least not for an OEM who wanted its Android phone to match or beat the iPhone’s list of features. Google didn’t offer movie or music stores to compete with iTunes before 2011 or so. Google’s standard Android UI was a little clunky and a little homely and didn’t really settle down until the Ice Cream Sandwich and Jelly Bean era. The OS was missing things under the hood, too—if you wanted to support Bluetooth 4.0 (completed in 2010 and implemented first by Apple in the iPhone 4S in 2011), for example, you had to build in support yourself until Android 4.3 rolled around in mid-2013.

Google has worked hard in the last year to combat the worst of these problems. Android as provided by Google is substantially feature-complete at this point—it will add support for new APIs and technologies as they’re released, but it’s not playing catch-up anymore. Many of the applications that would have been updated along with Android in 2011 are now updated independently via the Google Play store, and users can download (and sideload) Google’s keyboard and launcher and apps to work around many OEM customizations.

Android version distribution among active users as of this writing. This is what it looks like when OEMs are in charge of their own updates. Credit: Andrew Cunningham

That being said, Google is going to be dealing with the aftermath of Android’s early marketshare-at-any-cost, make-it-look-however-you-want strategy on phones and tablets for years to come—in 2014, more than 15 percent of active devices run an operating system introduced in 2010. Forty-eight percent run an OS released in 2012. Only 24 percent are running a version that can work with those shiny new smartwatches.

The new Android projects Google talked about at I/O this year circumvent the problem entirely by not offering that kind of freedom to OEMs in the first place. That might make it more difficult for them to differentiate their products from one another, but it saves them a ton of development work and gives users more consistent, more secure devices that all pick up new features at the same time.

Listing image: Andrew Cunningham

Andrew Cunningham Senior Technology Reporter

Andrew is a Senior Technology Reporter at Ars Technica, with a focus on consumer tech including computer hardware and in-depth reviews of operating systems like Windows and macOS. Andrew lives in Philadelphia and co-hosts a weekly book podcast called Overdue.

74 Comments