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.

About author

AndroidGuys
AndroidGuys 4641 posts

Founded on November 5, 2007, we've enjoyed bringing you the latest in Android news and rumors. Updated daily, we strive to deliver reviews, opinions, and updates on all things related to Android.

You might also like

News and Rumors

Pre-Order Samsung Galaxy Note from Best Buy and Get Free Flip Cover Case

Starting Sunday, Feb 5th Best Buy will be allowing pre-orders of the latest Samsung device on AT&T. The Samsung Galaxy Note, is a 5.3″ HD Super AMOLED device boasting a

News and Rumors

Three great camera apps for serious shutterbugs

While many of us prefer the plain vanilla Android experience of a Nexus device, a Google Experience device, or an AOSP ROM, there is at least one area where it

News and Rumors

Intel’s Atom processors now support Android 4.1 Jelly Bean

Intel has confirmed that it has finished porting Android 4.1 Jelly Bean to its Atom mobile processors. Until recently, Intel’s processors were only equipped for Android 2.3 and Android 4.0,

12 Comments

  1. Wix
    May 07, 17:56 Reply

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

  2. droidin
    May 07, 19:46 Reply

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

    • Mark Murphy
      May 07, 20:38 Reply

      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.

  3. pjv
    May 07, 20:59 Reply

    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
      May 07, 21:20 Reply

      "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
        May 08, 00:57 Reply

        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.

  4. pjv
    May 07, 20:59 Reply

    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.

  5. m3 karte
    May 10, 11:42 Reply

    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..

  6. khay
    July 13, 17:27 Reply

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

  7. Paweł Lasek
    August 24, 09:44 Reply

    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.

  8. Hmm is anyone else encountering problems with the pictures on this blog loading?
    I’m trying to find out if its a problem on my end or if
    it’s the blog. Any responses would be greatly appreciated.

Leave a Reply