We recently updated the developer portal device targeting capabilities to include targeting for the most popular Android devices including the Nexus 5, 7, 10, HTC One, Shield Tablet, Galaxy Nexus, Sony Experia Z, and the Motorola Droid Razr HD to name just a few. Developers can now look at the list of supported, excluded and unsupported devices to quickly see which devices are compatible with their app, and if their app manifest settings have filtered out any devices.

To make sure your app or game is available on as many devices as possible, you need to optimize the targeting via the developer portal and your Android manifest. Android developers know that getting on as many devices as possible is key for a successful app launch. More devices = more downloads = more $$$. Consequently, most developers are aware that careful construction of an app’s manifest (i.e. the AndroidManifest.xml file in the .apk package) is essential for targeting compatible devices, while avoiding devices that would cause their app to perform poorly.

However, there are a few common mistakes developers make with manifests that can cause device targeting to be too restrictive or too permissive when determining an app’s compatibility. Here are 3 common mistakes that we see:

40% of Apps Have an Overly Restrictive Manifest

The <uses-permission> element of AndroidManifest.xml is used to request access to specific hardware and software capabilities on an Android device. Common uses include requesting permission for a camera, location, or telephony services. Many developers don’t realize that specifying these permissions also result in implied <uses-feature> constraints, which restrict the app’s visibility on devices without these features (see Android <uses-feature> API guide for a complete reference). In practice, many apps don’t strictly require the implied features in order to work. For example, many apps with mapping features can either work with the user’s current location (supplied by location services), or can also take input from the user (an address or zip code). Likewise, code in the app can intelligently disable telephony or picture-taking features when the device doesn’t have the necessary capabilities.

Based on our research, almost 40% of apps in Amazon’s catalog appear to have an overly restrictive manifest due to <uses-permission> issues. To check for this, you can use the dump badging command with the aapt tool (included in the Android SDK) to test your app. In the output, look for uses-implied-feature lines, as below:

% ./aapt dump badging ~/projects/MyApp.apk|egrep 'hardware.location|permission'

uses-permission: name='android.permission.ACCESS_FINE_LOCATION'

 uses-feature: name='android.hardware.location'

 uses-implied-feature: name='android.hardware.location' reason='requested android.permission.ACCESS_FINE_LOCATION permission'

 uses-feature: name='android.hardware.location.gps'

 uses-implied-feature: name='android.hardware.location.gps' reason='requested android.permission.ACCESS_FINE_LOCATION permission'

If your app doesn’t strictly require a feature noted with uses-implied-feature, you should explicitly declare the feature to be not required (required="false”) in your app’s manifest. For example, construct your app’s manifest like this to avoid the implied features above:

 <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

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

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

This tells app stores that your app can work on devices without location services, but will take advantage of them if present. Now your app will be available on a wider range of devices!

Incorrect Targeting for non-Touchscreen Devices

By default, the touchscreen feature is enabled, even when it’s not specified in the app’s manifest. During testing, we discovered that 65% of all binaries submitted for Fire TV still do not disable this feature in their manifest. As a result, apps designed specifically for non-touchscreen devices like Fire TV, may be available for Android phone or tablet devices - resulting in a poor customer experience and most likely bad reviews.  

If your .apk is intended for devices that don’t have touchscreens (e.g. Fire TV) you should disable this feature so that app stores filter your .apk appropriately, as in the example below:

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

Over-specifying compatibility with android:maxSdkVersion

The <uses-sdk> element is the primary way an app developer specifies compatibility with one or versions of the Android platform. The android:minSdkVersion attribute specifies the earliest compatible Android API level for the app. Normally, this is the only attribute a developer needs to specify, since Android API levels are (by and large) backwards-compatible. It is recommended that you always declare this attribute.

Some app developers also specify the android:maxSdkVersion attribute, usually out of an abundance of caution, believing this will stop their app from being executed on future API levels until they can test and verify. However, this is not the case; maxSdkVersion is not used by the Android OS to stop app installs or execution. It is solely used by app stores for app discovery purposes. In practice, this attribute should not be specified unless there is a known incompatibility with a higher API level. Otherwise, you’re limiting your potential discovery for devices with a higher API level with no benefit to your existing app customers.

Consider an app that supports Android 4.0, API Level 14 and is known to work on Android 4.4, API Level 19. Some developers may choose to specify <uses-sdk android:maxSdkVersion> as below, believing (incorrectly) this will stop the app from running on Android 5.0, API Level 22:

<uses-sdk android:minSdkVersion=”14” android:maxSdkVersion=”19” />

Instead, they should just specify the minimum version, unless there is a known problem with higher Android levels:

<uses-sdk android:minSdkVersion=”14” />

Links to Additional Resources

For more information about device targeting, check-out the following additional resources:

• Register for a FREE Developer account
• Introduction to Device Targeting
• Using Device Targeting
• Supported Filters on Amazon Appstore
• Going Granular: Device Targeting for non-Amazon Devices