Android Manifests 101: How to Maximize Your User Base

By Andrew Edelsten, posted Mar 22 2013 at 12:55PM

When we were first putting together Android applications for Project SHIELD, we learned a few important lessons about Android Manifests. Our early attempts at smooth deployments were sometimes slowed down by small errors in manifests, so we’d like to share here what we think are essential to giving your users a happy experience on Project SHIELD, as well as other Android platforms.

During Android application development, programmers often need to add permissions to grant access to system resources or features, or to express hardware requirements. Additionally, Google Play Store scans application manifests and adds implied permissions and features. The combination of these express and implied permissions and features define on which devices an application can run.

When users search for applications on the Play Store, a device's screen parameters, permissions and features are used to filter out applications that are not applicable for the device. Developers must balance the need to avoid filtering where it is not applicable, with their list of must-haves. That is, it can actually be far MORE irritating to a user to download or purchase an application, only to have it not work on their device.

Guidance from Google on the subject states:"To control filtering, always explicitly declare hardware features in <uses-feature>elements, rather than relying on Google Play to "discover" the requirements in <uses-permission>elements. Then, if you want to disable filtering for a particular feature, you can add a android:required="false"attribute to the <uses-feature>declaration."

Developers can ensure that their user base is maximized by avoiding the specification of restrictive manifest elements and by relaxing requirements using the android:required attribute. Remember also that if you're stuck between two sets of potential manifests, you can always upload multiple APKs with different permission sets.

Top 5 incorrect permissions & features:

Incorrect specification of supported screen sizes and densities.

Assuming that a device is a phone based on screen density and forcing portrait display.