How Filters Work on Google Play

Introduction

Google Play uses the filter restrictions described below to determine whether to show your application to a user who is browsing or searching for applications from the Google Play app.

When determining whether to display your app, Google Play checks the device's hardware and software requirement, as well as it's carrier, location, and other characteristics. It then compares those against the restrictions and dependencies expressed by the application's manifest file and publishing details.

If the application is compatible with the device according to the filter rules, Google Play displays the application to the user. Otherwise, Google Play hides your application from search results and category browsing, even if a user specifically requests the app by clicking a deep link that points directly to the app's ID within Google Play.

Filtering based on the App Manifest

Most filters are triggered by elements within an application's manifest file, AndroidManifest.xml (although not everything in the manifest file can trigger filtering). Table 1 lists the manifest elements that you should use to trigger filtering, and explains how the filtering for each element works.

Table 1. Manifest elements that trigger filtering on Google Play.

Manifest Element	Filter Name	How It Works
<supports-screens>	Screen Size	An application indicates the screen sizes that it is capable of supporting by setting attributes of the <supports-screens> element. When the application is published, Google Play uses those attributes to determine whether to show the application to users, based on the screen sizes of their devices. As a general rule, Google Play assumes that the platform on the device can adapt smaller layouts to larger screens, but cannot adapt larger layouts to smaller screens. Thus, if an application declares support for "normal" screen size only, Google Play makes the application available to both normal- and large-screen devices, but filters the application so that it is not available to small-screen devices. If an application does not declare attributes for <supports-screens>, Google Play uses the default values for those attributes, which vary by API Level. Specifically: For applications that set either the android: minSdkVersion or android: targetSdkVersion to 3 or lower, the <supports-screens> element itself is undefined and no attributes are available. In this case, Google Play assumes that the application is designed for normal-size screens and shows the application to devices that have normal or larger screens. When the either the android: minSdkVersion or android: targetSdkVersion is set to 4 or higher, the default for all attributes is "true". In this way, the application is considered to support all screen sizes by default. Example 1 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. Example 2 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. Example 3 The manifest declares <uses-sdk android:minSdkVersion="4"> and does not include a <supports-screens> element. Result: Google Play will show the app to all users, unless other filters apply. For more information on how to declare support for screen sizes in your application, see <supports-screens> and Supporting Multiple Screens.
<uses-configuration>	Device Configuration: keyboard, navigation, touch screen	An application can request certain hardware features, and Google Play will show the app only on devices that have the required hardware. Example 1 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. Example 2 The manifest does not include a <uses-configuration> element. Result: Google Play will show the app to all users, unless other filters apply. For more details, see <uses-configuration>.
<uses-feature>	Device Features	An application can require certain device features to be present on the device. This functionality was introduced in Android 2.0 (API Level 5). Example 1 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. Example 2 The manifest does not include a <uses-feature> element. Result: Google Play will show the app to all users, unless other filters apply. For complete information, see <uses-feature> . Filtering based on implied features: In some cases, Google Play interprets permissions requested through <uses-permission> elements as feature requirements equivalent to those declared in <uses-feature> elements. See <uses-permission>, below.
	OpenGL-ES Version	An application can require that the device support a specific OpenGL-ES version using the <uses-feature android:openGlEsVersion="int"> attribute. Example 1 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. Example 2 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. Example 3 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. Example 4 The manifest does not specify openGlEsVersion. Result: Google Play will show the app to all users, unless other filters apply. For more details, see <uses-feature>.
<uses-library>	Software Libraries	An application can require specific shared libraries to be present on the device. Example 1 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. Example 2 The manifest does not include a <uses-library> element. Result: Google Play will show the app to all users, unless other filters apply. For more details, see <uses-library>.
<uses-permission>		Strictly, Google Play does not filter based on <uses-permission> elements. However, it does read the elements to determine whether the application has hardware feature requirements that may not have been properly declared in <uses-feature> elements. 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.
<uses-sdk>	Minimum Framework Version (minSdkVersion)	An application can require a minimum API level. Example 1 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. Example 2 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.

Advanced manifest filters

In addition to the manifest elements in table 1, Google Play can also filter applications based on the advanced manifest elements in table 2.

These manifest elements and the filtering they trigger are for exceptional use-cases only. These are designed for certain types of high-performance games and similar applications that require strict controls on application distribution. Most applications should never use these filters.

Table 2. Advanced manifest elements for Google Play filtering.

Filter Name	How It Works
<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. Using this element can dramatically reduce the potential user base for your application, by excluding all combinations of screen size and density that you have not listed. You should instead use the <supports-screens> manifest element (described above in table 1) to enable screen compatibility mode for screen configurations you have not accounted for with alternative resources.
<supports-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.

Other Filters

---

Google Play uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below.

Table 3. Application and publishing characteristics that affect filtering on Google Play.

Filter Name	How It Works
Publishing Status	Only published applications will appear in searches and browsing within Google Play. Even if an app is unpublished, it can be installed if users can see it in their Downloads area among their purchased, installed, or recently uninstalled apps. If an application has been suspended, users will not be able to reinstall or update it, even if it appears in their Downloads.
Priced Status	Not all users can see paid apps. To show paid apps, a device must have a SIM card and be running Android 1.1 or later, and it must be in a country (as determined by SIM carrier) in which paid apps are available.
Country Targeting	When you upload your app to Google Play, you can select the countries in which to distribute your app under Pricing and Distribution. The app will then be available to users in only the countries you select.
CPU Architecture (ABI)	An application that includes native libraries that target a specific CPU architecture (ARM EABI v7 or x86, for example) are visible only on devices that support that architecture. For details about the NDK and using native libraries, see What is the Android NDK?
Copy-Protected Applications	Google Play no longer supports the Copy Protection feature in the Developer Console and no longer filters apps based on it. To secure your app, please use Application Licensing instead. See Replacement for Copy Protection for more information.

 

Filtering in Google Play is based on 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.

Google Play filtering is based in part on manifest declarations and other aspects of the Android framework, but actual filtering behaviors are distinct from the framework and are not bound to specific API levels.