At Google I/O 2011, the Android team announced that there were over 300 Android devices in distribution throughout the world.  These devices range in size from 2.5″ phones to 10″ tablets (or 60″ televisions).  They cover 9 different versions of Android and a variety of custom interfaces.  Some Android displays contain 143 pixels per linear inch, others as many as 342.  Some have physical devices, some have trackballs, some have gyroscopes.  Android was supposed to move us past the J2ME world’s compatibility issues, but with this much variation between devices, it still takes a lot of effort to look good on all of them.  What’s a company to do?

Fortunately, the Android team has done a lot to make adaptable apps possible.  All (…almost all) of Android’s layout classes are design to work well on a variety of screen sizes.  There’s a nifty resource scheme that makes it easy to provide different icons for screens with different pixel densities, and known patterns for making use of new features on newer Android versions while still degrading gracefully on older versions.  9-Patch graphics allow custom buttons and text boxes to stretch and shrink appropriately.

There are examples of companies handling almost everyone.  Rovio covered 97% of Android devices with Angry Birds Rio, and Pulse managed 99%.  Still, you have to draw the line somewhere and looking great on 95%+ of all Android devices requires an investment in polish.  If this is you first foray into developing a mobile app, I recommend targeting Android 1.6 (Donut) and up.  This covers 99.2% of all devices accessing the Android Market today.  If you end up needing an API from version 2.1 (Eclair), the next version still active, you can pretty safely jettison support for 1.6, which will only cost you another 1.3% of the Market’s devices.  2.1/Eclair is a tougher case to drop, at 9.6% of the Market, and you barely have a choice but to support 2.2/Froyo (35.3%).  You can use the fancy new features from later platforms, but again, you’ll have to go out of your way to build a simpler experience for older versions.

If you’re pretty sure you’re going to make an ongoing investment in native Android apps, you should be designing your apps with some of the newer UI features like fragments and action bars, especially because they make it easier to develop related, but distinct, interfaces for phones and tablets.  As a bonus, using newer UI features means your app won’t look dated 9 months from now.  Less than 3% of devices (3.0+) support Fragments today, but the Android team has provided a compatibility library so that you can use fragments all the way down to 1.6.

I hope this post and its included links have helped you understand what you’re up against in supporting the myriad Android devices available and what you can do about it.  If you’d like some more guidance, contact me and I’ll be glad to help you get past these challenges.