November 25, 2014

Android APIs: A Spectrum of Openness

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.



  • Wix

    Excellent summary of the whole Android/iPhone "private APIs" debate!

  • http://intensedebate.com/people/droidin droidin

    Good example would be News and Weather Genie widget – you can't get its code publicly. I tried and failed

    • Mark Murphy

      That's not a question of "private APIs" as it is simply an app that has no released source code. In that respect, it is no different than Gmail, Maps, Goggles, Market, or any number of other apps.

  • pjv

    Some good points, don't get people confused between "open source", as in being able to read the code (the Android OS is, with only some small exceptions, open source), and "unregulated", as in apps being able to do what they want as long as it doesn't concern security aspects.

    In respect with the statement that Android/Google plays by its own rules (is its own unprivileged client) when it comes to Google apps and non-essential Android system apps, I disagree with you that Gmail would be an contrary example. That is, unless you consider the Gmail ContentProvider as a public one rather than a private one to that app (which is what they refer to). That it could have been written before the SDK is no argument, it was probably refactored along. Note too that anyone can write a Gmail app replacing the current one. There is no evidence though to support my claims as the Gmail app is one of the odd ones out that aren't open sourced, not that it would reveal any surprises if it were imho.

    • Mark Murphy

      "That it could have been written before the SDK is no argument, it was probably refactored along." Considering they haven't refactored many of the other apps, even those that have been significantly overhauled (e.g., Gallery), I feel that it is highly unlikely that Gmail is written to the SDK.

      • Dianne

        The new 3D gallery is built entirely against the SDK. (And entirely in Java, too, no native code.) There is still the old Gallery app, which does not rigidly build against the SDK, but it is also no longer maintained.

  • http://intensedebate.com/people/droidin droidin

    True.

  • pjv

    Some good points, don't get people confused between "open source", as in being able to read the code (the Android OS is, with only some small exceptions, open source), and "unregulated", as in apps being able to do what they want as long as it doesn't concern security aspects.

    In respect with the statement that Android/Google plays by its own rules (is its own unprivileged client) when it comes to Google apps and non-essential Android system apps, I disagree with you that Gmail would be an contrary example. That is, unless you consider the Gmail ContentProvider as a public one rather than a private one to that app (which is what they refer to). That it could have been written before the SDK is no argument, it was probably refactored along. Note too that anyone can write a Gmail app replacing the current one. There is no evidence though to support my claims as the Gmail app is one of the odd ones out that aren't open sourced, not that it would reveal any surprises if it were imho.

  • http://www.r4-ds-karte.de m3 karte

    Android is still sappy which equates to flourishing heedfulness upon both sides, for a developer as well as a user.I came to know that Android is expected to power 18 percent of all smartphones sold globally in 2012..

  • http://ekas0615.student.ipb.ac.id khay

    nice info. thank you for sharing. like this :p

  • http://unya.wordpress.com Paweł Lasek

    Regarding GMail & SDK – what if they were simply the applications that the SDK was built for? As in, writing the GApps and SDK together, checking what works well and what is a flop.