Android Wear and Play Services

Near as I have been able to determine, it is possible to create an Android Wear “micro app” as an ordinary Android SDK project, subject to the limitations imposed by the platform (e.g., no WebKit). However, it would appear that you need to use the Play Services Framework to communicate from the phone/tablet to the Android Wear device and back again. And I’m unclear whether it is possible for a device sans Play Services to be able to deploy the micro app to the Android Wear-able.

(if anyone knows of techniques to avoid this dependency, please write about them!)

This means that Android Wear isn’t an Android accessory, it’s a Google accessory.

When I tweeted my dismay about this, I received some push-back. And since it is difficult for me to explain this in 140 characters, we’ll go with a blog post instead…

I have blogged about the fact that the Play Services framework is proprietary and its ramifications before.

From a technical standpoint, I can see some arguments in favor of using a proprietary library for access to proprietary Web services. Basically, the library is, in effect, the Web service API, not the on-the-wire HTTP-based (or whatever-based) protocol. Having the library be open source would effectively require the on-the-wire protocol to be the API, with the library being a convenience wrapper. That’s certainly a viable route, and most public Web sites with Web services do just that. But if Google doesn’t want to make the on-the-wire protocol be the API, now or long term, that is Google’s decision.

Where I have problems with stuff being poured into Play Services is where no Google Web service should be involved. In that previous post, I mentioned the new LocationClient as being problematic, as there shouldn’t be anything in there inextricably tied to Google’s Web services. Even more dramatic are the hardware-specific ties:

• Google clearly promotes the Cast SDK for working with Chromecast (and, eventually, Android TV), despite the fact that RemotePlaybackClient in the Android SDK may meet the needs of most developers

• And now, Android Wear is effectively tied to Google, if indeed you cannot really create effective Wear apps without Play Services

Or, as I tweeted:

Requiring a proprietary library to mediate [communications] from an open source OS to an open source OS separated by inches is ridiculous.

But, then again, as Al Sutton pointed out, Android Wear isn’t really running an open source OS. Neither does Chromecast.

This is not to say that developers should bypass Play Services on philosophical grounds. It does mean that developers that are inextricably tied to Play Services leave out a growing chunk of the Android ecosystem, the ones outside of the Play Services sphere (Amazon’s Kindle Fire/Fire Phone/Fire TV, BlackBerry’s Android runtime, Nokia X, etc.). Gradle’s product flavors can help with this somewhat, but only to a point.

All I ask is for developers to make decisions with eyes wide open. Technically, depending upon Play Services is not that different than is depending upon some other library project. Tactically, it might even be the right decision. Strategically, just be aware that you are no longer developing for Android, but instead are developing for Play Services (using a lot of Android APIs), and that’s a more-controlled subset of the Android ecosystem.

And now, if you’ll excuse me, I’ll return to listening to the screams of anguish out on Stack Overflow from people trying to make sense of the new tools release and the L Developer Preview…