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.
