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">&lt;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>" /&gt;</pre>
11</dd>
12
13<dt>contained in:</dt>
14<dd><code><a
15href="{@docRoot}guide/topics/manifest/manifest-element.html">&lt;manifest&gt;</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;">&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</code>
64element, so if your application requires multiple features, it would declare
65multiple <code>&lt;uses-feature&gt;</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&lt;uses-feature android:name="android.hardware.bluetooth" />
71&lt;uses-feature android:name="android.hardware.camera" />
72</pre>
73
74<p>In general, you should always make sure to declare
75<code>&lt;uses-feature&gt;</code> elements for all of the features that your
76application requires.</p>
77
78<p>Declared <code>&lt;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>&lt;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>&lt;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>&lt;uses-permission&gt;</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 &mdash; an application declares features in
201<code>&lt;uses-feature&gt;</code> elements in its manifest <br/>with...</li>
202<li>Features available on the device, in hardware or software &mdash;
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>&lt;uses-feature&gt;</code> elements and evaluates them in combination
222with other elements, in some cases, such as <code>&lt;uses-sdk&gt;</code> and
223<code>&lt;uses-permission&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature android:name="android.hardware.camera" android:required="true" /&gt;</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>&lt;uses-feature android:name="android.hardware.camera" android:required="false" /&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-permission&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature android:name="android.hardware.camera" android:required="false" /&gt;</pre>
338
339<p class="caution">It's important to understand that the permissions that you
340request in <code>&lt;uses-permission&gt;</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>&lt;uses-permission&gt;</code> element, but does not explicitly declare
353the Bluetooth feature in a <code>&lt;uses-feature&gt;</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>&lt;uses-sdk&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;=4 (or uses-sdk is not declared)</nobr></td>
377<td>&lt;=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>&lt;=4</td>
384<td>&gt;=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>&gt;=5</td>
391<td>&gt;=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>&lt;uses-feature&gt;</code> element.</dt>
402<dd><em>Result:</em> Android Market does not filter the application from any device.</dd>
403</dl>
404
405<pre>&lt;manifest ...>
406    &lt;uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
407    &lt;uses-sdk android:minSdkVersion="3" />
408    ...
409&lt;/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>&lt;manifest ...>
420    &lt;uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
421    &lt;uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
422    ...
423&lt;/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>&lt;manifest ...>
431    &lt;uses-feature android:name="android.hardware.bluetooth" />
432    &lt;uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
433    &lt;uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
434    ...
435&lt;/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>&lt;manifest ...>
445    &lt;uses-feature android:name="android.hardware.bluetooth" android:required="false" />
446    &lt;uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
447    &lt;uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
448    ...
449&lt;/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> &gt; <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>&lt;<em>SDK</em>&gt;/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 &lt;<em>path_to_exported_.apk</em>&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-permission&gt;</code> element &mdash; 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>&lt;uses-feature&gt;</code> elements. Note
745that <code>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</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>&lt;uses-feature&gt;</code> declaration to the manifest file:</p>
755
756<pre>&lt;uses-feature android:name="android.hardware.camera" android:required="false" /&gt;</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>