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