Honeycomb Preview Now Available

Earlier today, I was just telling someone how we lesser mortals almost never get SDKs much in advance of hardware anymore. Well, we just got one: the Honeycomb SDK preview.

And, besides the preview, the SDK tools and plugins have been updated. Sounds like good stuff. Now to go digest it all for an afternoon snack.

Even if you can't use the new SDK, don't forget to update your tools.

After you've digested it, let us know your favorite new features!

Android Fragmentation

Android is fragmented. There, we said it (okay, so we said it yet again)!

Seriously, it's the so-called elephant in the room. According to Wikipedia , there are 3 dozen Android smartphones, and a handful of tablets and e-readers currently on the market. The list of upcoming Android devices is just as lengthy. But are all the new handsets running the latest and greatest Android platform? Of course not! Some recently released phones are still running Android 1.6. Older models are still running Android 1.5. Even the Motorola Droid is still rolling out the Android 2.1 update-this week! And remember, Android 2.0 (API Level 5) barely exists in the real world, as it was quickly replaced by Android 2.0.1 (API Level 6). It's not easy to keep track of all the Android devices out there, with their varied SDK versions, screen sizes and hardware capabilities. And that, my friend, is exactly what we're talking about when we say fragmentation.

Just How Fragged are We?

The Android platform has reasonably addressed the task of targeting different screen sizes, resolutions and orientations-not to say it's trivial, but at least there are methods of going about doing so. It still adds work as more variations reach the market, but goes a long way towards reducing the burden compared to some other platforms. In addition, various hardware configurations are relatively straightforward to query for or, at least, put smart error handling in for. (Admittedly, some devices don't behave correctly when they're missing certain hardware, and even if considered a bug, in many cases the burden is on the developer to create work-arounds.)

The answer largely depends on what type of developer you are.

What's an Android Developer to Do?

If you're a hobby developer, you'll likely want to target the handset you own. After all, who wants to write an app that can't run on their own phone? Perhaps start with the Android phone you've got, and then move on to the biggest and most stable Android handsets available to your target users.

If you're a mass market developer, you'll likely need to target the lowest available version that allows your application to perform the features it requires. You'll need to target as many phones as possible.

If you're a game company or technology company designing awesome new features, you'll probably want to target the Android devices with the very latest version of the platform, and those with the best performance so all of your nifty features run smoothly.

Is Fragmentation Going to Get Better, or Worse?

Better, and worse-but there is hope on the horizon. Google has recently come forward saying they have a plan on addressing at least part of the fragmentation issue. To us, the fact that Google has stepped forward and admitted that fragmentation is a problem is a very good sign.

Technically speaking, Android is a community developed, open source project run by the Open Handset Alliance. Google is but one of about 70 member companies, and not even the biggest though they may be one of the most influential. But, the reality is the Android is Google's baby. They created it and they should really control it, open source or not-someone's got to. Sure, getting community involvement is great, but direction must be provided by someone; going democratic only works when everyone (developers, manufacturers, operators) is on the same page and they just aren't. Platforms like the Apple iPhone haven't had this problem because they are a tightly locked down platform with a reasonably small set of devices, limited operators, and more controlled versioning; the iPhone is also a more mature platform and not going through rapid and successive improvements in a short time frame-it pisses their loyal user base off royally if they release one device only to have a new and improved one available three months later. On the Android platform, we've got an explosion of devices with a very broad range of features, price ranges, and networks.

Android Team to Adjust SDK Releases Based on Fragmentation Concerns

Anyway, Google has said that they will slow down the rollout of new Android SDK versions. The Android tools were separated from the SDK in Android 1.6, so now tools can be updated separately from the SDK. Google will also separate out the Android apps that generally ship with the platform so they can be updated on demand without a new SDK rollout to the field. This is basically the desktop model. Apple doesn't need to ship a new Mac OS X to ship a new version of Safari, iTunes, or Xcode. Microsoft doesn't need to ship a new version of Windows to update Internet Explorer, Outlook, or Visual Studio. So, why should Google ship a new version of the Android SDK just to get a new version of the browser, map app, email client, or any of the other apps out?

