Android Compatibility

Android is designed to run on many different types of devices. Fordevelopers, the range and number of devices means a huge potential audience: themore devices that run Android apps, the more users who can access your app. Inexchange, however, it also means that your apps will have to cope with that samevariety of hardware.

Fortunately, Android has built-in tools and support that make it easy foryour apps to do that, while at the same time letting you maintain control ofwhat types of devices your app is available to. With a bit of forethought andsome minor changes in your app's manifest file, you can ensure that userswhose devices can’t run your app will never see it in the Android Market, andwill not get in trouble by downloading it. This page explains how you cancontrol which devices have access to your apps, and how to prepare your apps tomake sure they reach the right audience.

What does “compatibility” mean?

A device is “Android compatible” if it can correctly run apps written for theAndroid execution environment. The exact details of the Android executionenvironment are defined by the Android Compatibility Definition Document,but the single most important characteristic of a compatible device is the ability to install and correctly run an Android.apk file.

There is exactly one Android API for each API level, and it’s the sameAPI no matter what kind of device it’s installed on. No parts of the API areoptional, and you never have to worry about parts of the API missing on somedevices. Every compatible Android device your app will land on will includeevery class and every API for that API level.

Of course, some APIs won’t work correctly if a particular device lacks thecorresponding hardware or feature. But that’s not a problem: we also designedAndroid to prevent apps from being visible to devices which don’t have featuresthe apps require. We’ve built support for this right into the SDK tools, andit’s part of the Android platform itself, as well as Android Market.

As a developer, you have complete control of how and where your apps areavailable. Android provides tools as a first-class part of the platform that letyou manage this. You control the availability of your apps, so that they reachonly the devices capable of running them.

How does it work?

You manage your app’s availability through a simple three-step process:

You state the features your app requires by declaring <uses-feature>elements its manifest file.
Devices are required to declare the features they include to AndroidMarket.
Android Market uses your app’s stated requirements to filter it from devicesthat don’t meet those requirements.

This way, users never even see apps that won’t work properly on theirdevices. As long as you accurately describe your app’s requirements, you don’tneed to worry about users blaming you for compatibility problems.

If you’re familiar with web development, you may recognize this model as“capability detection”. Web developers typically prefer this approach to“browser detection”, because it’s very difficult to keep up as new browsers andnew versions of current browsers are released. By checking for support forspecific required capabilities instead of the current browser, web developersget better fine-grained control. That’s the same approach Android uses: sinceit’s impossible to keep up with all the Android devices being released, youinstead use the fine-grained controls Android provides.

Filtering for technical reasons

Filtering on Android Market

Android Market filters the applications that are visible to users, sothat users can see and download only those applications that are compatible withtheir devices.

One of the ways Market filters applications is byfeature compatibility. To do this, Market checks the<uses-feature> elements in each application's manifest, toestablish the app's feature needs. Market then shows or hides the application toeach user, based on a comparison with the features available on the user'sdevice.

For information about other filters that you canuse to control the availability of your apps, see theMarketFilters document.

Android includes support for a lot of features, some hardware and somesoftware. Examples include compass and accelerometer sensors, cameras, and LiveWallpapers. However, not every device will support every feature. For instance,some devices don’t have the hardware horsepower to display Live Wallpaperswell.

To manage this, Android defines feature IDs. Every capability has acorresponding feature ID defined by the Android platform. For instance, thefeature ID for compass is“android.hardware.sensor.compass”, while the featureID for Live Wallpapers is“android.software.live_wallpapers”. Each of these IDsalso has a corresponding Java-language constant on thePackageManager class that you can use to query whetherfeature is supported at runtime. As Android adds support for new features infuture versions, new feature IDs will be added as well.

When you write your application, you specify which features your app requiresby listing their feature IDs in<uses-feature> elements inthe AndroidManifest.xml file. This is the information that AndroidMarket uses to match your app to devices that can run it. For instance, if youstate that your app requires android.software.live_wallpapers, it won’t be shownto devices that don’t support Live Wallpapers.

This puts you in total control of your app — because you don’t have todeclare these features. Consider an example involving cameras.

If you’re building a really impressive next-generation augmented-reality app,your app won’t function at all without a camera. However, if you’re building ashopping app that only uses the camera for barcode scanning, users withoutcameras might still find it useful even if they can’t scan barcodes. While bothapps need to acquire the permission to access the camera, only the first appneeds to state that it requires a camera. (The shopping app can simply check atruntime and disable the camera-related features if there’s no camerapresent.)

Since only you can say what the best approach is for your app, Androidprovides the tools and lets you make your own tradeoff between maximizingaudience size and minimizing development costs.

Filtering for business reasons

It’s possible that you may need to restrict your app’s availability forbusiness or legal reasons. For instance, an app that displays train schedulesfor the London Underground is unlikely to be useful to users outside the UnitedKingdom. Other apps might not be permitted in certain countries for business orlegal reasons. For cases such as these, Android Market itself providesdevelopers with filtering options that allow them control their app’savailability for non-technical reasons.

The help information for Android Market provides full details, but in anutshell, developers can use the Market publisher UI to:

List the countries an app is available in.
Select which carrier’s users are able to access the app.

Filtering for technical compatibility (such as required hardware components)is always based on information contained within your.apk file. Butfiltering for non-technical reasons (such as geographic restrictions) is alwayshandled in the Market user interface.

Future-proofing

There’s one additional quirk that we haven’t yet addressed: protecting appsfrom changes made to future versions of Android. If the Android platformintroduces a new feature or changes how existing features are handled, whathappens to existing apps that were written without any knowledge of the newbehavior?

Simply put, Android commits to not making existing apps available to deviceswhere they won’t work properly, even when the platform changes. The best way toexplain this is through examples, so here are two:

Android 1.0 through 1.5 required a 2 megapixel camera with auto-focus.However, with version 1.6, Android devices were permitted to omit the auto-focuscapability, though a (fixed-focus) camera was still required. Some apps such asbarcode scanners do not function as well with cameras that do not auto-focus. Toprevent users from having a bad experience with those apps, existing apps thatobtain permission to use the Camera were assumed by default to requireauto-focus. This allowed Android Market to filter those apps from devices thatlack auto-focus.
Android 2.2, meanwhile, allowed the microphone to be optional on somedevices, such as set-top boxes. Android 2.2 included a new feature ID for themicrophone which allows developers to filter their apps if necessary, but— as with camera — apps that obtain permission to record audio areassumed to require the microphone feature by default. If your app can use amicrophone but doesn’t strictly need it, you can explicitly state that you don’trequire it; but unless you do that, your app won’t be shown to devices withoutmicrophones.

In other words, whenever Android introduces new features or changes existingones, we will always take steps to protect existing applications so that theydon’t end up being available to devices where they won’t work.

This is implemented, in part, using the aapt tool in the SDK. To see which features your app explicitly requires or is implicitly assumed torequire, you can use the commandaapt dump badging.

Conclusion

The goal of Android is to create a huge installed base for developers to takeadvantage of. One of the ways we will achieve this is through different kinds ofhardware running the same software environment. But we also recognize that onlydevelopers know which kinds of devices their apps make sense on. We’ve built intools to the SDK and set up policies and requirements to ensure that developersremain in control of their apps, today and in the future. With the informationyou just read, and the resources listed in the sidebar of this document, you can publish your app with the confidence that only users who can run it willsee it.

For more information about Android device compatibility, please visit:

Android 应用兼容性