1 page.title=Filters on Google Play 2 @jd:body 3 4 <div id="qv-wrapper"> 5 <div id="qv"> 6 7 <h2>Quickview</h2> 8 <ul> 9 <li>Google Play applies filters that control which Android-powered devices can access your 10 application when the user is visiting the store.</li> 11 <li>Filtering is determined by comparing device configurations that you declare in you app's 12 manifest file to the configurations defined by the device, as well as other factors.</li> </ul> 13 14 <h2>In this document</h2> 15 16 <ol> 17 <li><a href="#how-filters-work">How Filters Work on Google Play</a></li> 18 <li><a href="#manifest-filters">Filtering based on Manifest Elements</a> 19 <ol> 20 <li><a href="#advanced-filters">Advanced manifest filters</a></li> 21 </ol> 22 </li> 23 <li><a href="#other-filters">Other Filters</a></li> 24 <li><a href="#MultiApks">Publishing Multiple APKs with Different Filters</a></li> 25 </ol> 26 27 <h2>See also</h2> 28 <ol> 29 <li><a 30 href="{@docRoot}guide/practices/compatibility.html">Android Compatibility</a></li> 31 <li><code><a 32 href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html"><supports-gl-texture></a></code></li> 33 <li><code><a 34 href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code></li> 35 <li><code><a 36 href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code></li> 37 <li><code><a 38 href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a></code></li> 39 <li><code><a 40 href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></li> 41 <li><code><a 42 href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></li> 43 <li><code><a 44 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></code></a></li> 45 </ol> 46 47 <div id="qv-extra"> 48 <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> 49 <div id="qv-sub-rule"> 50 <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0 5px;"> 51 <h2 style="color:#669999;padding-top:1em;">Interested in publishing your app on Google Play?</h2> 52 <p><a id="publish-link" 53 href="http://play.google.com/apps/publish">Go to Google Play</a> to create a publisher 54 account and upload your app.</p></div> 55 </div> 56 57 </div> 58 </div> 59 60 61 <p>When a user searches or browses on Google Play on an Android device, the results are filtered 62 based on which applications are compatible with that device. For example, if an application 63 requires a camera (as specified in the application manifest file), then Google Play will not show 64 the app on any device that does not have a camera.</p> 65 66 <p>Declarations in the manifest file that are compared to the device's configuration is not the 67 only part of how applications are filtered. Filtering might also occur due to the user's country and 68 carrier, the presence or absence of a SIM card, and other factors. </p> 69 70 <p>Changes to the Google Play filters are independent of changes to the Android platform itself. 71 This document is updated periodically to reflect any changes that affect the way Google Play 72 filters applications.</p> 73 74 75 <h2 id="how-filters-work">How Filters Work on Google Play</h2> 76 77 <p>Google Play uses the filter restrictions described below to determine 78 whether to show your application to a user who is browsing or searching for 79 applications from the Google Play app. When determining whether to display your app, 80 Google Play checks the device's hardware and software configuration, as well as it's 81 carrier, location, and other characteristics. It then compares those against the 82 restrictions and dependencies expressed by the application's 83 manifest file and publishing details. If the application is 84 compatible with the device according to the filter rules, Google Play displays the 85 application to the user. Otherwise, Google Play hides your application from search 86 results and category browsing, even if a user specifically requests 87 the app by clicking a deep link that points directly to the app's ID within Google Play..</p> 88 89 <p class="note"><strong>Note:</strong> When users browse the <a 90 href="http://play.google.com/apps">Google Play web site</a>, they can see all published 91 applications. The Google Play web site compares the application requirements to each of the 92 user's registered devices for compatibility, though, and only allows them to install the application 93 if it's compatible with their device.</p> 94 95 <p>You can use any combination of the available filters for your app. For example, you can set a 96 <code>minSdkVersion</code> requirement of <code>"4"</code> and set <code>smallScreens="false"</code> 97 in the app, then when uploading the app to Google Play you could target European countries (carriers) 98 only. Google Play's filters will thus prevent the application from being available on any device 99 that does not match all three of these requirements. </p> 100 101 <p>All filtering restrictions are associated with an application's version and can 102 change between versions. For example, if a user has installed your application and you publish an 103 update that makes the app invisible to the user, the user will not see that an update is 104 available.</p> 105 106 107 <h2 id="manifest-filters">Filtering based on Manifest Elements</h2> 108 109 <p>Most filters are triggered by elements within an application's 110 manifest file, <a 111 href="{@docRoot}guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a> 112 (although not everything in the manifest file can trigger filtering). 113 Table 1 lists the manifest elements that you should use to trigger 114 filtering, and explains how the filtering for each element works.</p> 115 116 <p id="table1" class="table-caption"><strong>Table 1.</strong> Manifest elements that 117 trigger filtering on Google Play.</p> 118 <table> 119 <tr> 120 <th>Manifest Element</th> 121 <th>Filter Name</th> 122 <th>How It Works</th> 123 </tr> 124 <tr> 125 <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code> 126 <!-- ##api level 4## --></td> 127 <td valign="top">Screen Size</td> 128 <td valign="top"> 129 130 <p>An application indicates the screen sizes that it is capable of supporting by 131 setting attributes of the <code><supports-screens></code> element. When 132 the application is published, Google Play uses those attributes to determine whether 133 to show the application to users, based on the screen sizes of their 134 devices. </p> 135 136 <p>As a general rule, Google Play assumes that the platform on the device can adapt 137 smaller layouts to larger screens, but cannot adapt larger layouts to smaller 138 screens. Thus, if an application declares support for "normal" screen size only, 139 Google Play makes the application available to both normal- and large-screen devices, 140 but filters the application so that it is not available to small-screen 141 devices.</p> 142 143 <p>If an application does not declare attributes for 144 <code><supports-screens></code>, Google Play uses the default values for those 145 attributes, which vary by API Level. Specifically: </p> 146 147 <ul> 148 <li><p>For applications that set either the <code><a 149 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">android: 150 minSdkVersion</a></code> or <code><a 151 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">android: 152 targetSdkVersion</a></code> to 3 or lower, the <code><supports-screens></code> element itself 153 is undefined and no attributes are available. In this case, Google Play assumes that 154 the application is designed for normal-size screens and shows the application to 155 devices that have normal or larger screens. </p> 156 157 <li>When the either the <code><a 158 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">android: 159 minSdkVersion</a></code> or <code><a 160 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">android: 161 targetSdkVersion</a></code> is set to 4 or higher, the default for all attributes is 162 <code>"true"</code>. In this way, the application is considered to support all screen sizes by 163 default.</li> 164 </ul> 165 166 <p><strong>Example 1</strong><br /> 167 The manifest declares <code><uses-sdk android:minSdkVersion="3"></code> 168 and does not include a <code><supports-screens></code> element. 169 <strong>Result</strong>: Google Play will not show the app to a user of a 170 small-screen device, but will show it to users of normal and large-screen 171 devices, unless other filters apply. </p> 172 <p><strong>Example 2<br /> 173 </strong>The manifest declares <code><uses-sdk android:minSdkVersion="3" 174 android:targetSdkVersion="4"></code> and does not include a 175 <code><supports-screens></code> element. 176 <strong>Result</strong>: Google Play will show the app to users on all 177 devices, unless other filters apply. </p> 178 <p><strong>Example 3<br /> 179 </strong>The manifest declares <code><uses-sdk android:minSdkVersion="4"></code> 180 and does not include a <code><supports-screens></code> element. 181 <strong>Result</strong>: Google Play will show the app to all users, 182 unless other filters apply. </p> 183 <p>For more information on how to declare support for screen sizes in your 184 application, see <code><a 185 href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code> 186 and <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple 187 Screens</a>.</p> 188 </td> 189 </tr> 190 191 <tr> 192 <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code> 193 <!-- ##api level 3## --></td> 194 <td valign="top">Device 195 Configuration: <br /> 196 keyboard, navigation, touch screen</td> 197 <td valign="top"><p>An application can 198 request certain hardware features, and Google Play will show the app only on devices that have the required hardware.</p> 199 <p><strong>Example 1<br /> 200 </strong>The manifest includes <code><uses-configuration android:reqFiveWayNav="true" /></code>, and a user is searching for apps on a device that does not have a five-way navigational control. <strong>Result</strong>: Google Play will not show the app to the user. </p> 201 <p><strong>Example 2<br /> 202 </strong>The manifest does not include a <code><uses-configuration></code> element. <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply.</p> 203 <p>For more details, see <a 204 href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><code><uses-configuration></code></a>.</p></td> 205 </tr> 206 207 <tr> 208 <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a 209 href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a> 210 </code> 211 <!-- ##api level 4## --></td> 212 <td valign="top">Device Features<br /> 213 (<code>name</code>)</td> 214 <td valign="top"><p>An application can require certain device features to be 215 present on the device. This functionality was introduced in Android 2.0 (API 216 Level 5).</p> 217 <p><strong>Example 1<br /> 218 </strong>The manifest includes <code><uses-feature 219 android:name="android.hardware.sensor.light" /></code>, and a user 220 is searching for apps on a device that does not have a light sensor. 221 <strong>Result</strong>: Google Play will not show the app to the user. </p> 222 <p><strong>Example 2<br /> 223 </strong>The manifest does not include a <code><uses-feature></code> 224 element. <strong>Result</strong>: Google Play will show the app to all users, 225 unless other filters apply.</p> 226 <p>For complete information, see <code><a 227 href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a> 228 </code>.</p> 229 <p><em>Filtering based on implied features:</em> In some cases, Google 230 Play interprets permissions requested through 231 <code><uses-permission></code> elements as feature requirements equivalent 232 to those declared in <code><uses-feature></code> elements. See <a 233 href="#uses-permission-filtering"><code><uses-permission></code></a>, 234 below.</p> 235 </td> 236 </tr> 237 238 <tr> 239 <td valign="top">OpenGL-ES 240 Version<br /> 241 (<code>openGlEsVersion</code>)</td> 242 <td valign="top"><p>An application can require that the device support a specific 243 OpenGL-ES version using the <code><uses-feature 244 android:openGlEsVersion="int"></code> attribute.</p> 245 <p><strong>Example 1<br /> 246 </strong>An app 247 requests multiple OpenGL-ES versions by specifying <code>openGlEsVersion</code> multiple times in the 248 manifest. <strong>Result</strong>: Google Play assumes that the app requires the highest of the indicated versions.</p> 249 <p><strong>Example 2<br /> 250 </strong>An app 251 requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. <strong>Result</strong>: Google Play will show the app to the user, unless other filters apply. If a 252 device reports that it supports OpenGL-ES version <em>X</em>, Google Play assumes that it 253 also supports any version earlier than <em>X</em>. 254 </p> 255 <p><strong>Example 3<br /> 256 </strong>A user is searching for apps on a device that does not 257 report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). <strong>Result</strong>: Google Play assumes that the device 258 supports only OpenGL-ES 1.0. Google Play will only show the user apps that do not specify <code>openGlEsVersion</code>, or apps that do not specify an OpenGL-ES version higher than 1.0. </p> 259 <p><strong>Example 4<br /> 260 </strong>The manifest does not specify <code>openGlEsVersion</code>. <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply. </p> 261 <p>For more details, see <a 262 href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>.</p></td> 263 </tr> 264 265 <tr> 266 <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></td> 267 <td valign="top">Software Libraries</td> 268 <td valign="top"><p>An application can require specific 269 shared libraries to be present on the device. </p> 270 <p><strong>Example 1<br /> 271 </strong>An app requires the <code>com.google.android.maps</code> library, and a user is searching for apps on a device that does not have the <code>com.google.android.maps</code> library. <strong>Result</strong>: Google Play will not show the app to the user. </p> 272 <p><strong>Example 2</strong><br /> 273 The manifest does not include a <code><uses-library></code> element. <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply.</p> 274 <p>For more details, see <a 275 href="{@docRoot}guide/topics/manifest/uses-library-element.html"><code><uses-library></code></a>.</p></td> 276 </tr> 277 <tr id="uses-permission-filtering"> 278 <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></td> 279 <td valign="top"> </td> 280 <td valign="top">Strictly, Google Play does not filter based on 281 <code><uses-permission></code> elements. However, it does read the 282 elements to determine whether the application has hardware feature requirements 283 that may not have been properly declared in <code><uses-feature></code> 284 elements. For example, if an application requests the <code>CAMERA</code> 285 permission but does not declare a <code><uses-feature></code> element for 286 <code>android.hardware.camera</code>, Google Play considers that the 287 application requires a camera and should not be shown to users whose devices do 288 not offer a camera.</p> 289 <p>In general, if an application requests hardware-related permissions, 290 Google Play assumes that the application requires the underlying hardware 291 features, even though there might be no corresponding to 292 <code><uses-feature></code> declarations. Google Play then sets up 293 filtering based on the features implied by the <code><uses-feature></code> 294 declarations.</p> 295 <p>For a list of permissions that imply hardware features, see 296 the documentation for the <a 297 href="{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions-features"><code><uses-feature></code></a> 298 element.</p> 299 </td> 300 </tr> 301 302 <tr> 303 <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a></code></td> 304 <td valign="top">Minimum Framework Version (<code>minSdkVersion</code>)</td> 305 <td valign="top"><p>An application can require a minimum API level. </p> 306 <p><strong>Example 1</strong><br /> 307 The manifest includes <code><uses-sdk 308 android:minSdkVersion="3"></code>, 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. <strong>Result</strong>: Google Play will not show the app to the user. </p> 309 <p><strong>Example 2</strong><br /> 310 The manifest does not include <code>minSdkVersion</code>, 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. <strong>Result</strong>: Google Play assumes that <code>minSdkVersion</code> 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. </p> 311 <p>Because you want to avoid this second scenario, we recommend that you always declare a <code>minSdkVersion</code>. For details, see <a 312 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min"><code>android:minSdkVersion</code></a>.</p></td> 313 </tr> 314 <tr> 315 <td valign="top">Maximum Framework Version (<code>maxSdkVersion</code>)</td> 316 <td valign="top"><p><em>Deprecated.</em> Android 317 2.1 and later do not check or enforce the <code>maxSdkVersion</code> attribute, and 318 the SDK will not compile if <code>maxSdkVersion</code> is set in an app's manifest. For devices already 319 compiled with <code>maxSdkVersion</code>, Google Play will respect it and use it for 320 filtering.</p> 321 <p> Declaring <code>maxSdkVersion</code> is <em>not</em> recommended. For details, see <a 322 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max"><code>android:maxSdkVersion</code></a>.</p></td> 323 </tr> 324 </table> 325 326 327 328 <h3 id="advanced-filters">Advanced manifest filters</h3> 329 330 <p>In addition to the manifest elements in <a href="#table1">table 1</a>, Google Play can also 331 filter applications based on the advanced manifest elements in table 2.</p> 332 333 <p>These manifest elements and the filtering they trigger are for exceptional use-cases 334 only. These are designed for certain types of high-performance games and similar applications that 335 require strict controls on application distribution. <strong>Most applications should never use 336 these filters</strong>.</p> 337 338 <p id="table2" class="table-caption"><strong>Table 2.</strong> Advanced manifest elements for 339 Google Play filtering.</p> 340 <table> 341 <tr><th>Manifest Element</th><th>Summary</th></tr> 342 <tr> 343 <td><nobr><a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code 344 <compatible-screens>}</a></nobr></td> 345 <td> 346 <p>Google Play filters the application if the device screen size and density does not match 347 any of the screen configurations (declared by a {@code <screen>} element) in the {@code 348 <compatible-screens>} element.</p> 349 <p class="caution"><strong>Caution:</strong> Normally, <strong>you should not use 350 this manifest element</strong>. Using this element can dramatically 351 reduce the potential user base for your application, by excluding all combinations of screen size 352 and density that you have not listed. You should instead use the <a 353 href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code 354 <supports-screens>}</a> manifest element (described above in <a href="#table1">table 355 1</a>) to enable screen compatibility mode for screen configurations you have not accounted for 356 with alternative resources.</p> 357 </td> 358 </tr> 359 <tr> 360 <td><nobr><a href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html">{@code 361 <supports-gl-texture>}</a></nobr></td> 362 <td> 363 <p>Google Play filters the application unless one or more of the GL texture compression 364 formats supported by the application are also supported by the device. </p> 365 </td> 366 </tr> 367 </table> 368 369 370 371 <h2 id="other-filters">Other Filters</h2> 372 373 <p>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. </p> 374 375 <p id="table3" class="table-caption"><strong>Table 3.</strong> Application and publishing 376 characteristics that affect filtering on Google Play.</p> 377 <table> <tr> 378 <th>Filter Name</th> <th>How It Works</th> </tr> 379 380 <tr> 381 <td valign="top">Publishing Status</td> <td valign="top"><p>Only published applications will appear in 382 searches and browsing within Google Play.</p> <p>Even if an app is unpublished, it can 383 be installed if users can see it in their Downloads area among their purchased, 384 installed, or recently uninstalled apps.</p> <p>If an application has been 385 suspended, users will not be able to reinstall or update it, even if it appears in their Downloads.</p> </td></tr> 386 <tr> 387 <td valign="top">Priced 388 Status</td> <td valign="top"><p>Not all users can see paid apps. To show paid apps, a device 389 must have a SIM card and be running Android 1.1 or later, and it must be in a 390 country (as determined by SIM carrier) in which paid apps are available.</p></td> 391 </tr> <tr> 392 <td valign="top">Country / Carrier Targeting</td> <td valign="top"> <p>When you upload your app to 393 Google Play, you can select specific countries to target. The app will only 394 be visible to the countries (carriers) that you select, as follows:</p> 395 <ul><li><p>A device's country is determined based on the carrier, if a carrier is 396 available. If no carrier can be determined, Google Play tries to 397 determine the country based on IP.</p></li> <li><p>Carrier is determined based on 398 the device's SIM (for GSM devices), not the current roaming carrier.</p></li></ul> 399 </td> </tr> <tr> 400 <td valign="top">Native Platform</td> <td valign="top"><p>An application that includes native 401 libraries that target a specific platform (ARM EABI v7 or x86, for example) are 402 visible only on devices that support that platform. For details about the NDK and using 403 native libraries, see <a href="{@docRoot}tools/sdk/ndk/index.html#overview">What is the 404 Android NDK?</a></p> </tr> <tr> 405 <td valign="top">Copy-Protected Applications</td> <td valign="top"><p>To 406 copy protect an application, set copy protection to "On" when you configure publishing 407 options for your application. Google Play will not show copy-protected applications on 408 developer devices or unreleased devices.</p></td> </tr> </table> 409 410 411 412 <h2 id="MultiApks">Publishing Multiple APKs with Different Filters</h2> 413 414 <p>Some specific Google Play filters allow you to publish multiple APKs for the same 415 application in order to provide a different APK to different device configurations. For example, if 416 you're creating a video game that uses high-fidelity graphic assets, you might want to create 417 two APKs that each support different texture compression formats. This way, you can reduce the 418 size of the APK file by including only the textures that are required for each device 419 configuration. Depending on each device's support for your texture compression formats, Google 420 Play will deliver it the APK that you've declared to support that device.</p> 421 422 <p>Currently, Google Play allows you to publish multiple APKs for the same application only 423 when each APK provides different filters based on the following configurations:</p> 424 <ul> 425 <li>OpenGL texture compression formats 426 <p>By using the <a 427 href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html">{@code 428 <supports-gl-texture>}</a> element.</p> 429 </li> 430 <li>Screen size (and, optionally, screen density) 431 <p>By using the <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code 432 <supports-screens>}</a> or <a 433 href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code 434 <compatible-screens>}</a> element.</p> 435 </li> 436 <li>API level 437 <p>By using the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code 438 <uses-sdk>}</a> element.</p> 439 </li> 440 </ul> 441 442 <p>All other filters still work the same as usual, but these three are the only filters that can 443 distinguish one APK from another within the same application listing on Google Play. For example, 444 you <em>cannot</em> publish multiple APKs for the same application if the APKs differ only based on 445 whether the device has a camera.</p> 446 447 <p class="caution"><strong>Caution:</strong> Publishing multiple APKs for the same application is 448 considered an advanced feature and <strong>most application should publish only one 449 APK that supports a wide range of device configurations</strong>. Publishing multiple APKs 450 requires that you follow specific rules within your filters and that you pay extra attention to the 451 version codes for each APK to ensure proper update paths for each configuration.</p> 452 453 <p>If you need more information about how to publish multiple APKs on Google Play, read <a 454 href="{@docRoot}guide/google/play/publishing/multiple-apks.html">Multiple APK Support</a>.</p> 455