By splitting the Android SDK into components, its users, developers, handset manufacturers, and carriers should be able to work more effectively. Users won't have to wait for their manufacturer and carrier to approve a full firmware release just to get a security bug fix in the browser. Developers will have fewer platform targets to worry about; instead, there may be more downloadable, add-on components to manage. Manufacturers won't have to try to keep up with the crazy speed with which the Android platform has been progressing. (During our current book project, we saw the number of platform levels go from 3 to 7. That's pretty crazy!) And, finally, carriers won't be burdened by so many full firmware updates that always leave them at risk of confused users or broken handsets. Remember, the operator is the first line of support. Large rollouts are costly for them. With the desktop model, people call their manufacturer or developer first, not their ISP or OS maker; the opposite is true for phone apps and carriers.

Where Do We Go From Here?

The exact nature of how this will play-out is unknown. Claims that everything will settle down and become totally managable are likely overly optimistic. Will the Android team truly be able to add new platform features through add-ons rather than full platform upgrades? Hopefully, but we'll see.

Android SDK API Level 6!

Congratulations to the Android SDK for leveling once again! (I can't help but think of gaming when the API Level is mentioned.) We're now at Level 6, which corresponds to Android 2.0.1, Release 1.

The SDK Tools have been updated, as well, to Release 4, which now requires the updated Eclipse plug-in 0.9.5.

Many handsets still have Android 1.6 and, if rumors are to be believed, will remain so. Thus, Android 1.6, Release 2, is now available to resolve some platform issues. It also requires SDK Tools, Release 4. Curiously, though, it has not "leveled up." Will this be an issue? How will applications and developers know if their Android 1.6 has defects found in Release 1 or not?

Get it all* now while it's hot! :)

*If I'm counting correctly, that's four new things:

• Android 2.0.1, Release 1, SDK
• Android 1.6, Release 2, SDK
• SDK Tools, Release 4
• Eclipse ADT Plug-in 0.9.5

Project Pitfalls: 10 Business Risks of Android Development

Android is an exciting new platform to develop for, but there are a number of risks associated with Android projects which should not be overlooked. Here’s a short list of what we see as the project pitfalls of Android development at this time. Read more...

[Note: We're blogging over at Network World all this month. Head on over to register to win a free copy of our book!]

Android Needs Google For Now

Today, we’re seeing two types of Android devices on the market: those with a basic, “vanilla” installation of Android and those with Android and Google services. This means developers and manufacturers have choices as to whether or not to integrate tightly with Google services. This decision requires some serious thought. Read more...

[Note: We're blogging over at Network World all this month. Head on over to register to win a free copy of our book!]

The Top Five Business Benefits of Android

With the Android 2.0 release newly available, perhaps you’re wondering if the Android platform is right for your business or your project. Here are the top five benefits of Android from a business perspective (primarily for prospective application developers). Read more...

[Note: We're blogging over at Network World all this month. Head on over to register to win a free copy of our book!]

Android Development Tip: Managing AVDs with the Eclipse Android Development Tools Plug-In

I've updated my Eclipse development environment a number of times in the past few weeks, what with the Android 1.5 preview, then the release version. I checked for updates this week and noticed yet another version of the ADT Eclipse plugin was available. One interesting new feature added in the latest version is an Android Virtual Device (AVD) manager, accessible from within Eclipse.

All emulator instances using the Android 1.5 SDK require an AVD configuration. Sure, you can use the android command line interface to create and manage AVDs, but if you just want to create a simple AVD quickly, you can now use the little wizard provided with the ADT plugin. The AVD manager button is added to your Eclipse toolbar. It looks like a little black cell phone.

Simply click it and the AVD manager will launch, listing all AVDs on your system. You can Add and Delete AVDs, as well as Refresh the AVD listing.


When creating a new AVD, you can set the following information:

• The AVD friendly name
• The Target Android system
• The Skin
• Whether or not to create an SD Card Image
• 
  You cannot create custom hardware profiles. That, you still need to use the android command line tool for.