31 10 / 2011
Understanding Android Resources
A lot is made of Android fragmentation these days. It’s hard to read a popular tech blog without at least a mention of the “massive fragmentation of Android”. It’s a popular thing to say, and keeps the Apple followers (see what I did there?) happy with said publication.
Some of the concern is related to the physical differences in devices such as software/physical keyboard, with/without GPS/camera/etc. These are justifiable concerns, certainly, but nothing that difficult to manage. The manifest file associated with every Android app gives you the necessary flexibility to manage which features of your app are required or not. So, if a GPS is absolutely required for your app, you can use the manifest to tell the Android Market to filter your app out of results on devices that don’t have a GPS. Simple.
Using the same example, if a GPS is not required, but is a nice additional feature for the experience, you can declare the feature usage optional. So, the app will show for devices with or without a GPS. Then at runtime, you simply need to detect whether the presence of a GPS should alter your workflow or UI. In many cases you can easily use reflection to determine what is or is not available. There can be outliers, certainly, but this is how physical fragmentation is handled in most scenarios.
I think more of the fragmentation is aimed at the variations of device screen sizes. You can look at the Droid, the Incredible, the Droid X, the Bionic, the Dell Streak, and the Galaxy Nexus to see a variety of screen sizes. What Android does is deal with these variations by creating a few general categories that all devices fit into.
There are four generalized buckets for size (small, normal, large, and extra large). There are also four buckets for density (ldpi, mdpi, hdpi, and xhdpi). Android puts each device into a combined bucket based on size and density. You can find a nice chart overview of those here: http://developer.android.com/guide/practices/screens_support.html#testing.
So while every chart or graph you’ll find on your favorite tech blog shows the countless configurations for Android devices, the truth is that 90% of the Android devices being tracked by Google fit into just 2 buckets (http://developer.android.com/resources/dashboard/screens.html). Both buckets are of the same size generalization, and really only differ in that 17% offer 160 dpi and the other 72% offer 240 dpi.
What that boils down to for the developer is simply two sets of images, one for mdpi (160 dpi) and one for hdpi (240 dpi) and one layout grouping (large size generalization, views for both portrait and landscape).
So, as Cyanogen asked on Twitter the other day, who’s really worried about fragmentation?
You’ll find a great explanation of how Android handles sizes and densities, from the perspective of a developer, here as an answer on StackOverflow.
