1 page.title=<uses-feature> 2 page.tags="filtering","features","google play filters","permissions" 3 @jd:body 4 5 <div id="qv-wrapper"> 6 <div id="qv"> 7 8 9 <h2>In this document</h2> 10 <ol> 11 <li><a href="#market-feature-filtering">Google Play and Feature-Based Filtering</a> 12 <ol> 13 <li><a href="#declared">Filtering based on explicitly declared features</a></li> 14 <li><a href="#implicit">Filtering based on implicit features</a></li> 15 <li><a href="#bt-permission-handling">Special handling for Bluetooth feature</a></li> 16 <li><a href="#testing">Testing the features required by your application</a></li> 17 </ol> 18 </li> 19 <li><a href="#features-reference">Features Reference</a> 20 <ol> 21 <li><a href="#hw-features">Hardware features</a></li> 22 <li><a href="#sw-features">Software features</a></li> 23 <li><a href="#permissions">Permissions that Imply Feature Requirements</a></li> 24 </ol> 25 </li> 26 </ol> 27 </div> 28 </div> 29 30 <div class="sidebox-wrapper"> 31 <div class="sidebox"> 32 <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> 33 <p style="color:#669999;padding-top:1em;">Google Play Filtering</p> 34 <p style="padding-top:1em;">Google Play uses the <code><uses-feature></code> 35 elements declared in your app manifest to filter your app from devices 36 that do not meet it's hardware and software feature requirements. </p> 37 38 <p style="margin-top:1em;">By specifying the features that your application requires, 39 you enable Google Play to present your application only to users whose 40 devices meet the application's feature requirements, rather than presenting it 41 to all users. </p> 42 43 <p>For important information about how 44 Google Play uses features as the basis for filtering, please read <a 45 href="#market-feature-filtering">Google Play and Feature-Based Filtering</a>, 46 below.</p> 47 </div> 48 </div> 49 50 <dl class="xml"> 51 52 <dt>syntax:</dt> 53 <dd> 54 <pre class="stx"><uses-feature 55 android:<a href="#name">name</a>="<em>string</em>" 56 android:<a href="#required">required</a>=["true" | "false"] 57 android:<a href="#glEsVersion">glEsVersion</a>="<em>integer</em>" /></pre> 58 </dd> 59 60 <dt>contained in:</dt> 61 <dd><code><a 62 href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a></code></dd> 63 64 <dt>description:</dt> 65 <dd>Declares a single hardware or software feature that is used by the 66 application. 67 68 <p>The purpose of a <code><uses-feature></code> declaration is to inform 69 any external entity of the set of hardware and software features on which your 70 application depends. The element offers a <code>required</code> attribute that 71 lets you specify whether your application requires and cannot function without 72 the declared feature, or whether it prefers to have the feature but can function 73 without it. Because feature support can vary across Android devices, the 74 <code><uses-feature></code> element serves an important role in letting an 75 application describe the device-variable features that it uses.</p> 76 77 <p>The set of available features that your application declares corresponds to 78 the set of feature constants made available by the Android {@link 79 android.content.pm.PackageManager}, which are listed for 80 convenience in the <a href="#features-reference">Features Reference</a> tables 81 at the bottom of this document. 82 83 <p>You must specify each feature in a separate <code><uses-feature></code> 84 element, so if your application requires multiple features, it would declare 85 multiple <code><uses-feature></code> elements. For example, an application 86 that requires both Bluetooth and camera features in the device would declare 87 these two elements:</p> 88 89 <pre> 90 <uses-feature android:name="android.hardware.bluetooth" /> 91 <uses-feature android:name="android.hardware.camera" /> 92 </pre> 93 94 <p>In general, you should always make sure to declare 95 <code><uses-feature></code> elements for all of the features that your 96 application requires.</p> 97 98 <p>Declared <code><uses-feature></code> elements are informational only, meaning 99 that the Android system itself does not check for matching feature support on 100 the device before installing an application. However, other services 101 (such as Google Play) or applications may check your application's 102 <code><uses-feature></code> declarations as part of handling or interacting 103 with your application. For this reason, it's very important that you declare all of 104 the features (from the list below) that your application uses. </p> 105 106 <p>For some features, there may exist a specific attribute that allows you to define 107 a version of the feature, such as the version of Open GL used (declared with 108 <a href="#glEsVersion"><code>glEsVersion</code></a>). Other features that either do or do not 109 exist for a device, such as a camera, are declared using the 110 <a href="#name"><code>name</code></a> attribute.</p> 111 112 113 <p>Although the <code><uses-feature></code> element is only activated for 114 devices running API Level 4 or higher, it is recommended to include these 115 elements for all applications, even if the <a href="uses-sdk-element.html#min"><code>minSdkVersion</code></a> 116 is "3" or lower. Devices running older versions of the platform will simply 117 ignore the element.</p> 118 119 <p class="note"><strong>Note:</strong> When declaring a feature, remember 120 that you must also request permissions as appropriate. For example, you must 121 still request the {@link android.Manifest.permission#CAMERA} 122 permission before your application can access the camera API. Requesting the 123 permission grants your application access to the appropriate hardware and 124 software, while declaring the features used by your application ensures proper 125 device compatibility.</p> 126 127 </dd> 128 129 130 <dt>attributes:</dt> 131 132 <dd> 133 <dl class="attr"> 134 135 <dt><a name="name"></a><code>android:name</code></dt> 136 <dd>Specifies a single hardware or software feature used by the application, 137 as a descriptor string. Valid descriptor values are listed in the <a 138 href="#hw-features">Hardware features</a> and <a href="#sw-features">Software 139 features</a> tables, below. </dd> 140 141 <dt><a name="required"></a><code>android:required</code></dt> <!-- added in api level 5 --> 142 <dd>Boolean value that indicates whether the application requires 143 the feature specified in <code>android:name</code>. 144 145 <ul> 146 <li>When you declare <code>"android:required="true"</code> for a feature, 147 you are specifying that the application <em>cannot function, or is not 148 designed to function</em>, when the specified feature is not present on the 149 device. </li> 150 151 <li>When you declare <code>"android:required="false"</code> for a feature, it 152 means that the application <em>prefers to use the feature</em> if present on 153 the device, but that it <em>is designed to function without the specified 154 feature</em>, if necessary. </li> 155 156 </ul> 157 158 <p>The default value for <code>android:required</code> if not declared is 159 <code>"true"</code>.</p> 160 </dd> 161 162 <dt><a name="glEsVersion"></a><code>android:glEsVersion</code></dt> 163 <dd>The OpenGL ES version required by the application. The higher 16 bits 164 represent the major number and the lower 16 bits represent the minor number. For 165 example, to specify OpenGL ES version 2.0, you would set the value as 166 "0x00020000". To specify OpenGL ES 2.1, if/when such a version were made 167 available, you would set the value as "0x00020001". 168 169 <p>An application should specify at most one <code>android:glEsVersion</code> 170 attribute in its manifest. If it specifies more than one, the 171 <code>android:glEsVersion</code> with the numerically highest value is used and 172 any other values are ignored.</p> 173 174 <p>If an application does not specify an <code>android:glEsVersion</code> 175 attribute, then it is assumed that the application requires only OpenGL ES 1.0, 176 which is supported by all Android-powered devices.</p> 177 178 <p>An application can assume that if a platform supports a given OpenGL ES 179 version, it also supports all numerically lower OpenGL ES versions. Therefore, 180 an application that requires both OpenGL ES 1.0 and OpenGL ES 2.0 must specify 181 that it requires OpenGL ES 2.0.</p> 182 183 <p>An application that can work with any of several OpenGL ES versions should 184 only specify the numerically lowest version of OpenGL ES that it requires. (It 185 can check at run-time whether a higher level of OpenGL ES is available.)</p> 186 </dd> 187 188 </dl> 189 </dd> 190 191 <!-- ##api level indication## --> 192 <dt>introduced in:</dt> 193 <dd>API Level 4</dd> 194 195 <dt>see also:</dt> 196 <dd> 197 <ul> 198 <li>{@link android.content.pm.PackageManager}</li> 199 <li>{@link android.content.pm.FeatureInfo}</li> 200 <li>{@link android.content.pm.ConfigurationInfo}</li> 201 <li><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><code><uses-permission></code></a></li> 202 <li><a href="{@docRoot}google/play/filters.html">Filters on Google Play</a></li> 203 </ul> 204 </dd> 205 206 </dl> 207 208 209 <h2 id="market-feature-filtering">Google Play and Feature-Based Filtering</h2> 210 211 <p>Google Play filters the applications that are visible to users, so that 212 users can see and download only those applications that are compatible with 213 their devices. One of the ways it filters applications is by feature 214 compatibility.</p> 215 216 <p>To determine an application's feature compatibility with a given user's 217 device, Google Play compares:</p> 218 219 <ul> 220 <li>Features required by the application — an application declares features in 221 <code><uses-feature></code> elements in its manifest <br/>with...</li> 222 <li>Features available on the device, in hardware or software — 223 a device reports the features it supports as read-only system properties.</li> 224 </ul> 225 226 <p>To ensure an accurate comparison of features, the Android Package Manager 227 provides a shared set of feature constants that both applications and devices 228 use to declare feature requirements and support. The available feature constants 229 are listed in the <a href="#features-reference">Features Reference</a> tables at 230 the bottom of this document, and in the class documentation for {@link 231 android.content.pm.PackageManager}.</p> 232 233 <p>When the user launches Google Play, the application queries the 234 Package Manager for the list of features available on the device by calling 235 {@link android.content.pm.PackageManager#getSystemAvailableFeatures()}. The 236 Store application then passes the features list up to Google Play 237 when establishing the session for the user.</p> 238 239 <p>Each time you upload an application to the Google Play Developer Console, 240 Google Play scans the application's manifest file. It looks for 241 <code><uses-feature></code> elements and evaluates them in combination 242 with other elements, in some cases, such as <code><uses-sdk></code> and 243 <code><uses-permission></code> elements. After establishing the 244 application's set of required features, it stores that list internally as 245 metadata associated with the application <code>.apk</code> and the application 246 version. </p> 247 248 <p>When a user searches or browses for applications using the Google Play 249 application, the service compares the features needed by each application with 250 the features available on the user's device. If all of an application's required 251 features are present on the device, Google Play allows the user to see the 252 application and potentially download it. If any required feature is not 253 supported by the device, Google Play filters the application so that it is 254 not visible to the user and not available for download. </p> 255 256 <p>Because the features you declare in <code><uses-feature></code> 257 elements directly affect how Google Play filters your application, it's 258 important to understand how Google Play evaluates the application's manifest 259 and establishes the set of required features. The sections below provide more 260 information. </p> 261 262 <h3 id="declared">Filtering based on explicitly declared features</h3> 263 264 <p>An explicitly declared feature is one that your application declares in a 265 <code><uses-feature></code> element. The feature declaration can include 266 an <code>android:required=["true" | "false"]</code> attribute (if you are 267 compiling against API level 5 or higher), which lets you specify whether the 268 application absolutely requires the feature and cannot function properly without 269 it (<code>"true"</code>), or whether the application prefers to use the feature 270 if available, but is designed to run without it (<code>"false"</code>).</p> 271 272 <p>Google Play handles explicitly declared features in this way: </p> 273 274 <ul> 275 <li>If a feature is explicitly declared as being required, Google Play adds 276 the feature to the list of required features for the application. It then 277 filters the application from users on devices that do not provide that feature. 278 For example: 279 <pre><uses-feature android:name="android.hardware.camera" android:required="true" /></pre></li> 280 <li>If a feature is explicitly declared as <em>not</em> being required, Google 281 Play <em>does not</em> add the feature to the list of required features. For 282 that reason, an explicitly declared non-required feature is never considered when 283 filtering the application. Even if the device does not provide the declared 284 feature, Google Play will still consider the application compatible with the 285 device and will show it to the user, unless other filtering rules apply. For 286 example: 287 <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre></li> 288 <li>If a feature is explicitly declared, but without an 289 <code>android:required</code> attribute, Google Play assumes that the feature 290 is required and sets up filtering on it. </li> 291 </ul> 292 293 <p>In general, if your application is designed to run on Android 1.6 and earlier 294 versions, the <code>android:required</code> attribute is not available in the 295 API and Google Play assumes that any and all 296 <code><uses-feature></code> declarations are required. </p> 297 298 <p class="note"><strong>Note:</strong> By declaring a feature explicitly and 299 including an <code>android:required="false"</code> attribute, you can 300 effectively disable all filtering on Google Play for the specified feature. 301 </p> 302 303 304 <h3 id="implicit">Filtering based on implicit features</h3> 305 306 <p>An <em>implicit</em> feature is one that an application requires in order to 307 function properly, but which is <em>not</em> declared in a 308 <code><uses-feature></code> element in the manifest file. Strictly 309 speaking, every application should <em>always</em> declare all features that it 310 uses or requires, so the absence of a declaration for a feature used by an 311 application should be considered an error. However, as a safeguard for users and 312 developers, Google Play looks for implicit features in each application and 313 sets up filters for those features, just as it would do for an explicitly 314 declared feature. </p> 315 316 <p>An application might require a feature but not declare it because: </p> 317 318 <ul> 319 <li>The application was compiled against an older version of the Android library 320 (Android 1.5 or earlier) and the <code><uses-feature></code> element was 321 not available.</li> 322 <li>The developer incorrectly assumed that the feature would be present on all 323 devices and a declaration was unnecessary.</li> 324 <li>The developer omitted the feature declaration accidentally.</li> 325 <li>The developer declared the feature explicitly, but the declaration was not 326 valid. For example, a spelling error in the <code><uses-feature></code> 327 element name or an unrecognized string value for the 328 <code>android:name</code> attribute would invalidate the feature declaration. 329 </li> 330 </ul> 331 332 <p>To account for the cases above, Google Play attempts to discover an 333 application's implied feature requirements by examining <em>other elements</em> 334 declared in the manifest file, specifically, 335 <code><uses-permission></code> elements.</p> 336 337 <p>If an application requests hardware-related permissions, Google Play 338 <em>assumes that the application uses the underlying hardware features and 339 therefore requires those features</em>, even though there might be no 340 corresponding to <code><uses-feature></code> declarations. For such 341 permissions, Google Play adds the underlying hardware features to the 342 metadata that it stores for the application and sets up filters for them.</p> 343 344 <p>For example, if an application requests the <code>CAMERA</code> permission 345 but does not declare a <code><uses-feature></code> element for 346 <code>android.hardware.camera</code>, Google Play considers that the 347 application requires a camera and should not be shown to users whose devices do 348 not offer a camera.</p> 349 350 <p>If you don't want Google Play to filter based on a specific implied 351 feature, you can disable that behavior. To do so, declare the feature explicitly 352 in a <code><uses-feature></code> element and include an 353 <code>android:required="false"</code> attribute. For example, to disable 354 filtering derived from the <code>CAMERA</code> permission, you would declare 355 the feature as shown below.</p> 356 357 <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre> 358 359 <p class="caution">It's important to understand that the permissions that you 360 request in <code><uses-permission></code> elements can directly affect how 361 Google Play filters your application. The reference section <a 362 href="#permissions">Permissions that Imply Feature Requirements</a>, 363 below, lists the full set of permissions that imply feature requirements and 364 therefore trigger filtering.</p> 365 366 <h3 id="bt-permission-handling">Special handling for Bluetooth feature</h3> 367 368 <p>Google Play applies slightly different rules than described above, when 369 determining filtering for Bluetooth.</p> 370 371 <p>If an application declares a Bluetooth permission in a 372 <code><uses-permission></code> element, but does not explicitly declare 373 the Bluetooth feature in a <code><uses-feature></code> element, Google 374 Play checks the version(s) of the Android platform on which the application is 375 designed to run, as specified in the <code><uses-sdk></code> element. </p> 376 377 <p>As shown in the table below, Google Play enables filtering for the 378 Bluetooth feature only if the application declares its lowest or targeted 379 platform as Android 2.0 (API level 5) or higher. However, note that Google 380 Play applies the normal rules for filtering when the application explicitly 381 declares the Bluetooth feature in a <code><uses-feature></code> element. 382 </p> 383 384 <p class="caption"><strong>Table 1.</strong> How Google Play determines the 385 Bluetooth feature requirement for an application that requests a Bluetooth 386 permission but does not declare the Bluetooth feature in a 387 <code><uses-feature></code> element.</p> 388 389 <table style="margin-top:1em;"> 390 <tr> 391 <th><nobr>If <code>minSdkVersion</code> is ...</nobr></th> 392 <th><nobr>or <code>targetSdkVersion</code> is</nobr></th> 393 <th>Result</th> 394 </tr> 395 <tr> 396 <td><nobr><=4 (or uses-sdk is not declared)</nobr></td> 397 <td><=4</td> 398 <td>Google Play <em>will not</em> filter the application from any devices 399 based on their reported support for the <code>android.hardware.bluetooth</code> 400 feature.</td> 401 </tr> 402 <tr> 403 <td><=4</td> 404 <td>>=5</td> 405 <td rowspan="2">Google Play filters the application from any devices that 406 do not support the <code>android.hardware.bluetooth</code> feature (including 407 older releases).</td> 408 </tr> 409 <tr> 410 <td>>=5</td> 411 <td>>=5</td> 412 </tr> 413 </table> 414 415 <p>The examples below illustrate the different filtering effects, based on how 416 Google Play handles the Bluetooth feature. </p> 417 418 <dl> 419 <dt>In first example, an application that is designed to run on older API levels 420 declares a Bluetooth permission, but does not declare the Bluetooth feature in a 421 <code><uses-feature></code> element.</dt> 422 <dd><em>Result:</em> Google Play does not filter the application from any device.</dd> 423 </dl> 424 425 <pre><manifest ...> 426 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> 427 <uses-sdk android:minSdkVersion="3" /> 428 ... 429 </manifest></pre> 430 431 <dl> 432 <dt>In the second example, below, the same application also declares a target 433 API level of "5". </dt> 434 <dd><em>Result:</em> Google Play now assumes that the feature is required and 435 will filter the application from all devices that do not report Bluetooth support, 436 including devices running older versions of the platform. </dd> 437 </dl> 438 439 <pre><manifest ...> 440 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> 441 <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> 442 ... 443 </manifest></pre> 444 445 <dl> 446 <dt>Here the same application now specifically declares the Bluetooth feature.</dt> 447 <dd><em>Result:</em> Identical to the previous example (filtering is applied).</dd> 448 </dl> 449 450 <pre><manifest ...> 451 <uses-feature android:name="android.hardware.bluetooth" /> 452 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> 453 <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> 454 ... 455 </manifest></pre> 456 457 <dl> 458 <dt>Finally, in the case below, the same application adds an 459 <code>android:required="false"</code> attribute.</dt> 460 <dd><em>Result:</em> Google Play disables filtering based on Bluetooth 461 feature support, for all devices.</dd> 462 </dl> 463 464 <pre><manifest ...> 465 <uses-feature android:name="android.hardware.bluetooth" android:required="false" /> 466 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> 467 <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> 468 ... 469 </manifest></pre> 470 471 472 473 <h3 id="testing">Testing the features required by your application</h3> 474 475 <p>You can use the <code>aapt</code> tool, included in the Android SDK, to 476 determine how Google Play will filter your application, based on its declared 477 features and permissions. To do so, run <code>aapt</code> with the <code>dump 478 badging</code> command. This causes <code>aapt</code> to parse your 479 application's manifest and apply the same rules as used by Google Play to 480 determine the features that your application requires. </p> 481 482 <p>To use the tool, follow these steps: </p> 483 484 <ol> 485 <li>First, build and export your application as an unsigned <code>.apk</code>. 486 If you are developing in Eclipse with ADT, right-click the project and select 487 <strong>Android Tools</strong> > <strong>Export Unsigned Application 488 Package</strong>. Select a destination filename and path and click 489 <strong>OK</strong>. </li> 490 <li>Next, locate the <code>aapt</code> tool, if it is not already in your PATH. 491 If you are using SDK Tools r8 or higher, you can find <code>aapt</code> in the 492 <code><<em>SDK</em>>/platform-tools/</code> directory. 493 <p class="note"><strong>Note:</strong> You must use the version of 494 <code>aapt</code> that is provided for the latest Platform-Tools component available. If 495 you do not have the latest Platform-Tools component, download it using the <a 496 href="{@docRoot}sdk/exploring.html">Android SDK Manager</a>. 497 </p></li> 498 <li>Run <code>aapt</code> using this syntax: </li> 499 </ol> 500 501 <pre>$ aapt dump badging <<em>path_to_exported_.apk</em>></pre> 502 503 <p>Here's an example of the command output for the second Bluetooth example, above: </p> 504 505 <pre>$ ./aapt dump badging BTExample.apk 506 package: name='com.example.android.btexample' versionCode='' versionName='' 507 <strong>uses-permission:'android.permission.BLUETOOTH_ADMIN'</strong> 508 <strong>uses-feature:'android.hardware.bluetooth'</strong> 509 sdkVersion:'3' 510 targetSdkVersion:'5' 511 application: label='BT Example' icon='res/drawable/app_bt_ex.png' 512 launchable activity name='com.example.android.btexample.MyActivity'label='' icon='' 513 uses-feature:'android.hardware.touchscreen' 514 main 515 supports-screens: 'small' 'normal' 'large' 516 locales: '--_--' 517 densities: '160' 518 </pre> 519 520 521 <h2 id=features-reference>Features Reference</h2> 522 523 <p>The tables below provide reference information about hardware and software 524 features and the permissions that can imply them on Google Play. </p> 525 526 <h3 id="hw-features">Hardware features</h3> 527 528 <p>The table below describes the hardware feature descriptors supported by the 529 most current platform release. To signal that your application uses or requires 530 a hardware feature, declare each value in a <code>android:name</code> attribute 531 in a separate <code><uses-feature></code> element. </p> 532 533 <table> 534 <tr> 535 <th>Feature Type</th> 536 <th>Feature Descriptor</th> 537 <th style="min-width:170px">Description</th> 538 <th>Comments</th> 539 </tr> 540 <tr> 541 <td>Audio</td> 542 <td><code>android.hardware.audio.low_latency</td> 543 <td>The application uses a low-latency audio pipeline on the device and 544 is sensitive to delays or lag in sound input or output.</td> 545 <td> 546 </td> 547 </tr> 548 <tr> 549 <td>Bluetooth</td> 550 <td><code>android.hardware.bluetooth</td> 551 <td>The application uses Bluetooth radio features in the device.</td> 552 <td> 553 </td> 554 </tr> 555 <tr> 556 <td rowspan="5">Camera</td> 557 <td><code>android.hardware.camera</code></td> 558 <td>The application uses the device's camera. If the device supports 559 multiple cameras, the application uses the camera that facing 560 away from the screen.</td> 561 <td></td> 562 </tr> 563 <tr> 564 <td><code>android.hardware.camera.autofocus</code></td> 565 <td>Subfeature. The application uses the device camera's autofocus capability.</td> 566 <td rowspan="3">These subfeatures implicitly declare the 567 <code>android.hardware.camera</code> parent feature, unless declared with 568 <code>android:required="false"</code>.</td> 569 </tr> 570 <tr> 571 <td><code>android.hardware.camera.flash</code></td> 572 <td>Subfeature. The application uses the device camera's flash.</td> 573 </tr> 574 <tr> 575 <td><code>android.hardware.camera.front</code></td> 576 <td>Subfeature. The application uses a front-facing camera on the device.</td> 577 </tr> 578 <tr> 579 <td><code>android.hardware.camera.any</code></td> 580 <td>The application uses at least one camera facing in any direction. Use this 581 in preference to <code>android.hardware.camera</code> if a back-facing camera is 582 not required.</td> 583 </tr> 584 585 <tr> 586 <td rowspan="3">Location</td> 587 <td><code>android.hardware.location</code></td> 588 <td>The application uses one or more features on the device for determining 589 location, such as GPS location, network location, or cell location.</td> 590 <td></td> 591 </tr> 592 <tr> 593 <td><code>android.hardware.location.network</code></td> 594 <td>Subfeature. The application uses coarse location coordinates obtained from 595 a network-based geolocation system supported on the device.</td> 596 <td rowspan="2">These subfeatures implicitly declare the 597 <code>android.hardware.location</code> parent feature, unless declared with 598 <code>android:required="false"</code>. </td> 599 </tr> 600 <tr> 601 <td><code>android.hardware.location.gps</code></td> 602 <td>Subfeature. The application uses precise location coordinates obtained 603 from a Global Positioning System receiver on the device. </td> 604 </tr> 605 <tr> 606 <td>Microphone</td> 607 <td><code>android.hardware.microphone</code></td> 608 <td>The application uses a microphone on the device. 609 </td> 610 <td></td> 611 </tr> 612 <tr> 613 <td>NFC</td> 614 <td><code>android.hardware.nfc</td> 615 <td>The application uses Near Field Communications radio features in the device.</td> 616 <td></td> 617 </tr> 618 <tr> 619 <td rowspan="6">Sensors</td> 620 <td><code>android.hardware.sensor.accelerometer</code></td> 621 <td>The application uses motion readings from an accelerometer on the 622 device.</td> 623 <td></td> 624 </tr> 625 <tr> 626 <td><code>android.hardware.sensor.barometer</code></td> 627 <td>The application uses the device's barometer.</td> 628 <td></td> 629 </tr> 630 <tr> 631 <td><code>android.hardware.sensor.compass</code></td> 632 <td>The application uses directional readings from a magnetometer (compass) on 633 the device.</td> 634 <td></td> 635 </tr> 636 <tr> 637 <td><code>android.hardware.sensor.gyroscope</code></td> 638 <td>The application uses the device's gyroscope sensor.</td> 639 <td></td> 640 </tr> 641 <tr> 642 <td><code>android.hardware.sensor.light</code></td> 643 <td>The application uses the device's light sensor.</td> 644 <td></td> 645 </tr> 646 <tr> 647 <td><code>android.hardware.sensor.proximity</code></td> 648 <td>The application uses the device's proximity sensor.</td> 649 <td></td> 650 </tr> 651 652 <tr> 653 <td rowspan="2">Screen</td> 654 <td><code>android.hardware.screen.landscape</code></td> 655 <td>The application requires landscape orientation.</td> 656 <td rowspan="2"> 657 <p>For example, if your app requires portrait orientation, you should declare 658 <code><uses-feature android:name="android.hardware.screen.portrait"/></code> so that only devices 659 that support portrait orientation (whether always or by user choice) can install your app. If your 660 application <em>supports</em> both orientations, then you don't need to declare either.</p> 661 <p>Both orientations are assumed <em>not required</em>, by default, so your app may be installed 662 on devices that support one or both orientations. However, if any of your activities request that 663 they run in a specific orientation, using the <a 664 href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code 665 android:screenOrientation}</a> attribute, then this also declares that the application requires that 666 orientation. For example, if you declare <a 667 href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code 668 android:screenOrientation}</a> with either {@code "landscape"}, {@code "reverseLandscape"}, or 669 {@code "sensorLandscape"}, then your application will be available only to devices that support 670 landscape orientation. As a best practice, you should still declare your requirement for this 671 orientation using a {@code <uses-feature>} element. If you declare an orientation for your 672 activity using <a href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code 673 android:screenOrientation}</a>, but don't actually <em>require</em> it, you can disable the 674 requirement by declaring the orientation with a {@code <uses-feature>} element and include 675 {@code android:required="false"}.</p> 676 <p>For backwards compatibility, any device running a platform version that supports only API 677 level 12 or lower is assumed to support both landscape and portrait.</p> 678 </td> 679 </tr> 680 <tr> 681 <td><code>android.hardware.screen.portrait</code></td> 682 <td>The application requires portrait orientation.</td> 683 </tr> 684 685 <tr> 686 <td rowspan="3">Telephony</td> 687 <td><code>android.hardware.telephony</code></td> 688 <td>The application uses telephony features on the device, such as telephony 689 radio with data communication services.</td> 690 <td></td> 691 </tr> 692 <tr> 693 <td><code>android.hardware.telephony.cdma</code></td> 694 <td>Subfeature. The application uses CDMA telephony radio features on the 695 device. </td> 696 <td rowspan="2">These subfeatures implicitly declare the 697 <code>android.hardware.telephony</code> parent feature, unless declared with 698 <code>android:required="false"</code>. </td> 699 </tr> 700 <tr> 701 <td><code>android.hardware.telephony.gsm</code></td> 702 <td>Subfeature. The application uses GSM telephony radio features on the 703 device.</td> 704 </tr> 705 706 <tr> 707 <td>Television</td> 708 <td><code>android.hardware.type.television</code></td> 709 <td>The application is designed for a television user experience.</td> 710 <td>This feature defines "television" to be a typical living room television experience: 711 displayed on a big screen, where the user is sitting far away and the dominant form of 712 input is something like a d-pad, and generally not through touch or a 713 mouse/pointer-device.</td> 714 </tr> 715 716 <tr> 717 <td rowspan="7">Touchscreen</td> 718 <td><code>android.hardware.faketouch</code></td> 719 <td>The application uses basic touch interaction events, such as "click down", "click 720 up", and drag.</td> 721 <td><p>When declared as required, this indicates that the application is compatible with a device 722 only if it offers an emulated touchscreen ("fake touch" interface), or better. A device that offers 723 a fake touch interface provides a user input system that emulates a subset of touchscreen 724 capabilities. For example, a mouse or remote control that drives an on-screen cursor provides a fake 725 touch interface. If your application requires basic point and click interaction (in other 726 words, it won't work with <em>only</em> a d-pad controller), you should declare this feature. 727 Because this is the minimum level of touch interaction, your app will also be compatible with 728 devices that offer more complex touch interfaces.</p> 729 <p class="note"><strong>Note:</strong> Because applications require the {@code 730 android.hardware.touchscreen} feature by default, if you want your application to be available to 731 devices that provide a fake touch interface, you must also explicitly declare that a touch screen is 732 <em>not</em> required by declaring {@code <uses-feature 733 android:name="android.hardware.touchscreen" <strong>android:required="false"</strong> 734 />}</p></td> 735 </tr> 736 737 <tr> 738 <td><code>android.hardware.faketouch.multitouch.distinct</code></td> 739 <td>The application performs distinct tracking of two or more "fingers" on a fake touch 740 interface. This is a superset of the faketouch feature.</td> 741 <td><p>When declared as required, this indicates that the application is compatible with a device 742 only if it supports touch emulation for events that supports distinct tracking of two or more 743 fingers, or better.</p> 744 <p>Unlike the distinct multitouch defined by {@code 745 android.hardware.touchscreen.multitouch.distinct}, input devices that support distinct multi-touch 746 with a fake touch interface will not support all two-finger gestures, because the input is 747 being transformed to cursor movement on the screen. That is, single finger gestures on such a device 748 move a cursor; two-finger swipes will result in single-finger touch events; other two-finger 749 gestures will result in the corresponding two-finger touch event. An example device that supports 750 distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement 751 which also supports two or more fingers.</p></td> 752 </tr> 753 754 <tr> 755 <td><code>android.hardware.faketouch.multitouch.jazzhand</code></td> 756 <td>The application performs distinct tracking of five or more "fingers" on a fake touch 757 interface. This is a superset of the faketouch feature.</td> 758 <td><p>When declared as required, this indicates that the application is compatible with a device 759 only if it supports touch emulation for events that supports distinct tracking of five or more 760 fingers.</p> 761 <p>Unlike the distinct multitouch defined by {@code 762 android.hardware.touchscreen.multitouch.jazzhand}, input devices that support jazzhand multi-touch 763 with a fake touch interface will not support all five-finger gestures, because the input is being 764 transformed to cursor movement on the screen. That is, single finger gestures on such a device move 765 a cursor; multi-finger gestures will result in single-finger touch events; other multi-finger 766 gestures will result in the corresponding multi-finger touch event. An example device that supports 767 distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement 768 which also supports five or more fingers.</p></td> 769 </tr> 770 771 <tr> 772 <td><code>android.hardware.touchscreen</code></td> 773 <td>The application uses touchscreen capabilities for gestures that are more interactive 774 than basic touch events, such as a fling. This is a superset of the basic faketouch feature.</td> 775 <td><p>By default, your application requires this. As such, your application is <em>not</em> 776 available to devices that provide only an emulated touch interface ("fake touch"), by default. If 777 you want your application available to devices that provide a fake touch interface (or even devices 778 that provide only a d-pad controller), you must explicitly declare that a touch screen is not 779 required, by declaring {@code android.hardware.touchscreen} with {@code android:required="false"}. 780 You should do so even if your application uses—but does not <em>require</em>—a real 781 touch screen interface.</p> 782 <p>If your application <em>does require</em> a touch interface (in order to perform touch 783 gestures such as a fling), then you don't need to do anything, because this is required by default. 784 However, it's best if you explicitly declare all features used by your application, so you should 785 still declare this if your app uses it.</p> 786 <p>If you require more complex touch interaction, such as multi-finger gestures, you 787 should declare the advanced touch screen features below.</p></td> 788 </tr> 789 <tr> 790 <td><code>android.hardware.touchscreen.multitouch</code></td> 791 <td>The application uses basic two-point multitouch capabilities on the device 792 screen, such as for pinch gestures, but does not need to track touches independently. This 793 is a superset of touchscreen feature.</td> 794 <td>This implicitly declares the <code>android.hardware.touchscreen</code> parent feature, unless 795 declared with <code>android:required="false"</code>. </td> 796 </tr> 797 <tr> 798 <td><code>android.hardware.touchscreen.multitouch.distinct</code></td> 799 <td>Subfeature. The application uses advanced multipoint multitouch 800 capabilities on the device screen, such as for tracking two or more points fully 801 independently. This is a superset of multitouch feature.</td> 802 <td rowspan="2">This implicitly declares the <code>android.hardware.touchscreen.multitouch</code> 803 parent feature, unless declared with <code>android:required="false"</code>. </td> 804 </tr> 805 <tr> 806 <td><code>android.hardware.touchscreen.multitouch.jazzhand</code></td> 807 <td>The application uses advanced multipoint multitouch 808 capabilities on the device screen, for tracking up to five points fully 809 independently. This is a superset of distinct multitouch feature.</td> 810 </tr> 811 812 <tr> 813 <td rowspan="2">USB</td> 814 <td><code>android.hardware.usb.host</code></td> 815 <td>The application uses USB host mode features (behaves as the host and connects to USB 816 devices).</td> 817 <td></td> 818 </tr> 819 820 <tr> 821 <td><code>android.hardware.usb.accessory</code></td> 822 <td>The application uses USB accessory features (behaves as the USB device and connects to USB 823 hosts).</td> 824 <td></td> 825 </tr> 826 827 <tr> 828 <td>Wifi</td> 829 <td><code>android.hardware.wifi</code></td> 830 <td>The application uses 802.11 networking (wifi) features on the device.</td> 831 <td></td> 832 </tr> 833 834 </table> 835 836 <h3 id="sw-features">Software features</h3> 837 838 <p>The table below describes the software feature descriptors supported by the 839 most current platform release. To signal that your application uses or requires 840 a software feature, declare each value in a <code>android:name</code> attribute 841 in a separate <code><uses-feature></code> element. </p> 842 843 844 <table> 845 <tr> 846 <th>Feature</th> 847 <th>Attribute Value</th> 848 <th>Description</th> 849 <th>Comments</th> 850 </tr> 851 <tr> 852 <td>Live Wallpaper</td> 853 <td><code>android.software.live_wallpaper</code></td> 854 <td>The application uses or provides Live Wallpapers.</td> 855 <td></td> 856 </tr> 857 <tr> 858 <td rowspan="2">SIP/VOIP</td> 859 <td><code>android.software.sip</code></td> 860 <td>The application uses SIP service on the device. 861 </td> 862 <td></td> 863 </tr> 864 <tr> 865 <td><code>android.software.sip.voip</code></td> 866 <td>Subfeature. The application uses SIP-based VOIP service on the device. 867 </td> 868 <td>This subfeature implicitly declares the <code>android.software.sip</code> parent feature, 869 unless declared with <code>android:required="false"</code>.</td> 870 </tr> 871 </table> 872 873 874 <h3 id="permissions">Permissions that Imply Feature Requirements</h3> 875 876 <p>Some feature constants listed in the tables above were made available to 877 applications <em>after</em> the corresponding API; for example, the 878 <code>android.hardware.bluetooth</code> feature was added in Android 2.2 (API 879 level 8), but the bluetooth API that it refers to was added in Android 2.0 (API 880 level 5). Because of this, some apps were able to use the API before they had 881 the ability to declare that they require the API via the 882 <code><uses-feature></code> system. </p> 883 884 <p>To prevent those apps from being made available unintentionally, Google 885 Play assumes that certain hardware-related permissions indicate that the 886 underlying hardware features are required by default. For instance, applications 887 that use Bluetooth must request the <code>BLUETOOTH</code> permission in a 888 <code><uses-permission></code> element — for legacy apps, Google 889 Play assumes that the permission declaration means that the underlying 890 <code>android.hardware.bluetooth</code> feature is required by the application 891 and sets up filtering based on that feature. </p> 892 893 <p>The table below lists permissions that imply feature requirements 894 equivalent to those declared in <code><uses-feature></code> elements. Note 895 that <code><uses-feature></code> declarations, including any declared 896 <code>android:required</code> attribute, always take precedence over features 897 implied by the permissions below. </p> 898 899 <p>For any of the permissions below, you can disable filtering based on the 900 implied feature by explicitly declaring the implied feature explicitly, in a 901 <code><uses-feature></code> element, with an 902 <code>android:required="false"</code> attribute. For example, to disable any 903 filtering based on the <code>CAMERA</code> permission, you would add this 904 <code><uses-feature></code> declaration to the manifest file:</p> 905 906 <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre> 907 908 <table id="permissions-features" > 909 <tr> 910 <th>Category</th> 911 <th>This Permission...</th> 912 <th>Implies This Feature Requirement</th> 913 <!-- <th>Comments</th> --> 914 </tr> 915 916 917 <tr> 918 <td rowspan="2">Bluetooth</td> 919 <td><code>BLUETOOTH</code></td> 920 <td><code>android.hardware.bluetooth</code> 921 <p>(See <a href="#bt-permission-handling">Special handling for Bluetooth feature</a> for details.)</p></td> 922 <!-- <td></td> --> 923 </tr> 924 <tr> 925 <td><code>BLUETOOTH_ADMIN</code></td> 926 <td><code>android.hardware.bluetooth</code></td> 927 <!-- <td></td> --> 928 </tr> 929 930 <tr> 931 <td>Camera</td> 932 <td><code>CAMERA</code></td> 933 <td><code>android.hardware.camera</code> <em>and</em> 934 <br><code>android.hardware.camera.autofocus</code></td> 935 <!-- <td></td> --> 936 </tr> 937 938 <tr> 939 <td rowspan="5">Location</td> 940 <td><code>ACCESS_MOCK_LOCATION</code></td> 941 <td><code>android.hardware.location</code></td> 942 <!-- <td></td> --> 943 </tr> 944 <tr> 945 <td><code>ACCESS_LOCATION_EXTRA_COMMANDS</code></td> 946 <td><code>android.hardware.location</code></td> 947 <!-- <td></td> --> 948 </tr> 949 <tr> 950 <td><code>INSTALL_LOCATION_PROVIDER</code></td> 951 <td><code>android.hardware.location</code></td> 952 <!-- <td></td> --> 953 </tr> 954 <tr> 955 <td><code>ACCESS_COARSE_LOCATION</code></td> 956 <td><code>android.hardware.location.network</code> <em>and</em> 957 <br><code>android.hardware.location</code></td> 958 <!-- <td></td> --> 959 </tr> 960 <tr> 961 <td><code>ACCESS_FINE_LOCATION</code></td> 962 <td><code>android.hardware.location.gps</code> <em>and</em> 963 <br><code>android.hardware.location</code></td> 964 <!-- <td></td> --> 965 </tr> 966 967 <tr> 968 <td>Microphone</td> 969 <td><code>RECORD_AUDIO</code></td> 970 <td><code>android.hardware.microphone</code></td> 971 <!-- <td></td> --> 972 </tr> 973 974 <tr> 975 <td rowspan="11">Telephony</td> 976 <td><code>CALL_PHONE</code></td> 977 <td><code>android.hardware.telephony</code></td> 978 <!-- <td></td> --> 979 </tr> 980 <tr> 981 <td><code>CALL_PRIVILEGED</code></td> 982 <td><code>android.hardware.telephony</code></td> 983 <!-- <td></td> --> 984 </tr> 985 986 <tr> 987 <td><code>MODIFY_PHONE_STATE</code></td> 988 <td><code>android.hardware.telephony</code></td> 989 <!-- <td></td> --> 990 </tr> 991 <tr> 992 <td><code>PROCESS_OUTGOING_CALLS</code></td> 993 <td><code>android.hardware.telephony</code></td> 994 <!-- <td></td> --> 995 </tr> 996 <tr> 997 <td><code>READ_SMS</code></td> 998 <td><code>android.hardware.telephony</code></td> 999 <!-- <td></td> --> 1000 </tr> 1001 <tr> 1002 <td><code>RECEIVE_SMS</code></td> 1003 <td><code>android.hardware.telephony</code></td> 1004 <!-- <td></td> --> 1005 </tr> 1006 <tr> 1007 <td><code>RECEIVE_MMS</code></td> 1008 <td><code>android.hardware.telephony</code></td> 1009 <!-- <td></td> --> 1010 </tr> 1011 <tr> 1012 <td><code>RECEIVE_WAP_PUSH</code></td> 1013 <td><code>android.hardware.telephony</code></td> 1014 <!-- <td></td> --> 1015 </tr> 1016 <tr> 1017 <td><code>SEND_SMS</code></td> 1018 <td><code>android.hardware.telephony</code></td> 1019 <!-- <td></td> --> 1020 </tr> 1021 <tr> 1022 <td><code>WRITE_APN_SETTINGS</code></td> 1023 <td><code>android.hardware.telephony</code></td> 1024 <!-- <td></td> --> 1025 </tr> 1026 <tr> 1027 <td><code>WRITE_SMS</code></td> 1028 <td><code>android.hardware.telephony</code></td> 1029 <!-- <td></td> --> 1030 </tr> 1031 1032 <tr> 1033 <td rowspan="3">Wifi</td> 1034 <td><code>ACCESS_WIFI_STATE</code></td> 1035 <td><code>android.hardware.wifi</code></td> 1036 <!-- <td></td> --> 1037 </tr> 1038 <tr> 1039 <td><code>CHANGE_WIFI_STATE</code></td> 1040 <td><code>android.hardware.wifi</code></td> 1041 <!-- <td></td> --> 1042 </tr> 1043 <tr> 1044 <td><code>CHANGE_WIFI_MULTICAST_STATE</code></td> 1045 <td><code>android.hardware.wifi</code></td> 1046 <!-- <td></td> --> 1047 </tr> 1048 </table>