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