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:

  1. Incorrect specification of supported screen sizes and densities.
  2. Assuming that a device is a phone based on screen density and forcing portrait display.
  3. Requiring fine location (which implies a GPS requirement) when coarse location will suffice.
    • Get more details on location strategies
    • Using coarse location is nearly always lower power - your users will thank you!
  4. Failing to explicitly specify & set android:required="false" for non-required features.
  5. Failing to consider using input masks for screens that report touch and stylus events at the same time.
    • Ok, you caught me, this one is anticipated. But do keep in mind that up coming Android devices will have multiple flavors of screen "touches." Be sure to use getToolType().

Google's current list of permissions that imply features