In this blog post we will focus on ensuring that your app is distributed to as many people as possible or at least, know who will not receive it. Indeed, fragmentation is so strong in Android’s ecosystem that a sizeable number of potential users may easily be put aside. Google provides parameters and tools to help prevent both software and hardware fragmentations issues. The Android Manifest is one of these tools, which we will analyze here.

The Android Manifest is a description file containing necessary information for the system. But it also contains parameters impacting the distribution of your app. For example, here is an Android Manifest, shipping with Shutterbug, of our Open Source projects.

Before reading further, bear in mind that an API level is a number identifying the framework API revision. Generally, each new revision adds functionalities. You can find a table indicating the correspondance between the OS version and the API level here. Here are settings likely to reduce the availability of your app.

Minimum API level

<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="15" />

The minSdkVersion parameter specifies the minimum API level on which the application is able to run (default is 1). A specific API level may be required to use functionalities which were not available in older versions of Android. Thus, by choosing a set of functionalities you choose a minimum Android version. If you want your app to be available on a given percentage of devices, you will be limited in terms of functionalities. If not set, the app may be available on devices missing some APIs, resulting in crashes.

Link between API level and functionnalities

Summary of the most important features added by API level

Each API level introduces a bunch of new APIs. Here is a summary of what was added in the most important API levels:

API level	Android version	Features
Level 8	Android 2.2 Froyo	Apps on external storage, Push notifications
Level 9	Android 2.3 Gingerbread	NFC reading support
Level 11	Android 3.0 Honeycomb	Activity fragments, Action bar, HTTP Live Streaming
Level 12	Android 3.1 Honeycomb	Resizeable home screen widgets
Level 16	Android 4.1 Jelly Bean	Expandable notifications
level 17	Android 4.2 Jelly Bean	Lock-screen widgets, Miracast support (wireless display)

Examples

For instance, for an application willing to receive push notifications, API level 8 is required. Only 1.5% of devices will not see your app on Google Play, which is very reasonable.

If you want to make an app able to read HLS you will probably need to use features available in API level 13. Thus roughly 40% of people (as of July 2013) will not see your app on Google Play.

That may seem to be a big number but remember:

• This is a number counting all the connections to Google Play around the world
• If you begin developing your app now, Android 4.0+ devices will get more and more users
• If video live streaming is the core feature of your app, you have hardly another choice

Permissions and features

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

Permissions are used to ask access rights to components (e.g camera, bluetooth, internet, …).

Features (available from API level 4) indicate required or facultative features (hardware or software). These are used for filtering on Google Play. It is not mandatory to mention features, since they are often implied by permissions.

Regarding hardware features, Google advises to explicitly declare them rather than relying on Google Play to “discover” them. They even put up a table explaining the relationship between permissions and features. For example, ACCESS FINE LOCATION permission implies the android.hardware.location.gps and android.hardware.location features.

Why is it important to explicitly declare hardware features?

Because permissions can prevent your app from being available on devices you wanted it to be! If you have a feature in your app which is not part of the core experience, make it optional. For example, phone call permission will prevent tablets to see your app in Google Play. A less obvious example is the camera on the Asus Nexus 7: it has a camera in front of the device but not in the back. Thus, camera permission will make your app unavailable for Nexus 7.

Supported screens

You should always indicate the screen sizes your app supports. By default, parameters for small and normal screens are set to true. The definition of small, normal, large and xlarge screens is quite vague because it is defined by OEMs. But you can consider that small, normal are for smartphones and that large, xlarge are for tablets. Here’s a figure from Google to give you an idea of the mapping between size and generalized size.

Depending on your strategy (which you should before starting your project), you may want:

• the same layout for all screen sizes: simple and fast but you do not take advantage of larger screen real estate. Below is a comparison of the Now Playing screen from Spotify’s app on a LG Nexus 4 and a Asus Nexus 7. It is exactly the same layout, so you can notice a waste of space on the tablet in landscape.
• a single app handling multiple layouts for different screen sizes: same core but different UI. It also means that it must be an Android 4.x app.
• multiple apps: smartphones + tablets, or Android 2.x + Android 4.×. The point is to address a maximum of your potential users and propose a fresh UI and new features to Android 4.x users. Development cost is higher and maintenance is made harder since you have two different projects.