Beyond Mobiles: Android as a Universal Development Platform

Early next year GoogleTV will include the Android Market, meaning that it will be a compatible device. A GoogleTV is unlikely to include telephony support, or a camera, microphone, vibration, compass, GPS, or LED. And it likely won’t be the first Android device that isn’t a phone.

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.

Screen size, resolution, and aspect ratio

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.

The existence of particular hardware

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?

Apps like Layar aren’t very useful on a device without a camera and compass. If the answer to question one is yes, you need to create a manifest entry declaring the hardware features your app requires. The Android Market will then filter those apps out for devices that don’t have the required hardware.

  <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.