The One: Musings on Android 1.0 SDK and the G1

Yesterday was a day for ones. The Android 1.0 SDK Release 1 was made available, a few hours after the T-Mobile G1 was released.

The Developer Roadmap explains a bit more about the cryptic “Release 1” portion of the SDK name. Basically, you can think of that as a patchlevel: any SDK described as “1.0” should meet the 1.0 API, with release numbers handling bug fixes in tools (e.g., the emulator) and such.

Compared to the differences between the M5 and 0.9 SDKs, the gap between the 0.9 and 1.0 SDKs seems relatively minor. I’ll have a better feel for that after (sigh) updating my book again and testing the sample applications against the new SDK.

Here are some interesting tidbits with the new SDK, uncovered while poring through the differences report:

  • There are a few new permissions related to the “subscribed feeds ContentProvider”, yet there does not appear to be any documentation of such a provider. The quoted phrase suggests it handles RSS/Atom feeds on behalf of client applications, and as such would be a handy addition to the framework. But, without a documented list of available properties and such, it would be difficult to use.
  • Android 1.0 adds the notion of a “permission group” (android.Manifest.permission_group), which appears to roll up a group of related permissions. This may allow you, the developer, to choose to request a group of permissions (easy but might cause concern among some users) or request the individual permissions you need (more complicated and prone to needing revision, but “friendlier” in terms of what rights you actually need to have).
  • They have also added “URI Permissions“. To quote from the documentation: “A typical example is attachments in a mail application. Access to the mail should be protected by permissions, since this is sensitive user data. However, if a URI to an image attachment is given to an image viewer, that image viewer will not have permission to open the attachment since it has no reason to hold a permission to access all e-mail.”
  • They mention new facilities for “moving a WebView across process boundaries”, which sounds very reminiscent of Google Chrome.

Additional migration materials can be found on the Android site, or in the new SDK.

As for the T-Mobile G1, there’s already been a wee bit o’ coverage of that topic. Here are just a few personal thoughts:

  • The Amazon MP3 store is a nice touch, as a counterpart to the iTunes store. Why? Because Amazon MP3s, at least when purchased through their Web site, are DRM-free. This dovetails nicely with the open source nature of Android, the barrier-free App Market, and the like, emphasizing that locks and chains are but one way to run a mobile device.
  • If enough applications implement the search hooks, having the dedicated search button on the keyboard could be quite handy. If, however, enough developers fail to implement search, users might get frustrated with whatever the default behavior of that dedicated search button is.
  • Somebody will eventually work out a pay-as-you-go data plan, and an Android device (not necessarily the HTC Dream) will be a likely candidate for such a service provider. For example, on the voice side, I have been a T-Mobile prepaid customer for a while, since I don’t live on my cell phone (under 1000 minutes/year, no text messages). This works well and saves me a ton of money on my mobile service expenses. Data plans used to be that way, but were ridiculously priced, with bandwidth measured in KB, not GB. A modern-era prepaid-data plan might cost $25/GB, as T-Mobile is asking for, just not every month, but only when you need to “fill up” your bandwidth bucket.
  • A lot of people are complaining about Microsoft Exchange support. I’m less worried about that than the not-exactly-confident response given about viewing Word, Excel, or PDF files.
Note: Select outbound links may include affiliate tracking codes. Revenue generated from any potential purchases is used to fund AndroidGuys. Read our policy.



  1. “Android 1.0 adds the notion of a “permission group” (android.Manifest.permission_group)”

    This is not actually new, the SDK is just generating the symbols for them. The XML attributes and programmatic APIs for them have been in the platform and SDK for quite a while. And these are only used for displaying permissions to the user in the UI.

    “They have also added “URI Permissions“”

    This is also not new, and has been in the platform for a long time.

  2. Thanks for the info!

    In the case of URI permissions, it would appear to be first documented in 1.0r1. Leastways, I never ran across it until 1.0r1, and the page I found it on ( did not mention it in 0.9. The machine I’m right this moment on only has M5 on it, but the APIs cited in that new documentation are not documented for the Context class in M5.

    Similarly, I think the symbols for the permission groups mean that those symbols are new to the documentation.

    I’ve gotten a vibe on the various Android Google Groups that people get defensive when folk like me say that such-and-so isn’t in the SDK, when it is but isn’t documented. Please don’t take our comments as a knock on the hard work the Android team has done on the platform and SDK. However, until Android becomes fully open source, all we have to go on is the documentation to tell us what Android can and cannot do.

    All I and others like me can do is amplify the documentation. I apologize if, in our attempts to do so, we inadvertently denigrate the capabilities of Android. And we certainly aren’t trying to disparage the Android team when we fumble around, trying to help.

  3. you gain expertise, would you mind updating…

    your blog with more information? it is extremely helpful for me. i would like to thank you for the efforts you have made in writing this article and i am hoping the same best work from you in the future as…

Comments are closed.