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