The Five Steps to Future Hardware Happiness

[This post is by Reto Meier AKA @retomeier, who wrote the book on Android App development. —Tim Bray]

Two questions I regularly get asked are “Why isn’t my app visible on the Market on the (insert device name here)?” and “How can I prepare for GoogleTV and Android tablets?” If you care about how broadly your app is available, pay attention now. Seriously. I don’t want to hear anyone telling me they weren’t told. [Seems a little combative? -Ed. Take it up a notch! -RM]

By now you’ve probably heard of Google TV, the Samsung Galaxy Tab, and the Dell Streak. These are only the vanguard — Android is quickly moving to hardware that is increasingly different from the smartphone devices we’re used to. The variations in hardware — including lack of features like GPS, accelerometers, and video cameras — means it’s time for you to think about what hardware your app needs, and what it can function without.

To make life easier every API includes a FEATURE_* constant. To control your app’s availability on the Android Market, you specify the features required for your app to work. I’d like to encourage you to add manifest Feature nodes for every API you use, specifying them as optional, or not, as appropriate using a manifest uses-feature nodes as shown below:

<uses-feature android:name="android.hardware.microphone"
              android:required="true"/>

Market won’t be inferring any future API features

My earlier post on future proofing your apps describes a process of feature inferring that used your app’s permissions to help us ensure apps were only visible on the appropriate hardware.

This process has evolved over time. From now on Market won’t be inferring future API features and we have no way to infer some previously available APIs (eg. sensors). As a result you’ll need to specify your mandatory and optional feature requirements — or risk your app either breaking or not being available for some users.

The 5 steps to future hardware happiness

1. Specify a uses-feature node for every API feature used by your app. This forces you to think about what your app uses, allowing you to:

2. Decide which features are necessary for your app to be useful and mark those featured with the attribute required=true. This lets Market hide your app from any device that doesn’t support the hardware features your app requires.

   <uses-feature android:name="android.hardware.telephony"
              android:required="true"/>

3. For features that aren’t strictly required, set required=false.

   <uses-feature android:name="android.hardware.bluetooth"
              android:required="false"/>

4. Then go in to your code and find where you have used the optional features. Use the hasSystemFeature method from the PackageManager to determine if the hardware is available and provide alternative paths for your code as appropriate.

   PackageManager pm = getPackageManager();
boolean hasCompass = pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS);

5. Now you can sleep soundly in the knowledge that no matter what variation in Android compatible hardware comes to market, your app will always (and only) be available on those it supports.

You can find more details on how the Android Market uses filters to determine whether to show your application to a user who is browsing or searching for applications on a given device at the Market Filters page on the Android Developer Site.

You have read this article with the title The Five Steps to Future Hardware Happiness. You can bookmark this page URL https://azaquery.blogspot.com/2010/10/the-five-steps-to-future-hardware_11.html. Thanks!