Remember, Google Play Services is Proprietary

There are three ways in which Google delivers new APIs to Android developers:

• New SDKs, tied to new versions of Android

• Add-on JARs or library projects, such as the Android Support package

• Google Play Services

In the latter case, while we still need to add an Android library project to our app, some (if not most) of the business logic is in the Play Services app, with the library simply providing a local API wrapper around the IPC to that other app.

It is obvious from Google I|O 2013 that Google is going to place new emphasis on the latter two modes of distribution. This is not to say that the Android OS will not advance – far from it. However, whereas we used to get all new capabilities via new SDK releases, more of those capabilities will be delivered independently of OS updates.

As usual, this is a double-edged sword.

Part of the stated rationale for this is to reduce fragmentation a bit. Anything added to a traditional library – such as the new DrawerLayout in the Android Support package – can be added by developers to apps running on a range of OS versions. Anything added to Google Play Services can be pushed by Google to whatever devices they choose, whenever they want.

In this respect, Google is trying to adopt an architecture a bit more like Firefox OS’s, where the true “firmware” controlled by device manufacturers is thin, with framework code distributed separately on top of it. The objective is to minimize the number of true firmware updates, allowing for more rapid innovation at the framework level, while not requiring the end-to-end ecosystem control seen with iOS.

And this would be wonderful, except for one small problem: Google Play Services is proprietary and is controlled purely by Google. That has many ramifications, including:

1. We do not know what the code does. Part of the interest in Android has been its open source nature, for everything from cobbling together workarounds for bugs to vetting the privacy and security. This is far less possible with a closed-source Google Play Services.

2. Google controls which devices get Google Play Services and when. Hence, Google will be the one to decide when older devices no longer get Play Services updates, not the users, and not the developers. Also, Google can push updates whenever they want, and those updates will immediately affect apps that use Play Services… and those updates may include bugs.

3. Google Play Services is not freely distributable. It, like the rest of Google’s proprietary app suite, is only available to licensees. Hence, you will not find Google Play Services on devices like Amazon’s Kindle Fire. You will not find Google Play Services in ROM mods, unless they either have somehow managed to license it or they are distributing it outside of any license.

(and if some ROM mod maintainer has successfully licensed this code, somebody let me know, as I have tried licensing it for use with a ROM mod and Google ignored me)

And, closely related to the previous issue, developers who wish to support non-Play Android devices will either need to eschew the abilities from Google Play Services, write workarounds, or reimplement them.

Google’s counter-argument – that Google Play Services would only contain code that would have been proprietary anyway – does not pass the smell test IMHO. After all, all code ever written would have been proprietary anyway, had somebody not elected to release it as open source. Even for places where the code already existed in proprietary form (e.g., the fused location provider, apparently culled from Google Maps), the rewrite to allow that code to be used by third parties would have changed it enough that the fact that it started as proprietary should have no effect on decisions going forward. And particularly in the case of the fused location provider, I have difficulty believing that there are reasons that justify having it in Google Play Services instead of the Android Support package.

Ken Kinder recently wrote a blog post about migrating from Google services, where he opened up with:

Looking back on Larry Page’s tenure as CEO, I don’t know if it’s a coincidence but it seems reasonable to believe that, unlike Eric Schmidt, Page does not believe in open standards or an open Internet.

I’m not yet ready to append “or open source” to that statement, but I am getting worried.