This suggests that there are some changes in store for the Android compatibility definition.
If you were an apps developer when the first desktop computer was released – what would you have built?
25 year ago, when I was writing code in my parents living room, I held little expectation that anyone but me would ever use any of it. Sharing an app meant copying it onto a 5.25” floppy disk and biking it over to a friends house where, CRC errors permitting, we’d run it.
There was also the issue of OS fragmentation. I had an IBM compatible PC-XT, my school housed a collection of BBC Micros and most of my friends had Amigas and C64s.
Over the next decade “IBM compatible” became “PC” and the Internet provided an unprecedented distribution mechanism that lets your apps span the globe in a heartbeat.
Right now there are more than 60 different compatible Android devices
Until recently the only way to get your mobile apps onto a phone was through a relationship with a carrier or device maker. Today, every day, 200,000 more people are activating Android compatible devices and searching the Market for your apps.
The open nature of Android means hardware manufacturers are using Android to power an increasingly diverse range of connected devices. At the same time, the Android Compatibility Program is expanding to make more of these devices compatible.
People talk a lot about the dangers of fragmentation
Where some might complain, I see a unique opportunity. Suddenly we’re presented with a blank slate on which to innovate, a rare opportunity to consider new ways for people to interact with devices with which they are already familiar.
If you, as a developer, want to avoid dealing with fragmentation it’s easily done. Pick a single device and develop only for that (I’d suggest the Motorola Droid). You’ll miss out on an order of magnitude of users, but you won’t have to make your apps resolution independent.
The same code will do the same thing on any compatible hardware
The Android Compatibility Program eliminates the real risks of hardware fragmentation. As a developer, all you need to do is make sure that your software doesn’t make assumptions about the underlying hardware.
So what are the assumptions you need to avoid?
- Screen size, resolution, and aspect ratio.
- The existence of particular hardware.
Android developers have been accounting for different screen sizes since Android 1.6 and the release of the Verizon Droid and HTC Tattoo. There is an excellent writeup describing how to support multiple screen resolutions on the Android Developer Guide, aptly titled Supporting Multiple Screen Sizes.
At the risk of providing spoilers, it will tell you to:
- Use density independent pixels rather than hard-coding pixel values in your code.
- Use layouts such as Relative Layout, that don’t assume screen sizes, aspect ratios, or resolutions.
- Provide alternative layouts (if required) for small, normal, or large screens.
- Provide alternative drawable assets for low, medium, or high resolution displays.
- Use the emulator to test, test, and test.
When it comes to hardware dependencies, there are two questions you need to address. Does your app:
- Need any specific hardware in order to function?
- Use some hardware features if they’re available, but which aren’t strictly necessary?
<uses-feature android:name="android.hardware.sensor.compass"/>
<uses-feature android:name="android.hardware.camera"/>
As I described in Future Proofing Your Apps, the Market will make some aggressive guesses even if you don’t specify all the hardware you require, so if the answer to question two is yes, you need to tell the Market.
Specify optional hardware when you will use it if it’s available, but your app doesn’t depend on it.
Google Places uses cool compass arrows to show the direction of a place on interest. Even without the compass the app would still be useful on my TV, so it should declare the compass hardware as optional.
<uses-feature android:name="android.hardware.sensor.compass"
android:required="false" />
Within your app you will still need to find the code that uses the optional hardware and modify its behaviour accordingly.In this example, I’d want the app to simply hide the compass arrow if the compass isn’t available.
You can determine the availability of any hardware feature using the Package Manager and modify the UI or behaviour of your app accordingly.
PackageManager pm = getPackageManager();
pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS);
To make your life easier, all compatible devices will maintain the APIs used to monitor and control all supported hardware, they simply won’t return useful results when the required hardware doesn’t exist.
Be a launch partner for future Android devices
As an Android Advocate I’m regularly asked by developers how they can have their app available as a launch partner for future devices. You can consider this blog post as my answer.
