Android APIs: A Spectrum of Openness

(cross-posted from AndroidGuys)

Since I think I had a small role in kicking off a current meta-discussion, I figure I should chime in and try to better clarify some remarks.

The iPad launch brought iPhone OS restrictions back to the foreground. One aspect in particular is the ban on accessing “private APIs”. A popular argument then ensues, on whether Android is open or not.

Android is more open than most, but it is not completely open. Rather, there is a spectrum of openness, and Android has portions all along that spectrum.

Fully open APIs are those that are documented in the Android SDK. These include Java classes and methods that can be directly compiled against, documented Intents, documented content providers, etc.

There is then a set of “APIs” that are undocumented but are still reachable from an SDK application. These include public Java classes and methods that are hidden from the SDK but accessible via reflection, undocuemnted Intents, undocumented content providers, and the like. In many places, I counsel against applications using those APIs, because their use can cause all sorts of problems, for developers, users, and Android as a whole. Tim Bray, as part of this meta-discussion, also counsels against their use. However, unlike with iPhone OS, there is no contractual obligation to avoid these – and that’s the primary “openness” difference.

Beyond that, there is a metric buttload of functionality that is not directly reachable from the SDK and is only available to applications built as part of the firmware. Al Sutton outlined limitations on what is available for third-party application installers. While you can see a lot of this functionality by examining the Android open source code, you can’t do much with it yourself.

What truly kicked off all of this were some statements attributed to Andy Rubin, head honcho of Android:

We have an SDK we give to developers, and when we write our Gmail app, we use the same SDK. A lot of guys have private APIs. We don’t. That’s on policy and on technology. If there’s a secret API to hook into billing system we open up that billing system to third parties. If there’s a secret API to allow application multitasking, we open it up. There are no secret APIs. That is important to highlight for Android sake. Open is open and we live by our own implementations.

From the standpoint of private APIs, the question the becomes: is a piece of functionality that is only accessible from the firmware a private API? I would argue no, insofar as “API” implies something that is designed for others to code to. However, there is no question that Android has lots of private functionality, and there are definitely some things that are now effectively “private APIs” (e.g., the ability to adjust so-called “secure settings”).

Frankly, I’m more perturbed by the first sentence. I’ll be stunned if Gmail is written purely to the SDK, simply because none of the built-in Android applications are written to the SDK. Most of them were written before the SDK existed.