I wrote a post in the Android-Developer blog today cautioning about the use of Content Providers that aren’t part of the published Android API. John Gruber pounced, deducing that, contrary to our stated policy, this constituted evidence of “private APIs”. Let me explain exactly what’s going on here.
The Policy · I think it was best expressed by Android platform engineer Dianne Hackborn in her Multitasking the Android Way post:
The available APIs must be sufficient for writing the built-in Google applications, as part of our "all applications are created equal" philosophy. This means background music playback, data syncing, GPS navigation, and application downloading must be implemented with the same APIs that are available to third party developers.
The SMS Application · It’s like this; Google built an SMS app that’s part of the basic application suite. It doesn’t use any private APIs. Anyone could write a replacement SMS application and deliver it via in the Android Market, and in fact this has happened, for example Handcent SMS. It’s perfectly possible that a handset provider might ship some other SMS app instead of Google’s.
The Android platform includes the SMSManager class for sending SMS messages, and you can set up a listener to receive them as well. Nothing private or secret.
The Google-provided SMS app has its own database that it uses to stash away the SMS history, and it sets up its own Content Provider for its own internal use. It turns out that if you read the source code, you can figure out how to reach in and access that Content Provider. Which is probably a bad idea, because it’s part of an application that might not even be there.
I personally think the benefits of an Open Source platform exceed this sort of cost — when someone uses the source to figure out how to do something that really isn’t very smart.
That’s the story. Does this constitute a “Private API”? Your call.