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.