a-look-over-manifest-attributes-used-in-google-play-filtering

                   When a user searches for an app in play store, Google play filtered his searches to provide him/her the best suited result for him/her. The google play get an idea about filtering, from the several types of app metadata and configuration settings, including manifest declarations, required libraries,architecture dependencies, and distribution controls set in the Google Play Developer Console, such as geographic targeting, pricing, and more. We will look into some manifest attribute, their purposes and their specialties.

1. <support-screens>

       This attribute is used to define the screen sizes of the devices, into which you supposed your application should be installed. Accordingly Google play filters your application and put it into the list of devices into which your application can be installed. As a general rule Google Play assume that smaller layout can be easily fit into the large screen devices. But not the larger layouts in the smaller devices. So thus, if any application declares support for normal screen size then Google Play allows that app to be installed for both normal and the larger screen size devices.

And If an application does not declare this attribute in their manifest , then Google Play picks up the default values, vary by API Levels

Suppose: The manifest declares <uses-sdk android:minSdkVersion="3"> and does not include a<supports-screens> element.

Result: Google Play will not show the app to a user of a small-screen device, but will show it to users of normal and large-screen devices, unless other filters apply.

Suppose: The manifest declares <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"> and does not include a<supports-screens> element.

Result: Google Play will show the app to users on all devices, unless other filters apply.

To Know, How to declare the <support-screens> attribute, see <support-screens>.

2. <uses-configuration>

This attribute helps Google Play to filter the apps which have any special hardware requirement.

Suppose:The manifest includes <uses-configuration android:reqFiveWayNav="true" />, and a user is searching for apps on a device that does not have a five-way navigational control.

Result: Google Play will not show the app to the user.

Suppose: The manifest does not include a <uses-configuration>element.

Result: Google Play will show the app to all users, unless other filters apply.

To Know, How to declare the <uses-configuration> attribute, see <uses-configuration>

3. <uses-feature>

        If any application uses this attribute in their manifest, then Google Play categorized that app for the list of devices which satisfy the required device features. This Fuctionality was introduced in Android 2.0.

Suppose: The manifest includes <uses-feature android:name="android.hardware.sensor.light" />, and a user is searching for apps on a device that does not have a light sensor.

Result: Google Play will not show the app to the user.

An application may also require a specific Open-GL ES version support, using the 

 <uses-feature  android:openGlEsVersion="int"> attribute.

Suppose: An app requests multiple OpenGL-ES versions by specifying openGlEsVersion multiple times in the manifest.

Result: Google Play assumes that the app requires the highest of the indicated versions.

Suppose: An app requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0.

Result: Google Play will show the app to the user, unless other filters apply. If a device reports that it supports OpenGL-ES version X, Google Play assumes that it also supports any version earlier than X.

Suppose: A user is searching for apps on a device that does not report an OpenGL-ES version (for example, a device running Android 1.5 or earlier).

Result: Google Play assumes that the device supports only OpenGL-ES 1.0. Google Play will only show the user apps that do not specify openGlEsVersion, or apps that do not specify an OpenGL-ES version higher than 1.0.

To Know, How to declare the <uses-feature> attribute, see <uses-feature>

4. <uses-library>
   

If application uses this attribute in the manifest, then it means that the application wants that the specific shared library should be present on the devices. It creates a filter for the google play to show only those apps whose library need satisfy by the device.

Suppose: An app requires the com.google.android.maps library, and a user is searching for apps on a device that does not have the com.google.android.maps library.

Result: Google Play will not show the app to the user.

Suppose:The manifest does not include a <uses-library> element.

Result: Google Play will show the app to all users, unless other filters apply.

To Know, How to declare the <uses-library> attribute, see <uses-library>

5. <uses-permission>
   If in any app the <uses-feature> attribute is not declared properly, then Google Play managed itself through <uses-permission> attribute whether the app has reqiurement of the hardware feature or not. For example, if an application requests the CAMERA permission but does not declare a <uses-feature> element for android.hardware.camera, Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.
   

In general, if an application requests hardware-related permissions, Google Play assumes that the application requires the underlying hardware features, even though there might be no corresponding to <uses-feature>declarations. Google Play then sets up filtering based on the features implied by the <uses-feature> declarations.

For a list of permissions that imply hardware features, see the documentation for the <uses-feature> element.

6. <uses-sdk>
   An application can require a minimum API level.
   

Minimum Framework Version (minSdkVersion)

Suppose: The manifest includes <uses-sdk android:minSdkVersion="3">, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2

Result: Google Play will not show the app to the user.

Suppose: The manifest does not include minSdkVersion, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2.

Result: Google Play assumes that minSdkVersion is "1" and that the app is compatible with all versions of Android. Google Play shows the app to the user and allows the user to download the app. The app crashes at runtime.

Because you want to avoid this second scenario, we recommend that you always declare a minSdkVersion. For details, see android:minSdkVersion.

Maximum Framework Version (maxSdkVersion)

Deprecated. Android 2.1 and later do not check or enforce the maxSdkVersion attribute, and the SDK will not compile if maxSdkVersion is set in an app's manifest. For devices already compiled with maxSdkVersion, Google Play will respect it and use it for filtering.

Declaring maxSdkVersion is not recommended. For details, see android:maxSdkVersion.

There are few attributes used in manifest as a filter for Google Play, but they trigger in exceptional cases. Used in some high – performance gamens and similar application, Most application should never used these filters.

Advanced Manifest Filters

1.<compatible-screens>

Google Play filters the application if the device screen size and density does not match any of the screen configurations (declared by a <screen> element) in the <compatible-screens> element.

Caution: Normally, you should not use this manifest element. It will resuce the user base for your application, instead of using this use <support-screens> manifest element (described above) to enable screen compatibility mode for screen configurations you have not accounted for with alternative resources.

2.<support-gl-texture>

Google Play filters the application unless one or more of the GL texture compression formats supported by the application are also supported by the device.

Reference :- Google Play Filters

Download :- Google Play Filtering