1 page.title=<uses-feature>
2 page.tags="filtering","features","google play filters","permissions"
9 <h2>In this document</h2>
11 <li><a href="#market-feature-filtering">Google Play and Feature-Based Filtering</a>
13 <li><a href="#declared">Filtering based on explicitly declared features</a></li>
14 <li><a href="#implicit">Filtering based on implicit features</a></li>
15 <li><a href="#bt-permission-handling">Special handling for Bluetooth feature</a></li>
16 <li><a href="#testing">Testing the features required by your application</a></li>
19 <li><a href="#features-reference">Features Reference</a>
21 <li><a href="#hw-features">Hardware features</a></li>
22 <li><a href="#sw-features">Software features</a></li>
23 <li><a href="#permissions">Permissions that Imply Feature Requirements</a></li>
30 <div class="sidebox-wrapper">
32 <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;">
33 <p style="color:#669999;padding-top:1em;">Google Play Filtering</p>
34 <p style="padding-top:1em;">Google Play uses the <code><uses-feature></code>
35 elements declared in your app manifest to filter your app from devices
36 that do not meet it's hardware and software feature requirements. </p>
38 <p style="margin-top:1em;">By specifying the features that your application requires,
39 you enable Google Play to present your application only to users whose
40 devices meet the application's feature requirements, rather than presenting it
43 <p>For important information about how
44 Google Play uses features as the basis for filtering, please read <a
45 href="#market-feature-filtering">Google Play and Feature-Based Filtering</a>,
54 <pre class="stx"><uses-feature
55 android:<a href="#name">name</a>="<em>string</em>"
56 android:<a href="#required">required</a>=["true" | "false"]
57 android:<a href="#glEsVersion">glEsVersion</a>="<em>integer</em>" /></pre>
60 <dt>contained in:</dt>
62 href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a></code></dd>
65 <dd itemprop="description">Declares a single hardware or software feature that is used by the
68 <p>The purpose of a <code><uses-feature></code> declaration is to inform
69 any external entity of the set of hardware and software features on which your
70 application depends. The element offers a <code>required</code> attribute that
71 lets you specify whether your application requires and cannot function without
72 the declared feature, or whether it prefers to have the feature but can function
73 without it. Because feature support can vary across Android devices, the
74 <code><uses-feature></code> element serves an important role in letting an
75 application describe the device-variable features that it uses.</p>
77 <p>The set of available features that your application declares corresponds to
78 the set of feature constants made available by the Android {@link
79 android.content.pm.PackageManager}, which are listed for
80 convenience in the <a href="#features-reference">Features Reference</a> tables
81 at the bottom of this document.
83 <p>You must specify each feature in a separate <code><uses-feature></code>
84 element, so if your application requires multiple features, it would declare
85 multiple <code><uses-feature></code> elements. For example, an application
86 that requires both Bluetooth and camera features in the device would declare
87 these two elements:</p>
90 <uses-feature android:name="android.hardware.bluetooth" />
91 <uses-feature android:name="android.hardware.camera" />
94 <p>In general, you should always make sure to declare
95 <code><uses-feature></code> elements for all of the features that your
96 application requires.</p>
98 <p>Declared <code><uses-feature></code> elements are informational only, meaning
99 that the Android system itself does not check for matching feature support on
100 the device before installing an application. However, other services
101 (such as Google Play) or applications may check your application's
102 <code><uses-feature></code> declarations as part of handling or interacting
103 with your application. For this reason, it's very important that you declare all of
104 the features (from the list below) that your application uses. </p>
106 <p>For some features, there may exist a specific attribute that allows you to define
107 a version of the feature, such as the version of Open GL used (declared with
108 <a href="#glEsVersion"><code>glEsVersion</code></a>). Other features that either do or do not
109 exist for a device, such as a camera, are declared using the
110 <a href="#name"><code>name</code></a> attribute.</p>
113 <p>Although the <code><uses-feature></code> element is only activated for
114 devices running API Level 4 or higher, it is recommended to include these
115 elements for all applications, even if the <a href="uses-sdk-element.html#min"><code>minSdkVersion</code></a>
116 is "3" or lower. Devices running older versions of the platform will simply
117 ignore the element.</p>
119 <p class="note"><strong>Note:</strong> When declaring a feature, remember
120 that you must also request permissions as appropriate. For example, you must
121 still request the {@link android.Manifest.permission#CAMERA}
122 permission before your application can access the camera API. Requesting the
123 permission grants your application access to the appropriate hardware and
124 software, while declaring the features used by your application ensures proper
125 device compatibility.</p>
135 <dt><a name="name"></a><code>android:name</code></dt>
136 <dd>Specifies a single hardware or software feature used by the application,
137 as a descriptor string. Valid descriptor values are listed in the <a
138 href="#hw-features">Hardware features</a> and <a href="#sw-features">Software
139 features</a> tables, below. Descriptor string values are case-sensitive.</dd>
141 <dt><a name="required"></a><code>android:required</code></dt> <!-- added in api level 5 -->
142 <dd>Boolean value that indicates whether the application requires
143 the feature specified in <code>android:name</code>.
146 <li>When you declare <code>"android:required="true"</code> for a feature,
147 you are specifying that the application <em>cannot function, or is not
148 designed to function</em>, when the specified feature is not present on the
151 <li>When you declare <code>"android:required="false"</code> for a feature, it
152 means that the application <em>prefers to use the feature</em> if present on
153 the device, but that it <em>is designed to function without the specified
154 feature</em>, if necessary. </li>
158 <p>The default value for <code>android:required</code> if not declared is
159 <code>"true"</code>.</p>
162 <dt><a name="glEsVersion"></a><code>android:glEsVersion</code></dt>
163 <dd>The OpenGL ES version required by the application. The higher 16 bits
164 represent the major number and the lower 16 bits represent the minor number. For
165 example, to specify OpenGL ES version 2.0, you would set the value as
166 "0x00020000", or to specify OpenGL ES 3.0, you would set the value as "0x00030000".
168 <p>An application should specify at most one <code>android:glEsVersion</code>
169 attribute in its manifest. If it specifies more than one, the
170 <code>android:glEsVersion</code> with the numerically highest value is used and
171 any other values are ignored.</p>
173 <p>If an application does not specify an <code>android:glEsVersion</code>
174 attribute, then it is assumed that the application requires only OpenGL ES 1.0,
175 which is supported by all Android-powered devices.</p>
177 <p>An application can assume that if a platform supports a given OpenGL ES
178 version, it also supports all numerically lower OpenGL ES versions. Therefore,
179 an application that requires both OpenGL ES 1.0 and OpenGL ES 2.0 must specify
180 that it requires OpenGL ES 2.0.</p>
182 <p>An application that can work with any of several OpenGL ES versions should
183 only specify the numerically lowest version of OpenGL ES that it requires. (It
184 can check at run-time whether a higher level of OpenGL ES is available.)</p>
186 <p>For more information about using OpenGL ES, including how to check the supported OpenGL ES
187 version at runtime, see the <a href="{@docRoot}guide/topics/graphics/opengl.html">OpenGL ES</a>
194 <!-- ##api level indication## -->
195 <dt>introduced in:</dt>
201 <li>{@link android.content.pm.PackageManager}</li>
202 <li>{@link android.content.pm.FeatureInfo}</li>
203 <li>{@link android.content.pm.ConfigurationInfo}</li>
204 <li><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><code><uses-permission></code></a></li>
205 <li><a href="{@docRoot}google/play/filters.html">Filters on Google Play</a></li>
212 <h2 id="market-feature-filtering">Google Play and Feature-Based Filtering</h2>
214 <p>Google Play filters the applications that are visible to users, so that
215 users can see and download only those applications that are compatible with
216 their devices. One of the ways it filters applications is by feature
219 <p>To determine an application's feature compatibility with a given user's
220 device, Google Play compares:</p>
223 <li>Features required by the application — an application declares features in
224 <code><uses-feature></code> elements in its manifest <br/>with...</li>
225 <li>Features available on the device, in hardware or software —
226 a device reports the features it supports as read-only system properties.</li>
229 <p>To ensure an accurate comparison of features, the Android Package Manager
230 provides a shared set of feature constants that both applications and devices
231 use to declare feature requirements and support. The available feature constants
232 are listed in the <a href="#features-reference">Features Reference</a> tables at
233 the bottom of this document, and in the class documentation for {@link
234 android.content.pm.PackageManager}.</p>
236 <p>When the user launches Google Play, the application queries the
237 Package Manager for the list of features available on the device by calling
238 {@link android.content.pm.PackageManager#getSystemAvailableFeatures()}. The
239 Store application then passes the features list up to Google Play
240 when establishing the session for the user.</p>
242 <p>Each time you upload an application to the Google Play Developer Console,
243 Google Play scans the application's manifest file. It looks for
244 <code><uses-feature></code> elements and evaluates them in combination
245 with other elements, in some cases, such as <code><uses-sdk></code> and
246 <code><uses-permission></code> elements. After establishing the
247 application's set of required features, it stores that list internally as
248 metadata associated with the application <code>.apk</code> and the application
251 <p>When a user searches or browses for applications using the Google Play
252 application, the service compares the features needed by each application with
253 the features available on the user's device. If all of an application's required
254 features are present on the device, Google Play allows the user to see the
255 application and potentially download it. If any required feature is not
256 supported by the device, Google Play filters the application so that it is
257 not visible to the user and not available for download. </p>
259 <p>Because the features you declare in <code><uses-feature></code>
260 elements directly affect how Google Play filters your application, it's
261 important to understand how Google Play evaluates the application's manifest
262 and establishes the set of required features. The sections below provide more
265 <h3 id="declared">Filtering based on explicitly declared features</h3>
267 <p>An explicitly declared feature is one that your application declares in a
268 <code><uses-feature></code> element. The feature declaration can include
269 an <code>android:required=["true" | "false"]</code> attribute (if you are
270 compiling against API level 5 or higher), which lets you specify whether the
271 application absolutely requires the feature and cannot function properly without
272 it (<code>"true"</code>), or whether the application prefers to use the feature
273 if available, but is designed to run without it (<code>"false"</code>).</p>
275 <p>Google Play handles explicitly declared features in this way: </p>
278 <li>If a feature is explicitly declared as being required, Google Play adds
279 the feature to the list of required features for the application. It then
280 filters the application from users on devices that do not provide that feature.
282 <pre><uses-feature android:name="android.hardware.camera" android:required="true" /></pre></li>
283 <li>If a feature is explicitly declared as <em>not</em> being required, Google
284 Play <em>does not</em> add the feature to the list of required features. For
285 that reason, an explicitly declared non-required feature is never considered when
286 filtering the application. Even if the device does not provide the declared
287 feature, Google Play will still consider the application compatible with the
288 device and will show it to the user, unless other filtering rules apply. For
290 <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre></li>
291 <li>If a feature is explicitly declared, but without an
292 <code>android:required</code> attribute, Google Play assumes that the feature
293 is required and sets up filtering on it. </li>
296 <p>In general, if your application is designed to run on Android 1.6 and earlier
297 versions, the <code>android:required</code> attribute is not available in the
298 API and Google Play assumes that any and all
299 <code><uses-feature></code> declarations are required. </p>
301 <p class="note"><strong>Note:</strong> By declaring a feature explicitly and
302 including an <code>android:required="false"</code> attribute, you can
303 effectively disable all filtering on Google Play for the specified feature.
307 <h3 id="implicit">Filtering based on implicit features</h3>
309 <p>An <em>implicit</em> feature is one that an application requires in order to
310 function properly, but which is <em>not</em> declared in a
311 <code><uses-feature></code> element in the manifest file. Strictly
312 speaking, every application should <em>always</em> declare all features that it
313 uses or requires, so the absence of a declaration for a feature used by an
314 application should be considered an error. However, as a safeguard for users and
315 developers, Google Play looks for implicit features in each application and
316 sets up filters for those features, just as it would do for an explicitly
317 declared feature. </p>
319 <p>An application might require a feature but not declare it because: </p>
322 <li>The application was compiled against an older version of the Android library
323 (Android 1.5 or earlier) and the <code><uses-feature></code> element was
325 <li>The developer incorrectly assumed that the feature would be present on all
326 devices and a declaration was unnecessary.</li>
327 <li>The developer omitted the feature declaration accidentally.</li>
328 <li>The developer declared the feature explicitly, but the declaration was not
329 valid. For example, a spelling error in the <code><uses-feature></code>
330 element name or an unrecognized string value for the
331 <code>android:name</code> attribute would invalidate the feature declaration.
335 <p>To account for the cases above, Google Play attempts to discover an
336 application's implied feature requirements by examining <em>other elements</em>
337 declared in the manifest file, specifically,
338 <code><uses-permission></code> elements.</p>
340 <p>If an application requests hardware-related permissions, Google Play
341 <em>assumes that the application uses the underlying hardware features and
342 therefore requires those features</em>, even though there might be no
343 corresponding to <code><uses-feature></code> declarations. For such
344 permissions, Google Play adds the underlying hardware features to the
345 metadata that it stores for the application and sets up filters for them.</p>
347 <p>For example, if an application requests the <code>CAMERA</code> permission
348 but does not declare a <code><uses-feature></code> element for
349 <code>android.hardware.camera</code>, Google Play considers that the
350 application requires a camera and should not be shown to users whose devices do
351 not offer a camera.</p>
353 <p>If you don't want Google Play to filter based on a specific implied
354 feature, you can disable that behavior. To do so, declare the feature explicitly
355 in a <code><uses-feature></code> element and include an
356 <code>android:required="false"</code> attribute. For example, to disable
357 filtering derived from the <code>CAMERA</code> permission, you would declare
358 the feature as shown below.</p>
360 <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre>
362 <p class="caution">It's important to understand that the permissions that you
363 request in <code><uses-permission></code> elements can directly affect how
364 Google Play filters your application. The reference section <a
365 href="#permissions">Permissions that Imply Feature Requirements</a>,
366 below, lists the full set of permissions that imply feature requirements and
367 therefore trigger filtering.</p>
369 <h3 id="bt-permission-handling">Special handling for Bluetooth feature</h3>
371 <p>Google Play applies slightly different rules than described above, when
372 determining filtering for Bluetooth.</p>
374 <p>If an application declares a Bluetooth permission in a
375 <code><uses-permission></code> element, but does not explicitly declare
376 the Bluetooth feature in a <code><uses-feature></code> element, Google
377 Play checks the version(s) of the Android platform on which the application is
378 designed to run, as specified in the <code><uses-sdk></code> element. </p>
380 <p>As shown in the table below, Google Play enables filtering for the
381 Bluetooth feature only if the application declares its lowest or targeted
382 platform as Android 2.0 (API level 5) or higher. However, note that Google
383 Play applies the normal rules for filtering when the application explicitly
384 declares the Bluetooth feature in a <code><uses-feature></code> element.
387 <p class="caption"><strong>Table 1.</strong> How Google Play determines the
388 Bluetooth feature requirement for an application that requests a Bluetooth
389 permission but does not declare the Bluetooth feature in a
390 <code><uses-feature></code> element.</p>
392 <table style="margin-top:1em;">
394 <th><nobr>If <code>minSdkVersion</code> is ...</nobr></th>
395 <th><nobr>or <code>targetSdkVersion</code> is</nobr></th>
399 <td><nobr><=4 (or uses-sdk is not declared)</nobr></td>
401 <td>Google Play <em>will not</em> filter the application from any devices
402 based on their reported support for the <code>android.hardware.bluetooth</code>
408 <td rowspan="2">Google Play filters the application from any devices that
409 do not support the <code>android.hardware.bluetooth</code> feature (including
410 older releases).</td>
418 <p>The examples below illustrate the different filtering effects, based on how
419 Google Play handles the Bluetooth feature. </p>
422 <dt>In first example, an application that is designed to run on older API levels
423 declares a Bluetooth permission, but does not declare the Bluetooth feature in a
424 <code><uses-feature></code> element.</dt>
425 <dd><em>Result:</em> Google Play does not filter the application from any device.</dd>
428 <pre><manifest ...>
429 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
430 <uses-sdk android:minSdkVersion="3" />
435 <dt>In the second example, below, the same application also declares a target
436 API level of "5". </dt>
437 <dd><em>Result:</em> Google Play now assumes that the feature is required and
438 will filter the application from all devices that do not report Bluetooth support,
439 including devices running older versions of the platform. </dd>
442 <pre><manifest ...>
443 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
444 <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
449 <dt>Here the same application now specifically declares the Bluetooth feature.</dt>
450 <dd><em>Result:</em> Identical to the previous example (filtering is applied).</dd>
453 <pre><manifest ...>
454 <uses-feature android:name="android.hardware.bluetooth" />
455 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
456 <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
461 <dt>Finally, in the case below, the same application adds an
462 <code>android:required="false"</code> attribute.</dt>
463 <dd><em>Result:</em> Google Play disables filtering based on Bluetooth
464 feature support, for all devices.</dd>
467 <pre><manifest ...>
468 <uses-feature android:name="android.hardware.bluetooth" android:required="false" />
469 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
470 <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
476 <h3 id="testing">Testing the features required by your application</h3>
478 <p>You can use the <code>aapt</code> tool, included in the Android SDK, to
479 determine how Google Play will filter your application, based on its declared
480 features and permissions. To do so, run <code>aapt</code> with the <code>dump
481 badging</code> command. This causes <code>aapt</code> to parse your
482 application's manifest and apply the same rules as used by Google Play to
483 determine the features that your application requires. </p>
485 <p>To use the tool, follow these steps: </p>
488 <li>First, build and export your application as an unsigned <code>.apk</code>.
489 If you are developing in Eclipse with ADT, right-click the project and select
490 <strong>Android Tools</strong> > <strong>Export Unsigned Application
491 Package</strong>. Select a destination filename and path and click
492 <strong>OK</strong>. </li>
493 <li>Next, locate the <code>aapt</code> tool, if it is not already in your PATH.
494 If you are using SDK Tools r8 or higher, you can find <code>aapt</code> in the
495 <code><<em>SDK</em>>/platform-tools/</code> directory.
496 <p class="note"><strong>Note:</strong> You must use the version of
497 <code>aapt</code> that is provided for the latest Platform-Tools component available. If
498 you do not have the latest Platform-Tools component, download it using the <a
499 href="{@docRoot}sdk/exploring.html">Android SDK Manager</a>.
501 <li>Run <code>aapt</code> using this syntax: </li>
504 <pre>$ aapt dump badging <<em>path_to_exported_.apk</em>></pre>
506 <p>Here's an example of the command output for the second Bluetooth example, above: </p>
508 <pre>$ ./aapt dump badging BTExample.apk
509 package: name='com.example.android.btexample' versionCode='' versionName=''
510 <strong>uses-permission:'android.permission.BLUETOOTH_ADMIN'</strong>
511 <strong>uses-feature:'android.hardware.bluetooth'</strong>
514 application: label='BT Example' icon='res/drawable/app_bt_ex.png'
515 launchable activity name='com.example.android.btexample.MyActivity'label='' icon=''
516 uses-feature:'android.hardware.touchscreen'
518 supports-screens: 'small' 'normal' 'large'
524 <h2 id=features-reference>Features Reference</h2>
526 <p>The tables below provide reference information about hardware and software
527 features and the permissions that can imply them on Google Play. </p>
529 <h3 id="hw-features">Hardware features</h3>
531 <p>The table below describes the hardware feature descriptors supported by the
532 most current platform release. To signal that your application uses or requires
533 a hardware feature, declare each value in a <code>android:name</code> attribute
534 in a separate <code><uses-feature></code> element. </p>
538 <th>Feature Type</th>
539 <th>Feature Descriptor</th>
540 <th style="min-width:170px">Description</th>
545 <td><code>android.hardware.audio.low_latency</td>
546 <td>The application uses a low-latency audio pipeline on the device and
547 is sensitive to delays or lag in sound input or output.</td>
552 <td rowspan="2">Bluetooth</td>
553 <td><code>android.hardware.bluetooth</code></td>
554 <td>The application uses Bluetooth radio features in the device.</td>
558 <td><code>android.hardware.bluetooth_le</code></td>
559 <td>The application uses Bluetooth Low Energy radio features in the device.</td>
563 <td rowspan="5">Camera</td>
564 <td><code>android.hardware.camera</code></td>
565 <td>The application uses the device's camera. If the device supports
566 multiple cameras, the application uses the camera that facing
567 away from the screen.</td>
571 <td><code>android.hardware.camera.autofocus</code></td>
572 <td>Subfeature. The application uses the device camera's autofocus capability.</td>
573 <td rowspan="3">These subfeatures implicitly declare the
574 <code>android.hardware.camera</code> parent feature, unless declared with
575 <code>android:required="false"</code>.</td>
578 <td><code>android.hardware.camera.flash</code></td>
579 <td>Subfeature. The application uses the device camera's flash.</td>
582 <td><code>android.hardware.camera.front</code></td>
583 <td>Subfeature. The application uses a front-facing camera on the device.</td>
586 <td><code>android.hardware.camera.any</code></td>
587 <td>The application uses at least one camera facing in any direction. Use this
588 in preference to <code>android.hardware.camera</code> if a back-facing camera is
594 <td><code>android.hardware.consumerir</code></td>
595 <td>The application uses the consumer IR capabilities on the device.</td>
600 <td rowspan="3">Location</td>
601 <td><code>android.hardware.location</code></td>
602 <td>The application uses one or more features on the device for determining
603 location, such as GPS location, network location, or cell location.</td>
607 <td><code>android.hardware.location.network</code></td>
608 <td>Subfeature. The application uses coarse location coordinates obtained from
609 a network-based geolocation system supported on the device.</td>
610 <td rowspan="2">These subfeatures implicitly declare the
611 <code>android.hardware.location</code> parent feature, unless declared with
612 <code>android:required="false"</code>. </td>
615 <td><code>android.hardware.location.gps</code></td>
616 <td>Subfeature. The application uses precise location coordinates obtained
617 from a Global Positioning System receiver on the device. </td>
621 <td><code>android.hardware.microphone</code></td>
622 <td>The application uses a microphone on the device.
627 <td rowspan="2">NFC</td>
628 <td><code>android.hardware.nfc</td>
629 <td>The application uses Near Field Communications radio features in the device.</td>
633 <td><code>android.hardware.nfc.hce</code></td>
634 <td>The application uses the NFC card emulation feature in the device.</td>
638 <td rowspan="8">Sensors</td>
639 <td><code>android.hardware.sensor.accelerometer</code></td>
640 <td>The application uses motion readings from an accelerometer on the
645 <td><code>android.hardware.sensor.barometer</code></td>
646 <td>The application uses the device's barometer.</td>
650 <td><code>android.hardware.sensor.compass</code></td>
651 <td>The application uses directional readings from a magnetometer (compass) on
656 <td><code>android.hardware.sensor.gyroscope</code></td>
657 <td>The application uses the device's gyroscope sensor.</td>
661 <td><code>android.hardware.sensor.light</code></td>
662 <td>The application uses the device's light sensor.</td>
666 <td><code>android.hardware.sensor.proximity</code></td>
667 <td>The application uses the device's proximity sensor.</td>
671 <td><code>android.hardware.sensor.stepcounter</code></td>
672 <td>The application uses the device's step counter.</td>
676 <td><code>android.hardware.sensor.stepdetector</code></td>
677 <td>The application uses the device's step detector.</td>
682 <td rowspan="2">Screen</td>
683 <td><code>android.hardware.screen.landscape</code></td>
684 <td>The application requires landscape orientation.</td>
686 <p>For example, if your app requires portrait orientation, you should declare
687 <code><uses-feature android:name="android.hardware.screen.portrait"/></code> so that only devices
688 that support portrait orientation (whether always or by user choice) can install your app. If your
689 application <em>supports</em> both orientations, then you don't need to declare either.</p>
690 <p>Both orientations are assumed <em>not required</em>, by default, so your app may be installed
691 on devices that support one or both orientations. However, if any of your activities request that
692 they run in a specific orientation, using the <a
693 href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code
694 android:screenOrientation}</a> attribute, then this also declares that the application requires that
695 orientation. For example, if you declare <a
696 href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code
697 android:screenOrientation}</a> with either {@code "landscape"}, {@code "reverseLandscape"}, or
698 {@code "sensorLandscape"}, then your application will be available only to devices that support
699 landscape orientation. As a best practice, you should still declare your requirement for this
700 orientation using a {@code <uses-feature>} element. If you declare an orientation for your
701 activity using <a href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code
702 android:screenOrientation}</a>, but don't actually <em>require</em> it, you can disable the
703 requirement by declaring the orientation with a {@code <uses-feature>} element and include
704 {@code android:required="false"}.</p>
705 <p>For backwards compatibility, any device running a platform version that supports only API
706 level 12 or lower is assumed to support both landscape and portrait.</p>
710 <td><code>android.hardware.screen.portrait</code></td>
711 <td>The application requires portrait orientation.</td>
715 <td rowspan="3">Telephony</td>
716 <td><code>android.hardware.telephony</code></td>
717 <td>The application uses telephony features on the device, such as telephony
718 radio with data communication services.</td>
722 <td><code>android.hardware.telephony.cdma</code></td>
723 <td>Subfeature. The application uses CDMA telephony radio features on the
725 <td rowspan="2">These subfeatures implicitly declare the
726 <code>android.hardware.telephony</code> parent feature, unless declared with
727 <code>android:required="false"</code>. </td>
730 <td><code>android.hardware.telephony.gsm</code></td>
731 <td>Subfeature. The application uses GSM telephony radio features on the
737 <td><code>android.hardware.type.television</code></td>
738 <td>The application is designed for a television user experience.</td>
739 <td>This feature defines "television" to be a typical living room television experience:
740 displayed on a big screen, where the user is sitting far away and the dominant form of
741 input is something like a d-pad, and generally not through touch or a
742 mouse/pointer-device.</td>
746 <td rowspan="7">Touchscreen</td>
747 <td><code>android.hardware.faketouch</code></td>
748 <td>The application uses basic touch interaction events, such as "click down", "click
750 <td><p>When declared as required, this indicates that the application is compatible with a device
751 only if it offers an emulated touchscreen ("fake touch" interface), or better. A device that offers
752 a fake touch interface provides a user input system that emulates a subset of touchscreen
753 capabilities. For example, a mouse or remote control that drives an on-screen cursor provides a fake
754 touch interface. If your application requires basic point and click interaction (in other
755 words, it won't work with <em>only</em> a d-pad controller), you should declare this feature.
756 Because this is the minimum level of touch interaction, your app will also be compatible with
757 devices that offer more complex touch interfaces.</p>
758 <p class="note"><strong>Note:</strong> Because applications require the {@code
759 android.hardware.touchscreen} feature by default, if you want your application to be available to
760 devices that provide a fake touch interface, you must also explicitly declare that a touch screen is
761 <em>not</em> required by declaring {@code <uses-feature
762 android:name="android.hardware.touchscreen" <strong>android:required="false"</strong>
767 <td><code>android.hardware.faketouch.multitouch.distinct</code></td>
768 <td>The application performs distinct tracking of two or more "fingers" on a fake touch
769 interface. This is a superset of the faketouch feature.</td>
770 <td><p>When declared as required, this indicates that the application is compatible with a device
771 only if it supports touch emulation for events that supports distinct tracking of two or more
772 fingers, or better.</p>
773 <p>Unlike the distinct multitouch defined by {@code
774 android.hardware.touchscreen.multitouch.distinct}, input devices that support distinct multi-touch
775 with a fake touch interface will not support all two-finger gestures, because the input is
776 being transformed to cursor movement on the screen. That is, single finger gestures on such a device
777 move a cursor; two-finger swipes will result in single-finger touch events; other two-finger
778 gestures will result in the corresponding two-finger touch event. An example device that supports
779 distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement
780 which also supports two or more fingers.</p></td>
784 <td><code>android.hardware.faketouch.multitouch.jazzhand</code></td>
785 <td>The application performs distinct tracking of five or more "fingers" on a fake touch
786 interface. This is a superset of the faketouch feature.</td>
787 <td><p>When declared as required, this indicates that the application is compatible with a device
788 only if it supports touch emulation for events that supports distinct tracking of five or more
790 <p>Unlike the distinct multitouch defined by {@code
791 android.hardware.touchscreen.multitouch.jazzhand}, input devices that support jazzhand multi-touch
792 with a fake touch interface will not support all five-finger gestures, because the input is being
793 transformed to cursor movement on the screen. That is, single finger gestures on such a device move
794 a cursor; multi-finger gestures will result in single-finger touch events; other multi-finger
795 gestures will result in the corresponding multi-finger touch event. An example device that supports
796 distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement
797 which also supports five or more fingers.</p></td>
801 <td><code>android.hardware.touchscreen</code></td>
802 <td>The application uses touchscreen capabilities for gestures that are more interactive
803 than basic touch events, such as a fling. This is a superset of the basic faketouch feature.</td>
804 <td><p>By default, your application requires this. As such, your application is <em>not</em>
805 available to devices that provide only an emulated touch interface ("fake touch"), by default. If
806 you want your application available to devices that provide a fake touch interface (or even devices
807 that provide only a d-pad controller), you must explicitly declare that a touch screen is not
808 required, by declaring {@code android.hardware.touchscreen} with {@code android:required="false"}.
809 You should do so even if your application uses—but does not <em>require</em>—a real
810 touch screen interface.</p>
811 <p>If your application <em>does require</em> a touch interface (in order to perform touch
812 gestures such as a fling), then you don't need to do anything, because this is required by default.
813 However, it's best if you explicitly declare all features used by your application, so you should
814 still declare this if your app uses it.</p>
815 <p>If you require more complex touch interaction, such as multi-finger gestures, you
816 should declare the advanced touch screen features below.</p></td>
819 <td><code>android.hardware.touchscreen.multitouch</code></td>
820 <td>The application uses basic two-point multitouch capabilities on the device
821 screen, such as for pinch gestures, but does not need to track touches independently. This
822 is a superset of touchscreen feature.</td>
823 <td>This implicitly declares the <code>android.hardware.touchscreen</code> parent feature, unless
824 declared with <code>android:required="false"</code>. </td>
827 <td><code>android.hardware.touchscreen.multitouch.distinct</code></td>
828 <td>Subfeature. The application uses advanced multipoint multitouch
829 capabilities on the device screen, such as for tracking two or more points fully
830 independently. This is a superset of multitouch feature.</td>
831 <td rowspan="2">This implicitly declares the <code>android.hardware.touchscreen.multitouch</code>
832 parent feature, unless declared with <code>android:required="false"</code>. </td>
835 <td><code>android.hardware.touchscreen.multitouch.jazzhand</code></td>
836 <td>The application uses advanced multipoint multitouch
837 capabilities on the device screen, for tracking up to five points fully
838 independently. This is a superset of distinct multitouch feature.</td>
842 <td rowspan="2">USB</td>
843 <td><code>android.hardware.usb.host</code></td>
844 <td>The application uses USB host mode features (behaves as the host and connects to USB
850 <td><code>android.hardware.usb.accessory</code></td>
851 <td>The application uses USB accessory features (behaves as the USB device and connects to USB
857 <td rowspan="2">Wi-Fi</td>
858 <td><code>android.hardware.wifi</code></td>
859 <td>The application uses 802.11 networking (Wi-Fi) features on the device.</td>
863 <td><code>android.hardware.wifi.direct</code></td>
864 <td>The application uses the Wi-Fi Direct networking features on the device.</td>
869 <h3 id="sw-features">Software features</h3>
871 <p>The table below describes the software feature descriptors supported by the
872 most current platform release. To signal that your application uses or requires
873 a software feature, declare each value in a <code>android:name</code> attribute
874 in a separate <code><uses-feature></code> element. </p>
880 <th>Attribute Value</th>
885 <td><code>android.software.app_widgets</code></td>
886 <td>The application uses or provides App Widgets and should be installed only on devices
887 that include a Home screen or similar location where users can embed App Widgets.</td>
890 <td>Device Management</td>
891 <td><code>android.software.device_admin</code></td>
892 <td>The application uses device policy enforcement via device administrators.</td>
896 <td><code>android.software.home_screen</code></td>
897 <td>The application behaves as a Home screen replacement and should be installed only on
898 devices that support third-party Home screen apps.</td>
901 <td>Input Method</td>
902 <td><code>android.software.input_methods</code></td>
903 <td>The application provides a custom input method and should be installed only on devices that
904 support third-party input methods.</td>
907 <td>Live Wallpaper</td>
908 <td><code>android.software.live_wallpaper</code></td>
909 <td>The application uses or provides Live Wallpapers and should be installed only on devices that
910 support Live Wallpapers.</td>
913 <td rowspan="2">SIP/VOIP</td>
914 <td><code>android.software.sip</code></td>
915 <td>The application uses SIP service on the device and should be installed only on devices that
920 <td><code>android.software.sip.voip</code></td>
921 <td><p>Subfeature. The application uses SIP-based VOIP service on the device.
922 <p>This subfeature implicitly declares the <code>android.software.sip</code> parent feature,
923 unless declared with <code>android:required="false"</code>.</td>
928 <h3 id="permissions">Permissions that Imply Feature Requirements</h3>
930 <p>Some feature constants listed in the tables above were made available to
931 applications <em>after</em> the corresponding API; for example, the
932 <code>android.hardware.bluetooth</code> feature was added in Android 2.2 (API
933 level 8), but the bluetooth API that it refers to was added in Android 2.0 (API
934 level 5). Because of this, some apps were able to use the API before they had
935 the ability to declare that they require the API via the
936 <code><uses-feature></code> system. </p>
938 <p>To prevent those apps from being made available unintentionally, Google
939 Play assumes that certain hardware-related permissions indicate that the
940 underlying hardware features are required by default. For instance, applications
941 that use Bluetooth must request the <code>BLUETOOTH</code> permission in a
942 <code><uses-permission></code> element — for legacy apps, Google
943 Play assumes that the permission declaration means that the underlying
944 <code>android.hardware.bluetooth</code> feature is required by the application
945 and sets up filtering based on that feature. </p>
947 <p>The table below lists permissions that imply feature requirements
948 equivalent to those declared in <code><uses-feature></code> elements. Note
949 that <code><uses-feature></code> declarations, including any declared
950 <code>android:required</code> attribute, always take precedence over features
951 implied by the permissions below. </p>
953 <p>For any of the permissions below, you can disable filtering based on the
954 implied feature by explicitly declaring the implied feature explicitly, in a
955 <code><uses-feature></code> element, with an
956 <code>android:required="false"</code> attribute. For example, to disable any
957 filtering based on the <code>CAMERA</code> permission, you would add this
958 <code><uses-feature></code> declaration to the manifest file:</p>
960 <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre>
962 <table id="permissions-features" >
965 <th>This Permission...</th>
966 <th>Implies This Feature Requirement</th>
967 <!-- <th>Comments</th> -->
972 <td rowspan="2">Bluetooth</td>
973 <td><code>BLUETOOTH</code></td>
974 <td><code>android.hardware.bluetooth</code>
975 <p>(See <a href="#bt-permission-handling">Special handling for Bluetooth feature</a> for details.)</p></td>
979 <td><code>BLUETOOTH_ADMIN</code></td>
980 <td><code>android.hardware.bluetooth</code></td>
986 <td><code>CAMERA</code></td>
987 <td><code>android.hardware.camera</code> <em>and</em>
988 <br><code>android.hardware.camera.autofocus</code></td>
993 <td rowspan="5">Location</td>
994 <td><code>ACCESS_MOCK_LOCATION</code></td>
995 <td><code>android.hardware.location</code></td>
999 <td><code>ACCESS_LOCATION_EXTRA_COMMANDS</code></td>
1000 <td><code>android.hardware.location</code></td>
1004 <td><code>INSTALL_LOCATION_PROVIDER</code></td>
1005 <td><code>android.hardware.location</code></td>
1009 <td><code>ACCESS_COARSE_LOCATION</code></td>
1010 <td><code>android.hardware.location.network</code> <em>and</em>
1011 <br><code>android.hardware.location</code></td>
1015 <td><code>ACCESS_FINE_LOCATION</code></td>
1016 <td><code>android.hardware.location.gps</code> <em>and</em>
1017 <br><code>android.hardware.location</code></td>
1023 <td><code>RECORD_AUDIO</code></td>
1024 <td><code>android.hardware.microphone</code></td>
1029 <td rowspan="11">Telephony</td>
1030 <td><code>CALL_PHONE</code></td>
1031 <td><code>android.hardware.telephony</code></td>
1035 <td><code>CALL_PRIVILEGED</code></td>
1036 <td><code>android.hardware.telephony</code></td>
1041 <td><code>MODIFY_PHONE_STATE</code></td>
1042 <td><code>android.hardware.telephony</code></td>
1046 <td><code>PROCESS_OUTGOING_CALLS</code></td>
1047 <td><code>android.hardware.telephony</code></td>
1051 <td><code>READ_SMS</code></td>
1052 <td><code>android.hardware.telephony</code></td>
1056 <td><code>RECEIVE_SMS</code></td>
1057 <td><code>android.hardware.telephony</code></td>
1061 <td><code>RECEIVE_MMS</code></td>
1062 <td><code>android.hardware.telephony</code></td>
1066 <td><code>RECEIVE_WAP_PUSH</code></td>
1067 <td><code>android.hardware.telephony</code></td>
1071 <td><code>SEND_SMS</code></td>
1072 <td><code>android.hardware.telephony</code></td>
1076 <td><code>WRITE_APN_SETTINGS</code></td>
1077 <td><code>android.hardware.telephony</code></td>
1081 <td><code>WRITE_SMS</code></td>
1082 <td><code>android.hardware.telephony</code></td>
1087 <td rowspan="3">Wi-Fi</td>
1088 <td><code>ACCESS_WIFI_STATE</code></td>
1089 <td><code>android.hardware.wifi</code></td>
1093 <td><code>CHANGE_WIFI_STATE</code></td>
1094 <td><code>android.hardware.wifi</code></td>
1098 <td><code>CHANGE_WIFI_MULTICAST_STATE</code></td>
1099 <td><code>android.hardware.wifi</code></td>