| page.title=<uses-feature> |
| parent.title=The AndroidManifest.xml File |
| parent.link=manifest-intro.html |
| @jd:body |
| |
| <div id="qv-wrapper"> |
| <div id="qv"> |
| |
| |
| <h2>In this document</h2> |
| <ol> |
| <li><a href="#market-feature-filtering">Google Play and Feature-Based Filtering</a> |
| <ol> |
| <li><a href="#declared">Filtering based on explicitly declared features</a></li> |
| <li><a href="#implicit">Filtering based on implicit features</a></li> |
| <li><a href="#bt-permission-handling">Special handling for Bluetooth feature</a></li> |
| <li><a href="#testing">Testing the features required by your application</a></li> |
| </ol> |
| </li> |
| <li><a href="#features-reference">Features Reference</a> |
| <ol> |
| <li><a href="#hw-features">Hardware features</a></li> |
| <li><a href="#sw-features">Software features</a></li> |
| <li><a href="#permissions">Permissions that Imply Feature Requirements</a></li> |
| </ol> |
| </li> |
| </ol> |
| </div> |
| </div> |
| |
| |
| <dl class="xml"> |
| |
| <dt>syntax:</dt> |
| <dd> |
| <pre class="stx"><uses-feature android:<a href="#name">name</a>="<em>string</em>" |
| android:<a href="#required">required</a>=["true" | "false"] |
| android:<a href="#glEsVersion">glEsVersion</a>="<em>integer</em>" /></pre> |
| </dd> |
| |
| <dt>contained in:</dt> |
| <dd><code><a |
| href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a></code></dd> |
| |
| <div class="sidebox-wrapper"> |
| <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> |
| <div id="qv-sub-rule"> |
| <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> |
| <p style="color:#669999;padding-top:1em;">Google Play and <code style="color:#669999;"><uses-feature></code> elements</p> |
| <p style="margin-top:1em;">Google Play filters the applications that are visible to users, so |
| that users can see and download only those applications that are compatible with their |
| devices. One of the ways it filters applications is by feature compatibility.</p> |
| |
| <p style="margin-top:1em;">To do this, Google Play checks the |
| <code><uses-feature></code> elements in each application's manifest, to |
| establish the app's feature needs. Google Play then shows or hides the application to |
| each user, based on a comparison with the features available on the user's |
| device. </p> |
| |
| <p style="margin-top:1em;">By specifying the features that your application requires, |
| you enable Google Play to present your application only to users whose |
| devices meet the application's feature requirements, rather than presenting it |
| to all users. </p> |
| |
| <p style="margin-top:1em;" class="caution">For important information about how |
| Google Play uses features as the basis for filtering, please read <a |
| href="#market-feature-filtering">Google Play and Feature-Based Filtering</a>, |
| below.</p> |
| </div> |
| </div> |
| |
| <dt>description:</dt> |
| <dd>Declares a single hardware or software feature that is used by the |
| application. |
| |
| <p>The purpose of a <code><uses-feature></code> declaration is to inform |
| any external entity of the set of hardware and software features on which your |
| application depends. The element offers a <code>required</code> attribute that |
| lets you specify whether your application requires and cannot function without |
| the declared feature, or whether it prefers to have the feature but can function |
| without it. Because feature support can vary across Android devices, the |
| <code><uses-feature></code> element serves an important role in letting an |
| application describe the device-variable features that it uses.</p> |
| |
| <p>The set of available features that your application declares corresponds to |
| the set of feature constants made available by the Android {@link |
| android.content.pm.PackageManager}, which are listed for |
| convenience in the <a href="#features-reference">Features Reference</a> tables |
| at the bottom of this document. |
| |
| <p>You must specify each feature in a separate <code><uses-feature></code> |
| element, so if your application requires multiple features, it would declare |
| multiple <code><uses-feature></code> elements. For example, an application |
| that requires both Bluetooth and camera features in the device would declare |
| these two elements:</p> |
| |
| <pre> |
| <uses-feature android:name="android.hardware.bluetooth" /> |
| <uses-feature android:name="android.hardware.camera" /> |
| </pre> |
| |
| <p>In general, you should always make sure to declare |
| <code><uses-feature></code> elements for all of the features that your |
| application requires.</p> |
| |
| <p>Declared <code><uses-feature></code> elements are informational only, meaning |
| that the Android system itself does not check for matching feature support on |
| the device before installing an application. However, other services |
| (such as Google Play) or applications may check your application's |
| <code><uses-feature></code> declarations as part of handling or interacting |
| with your application. For this reason, it's very important that you declare all of |
| the features (from the list below) that your application uses. </p> |
| |
| <p>For some features, there may exist a specific attribute that allows you to define |
| a version of the feature, such as the version of Open GL used (declared with |
| <a href="#glEsVersion"><code>glEsVersion</code></a>). Other features that either do or do not |
| exist for a device, such as a camera, are declared using the |
| <a href="#name"><code>name</code></a> attribute.</p> |
| |
| |
| <p>Although the <code><uses-feature></code> element is only activated for |
| devices running API Level 4 or higher, it is recommended to include these |
| elements for all applications, even if the <a href="uses-sdk-element.html#min"><code>minSdkVersion</code></a> |
| is "3" or lower. Devices running older versions of the platform will simply |
| ignore the element.</p> |
| |
| <p class="note"><strong>Note:</strong> When declaring a feature, remember |
| that you must also request permissions as appropriate. For example, you must |
| still request the {@link android.Manifest.permission#CAMERA} |
| permission before your application can access the camera API. Requesting the |
| permission grants your application access to the appropriate hardware and |
| software, while declaring the features used by your application ensures proper |
| device compatibility.</p> |
| |
| </dd> |
| |
| |
| <dt>attributes:</dt> |
| |
| <dd> |
| <dl class="attr"> |
| |
| <dt><a name="name"></a><code>android:name</code></dt> |
| <dd>Specifies a single hardware or software feature used by the application, |
| as a descriptor string. Valid descriptor values are listed in the <a |
| href="#hw-features">Hardware features</a> and <a href="#sw-features">Software |
| features</a> tables, below. </dd> |
| |
| <dt><a name="required"></a><code>android:required</code></dt> <!-- added in api level 5 --> |
| <dd>Boolean value that indicates whether the application requires |
| the feature specified in <code>android:name</code>. |
| |
| <ul> |
| <li>When you declare <code>"android:required="true"</code> for a feature, |
| you are specifying that the application <em>cannot function, or is not |
| designed to function</em>, when the specified feature is not present on the |
| device. </li> |
| |
| <li>When you declare <code>"android:required="false"</code> for a feature, it |
| means that the application <em>prefers to use the feature</em> if present on |
| the device, but that it <em>is designed to function without the specified |
| feature</em>, if necessary. </li> |
| |
| </ul> |
| |
| <p>The default value for <code>android:required</code> if not declared is |
| <code>"true"</code>.</p> |
| </dd> |
| |
| <dt><a name="glEsVersion"></a><code>android:glEsVersion</code></dt> |
| <dd>The OpenGL ES version required by the application. The higher 16 bits |
| represent the major number and the lower 16 bits represent the minor number. For |
| example, to specify OpenGL ES version 2.0, you would set the value as |
| "0x00020000". To specify OpenGL ES 2.1, if/when such a version were made |
| available, you would set the value as "0x00020001". |
| |
| <p>An application should specify at most one <code>android:glEsVersion</code> |
| attribute in its manifest. If it specifies more than one, the |
| <code>android:glEsVersion</code> with the numerically highest value is used and |
| any other values are ignored.</p> |
| |
| <p>If an application does not specify an <code>android:glEsVersion</code> |
| attribute, then it is assumed that the application requires only OpenGL ES 1.0, |
| which is supported by all Android-powered devices.</p> |
| |
| <p>An application can assume that if a platform supports a given OpenGL ES |
| version, it also supports all numerically lower OpenGL ES versions. Therefore, |
| an application that requires both OpenGL ES 1.0 and OpenGL ES 2.0 must specify |
| that it requires OpenGL ES 2.0.</p> |
| |
| <p>An application that can work with any of several OpenGL ES versions should |
| only specify the numerically lowest version of OpenGL ES that it requires. (It |
| can check at run-time whether a higher level of OpenGL ES is available.)</p> |
| </dd> |
| |
| </dl> |
| </dd> |
| |
| <!-- ##api level indication## --> |
| <dt>introduced in:</dt> |
| <dd>API Level 4</dd> |
| |
| <dt>see also:</dt> |
| <dd> |
| <ul> |
| <li>{@link android.content.pm.PackageManager}</li> |
| <li>{@link android.content.pm.FeatureInfo}</li> |
| <li>{@link android.content.pm.ConfigurationInfo}</li> |
| <li><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><code><uses-permission></code></a></li> |
| <li><a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a></li> |
| </ul> |
| </dd> |
| |
| </dl> |
| |
| |
| <h2 id="market-feature-filtering">Google Play and Feature-Based Filtering</h2> |
| |
| <p>Google Play filters the applications that are visible to users, so that |
| users can see and download only those applications that are compatible with |
| their devices. One of the ways it filters applications is by feature |
| compatibility.</p> |
| |
| <p>To determine an application's feature compatibility with a given user's |
| device, Google Play compares:</p> |
| |
| <ul> |
| <li>Features required by the application — an application declares features in |
| <code><uses-feature></code> elements in its manifest <br/>with...</li> |
| <li>Features available on the device, in hardware or software — |
| a device reports the features it supports as read-only system properties.</li> |
| </ul> |
| |
| <p>To ensure an accurate comparison of features, the Android Package Manager |
| provides a shared set of feature constants that both applications and devices |
| use to declare feature requirements and support. The available feature constants |
| are listed in the <a href="#features-reference">Features Reference</a> tables at |
| the bottom of this document, and in the class documentation for {@link |
| android.content.pm.PackageManager}.</p> |
| |
| <p>When the user launches Google Play, the application queries the |
| Package Manager for the list of features available on the device by calling |
| {@link android.content.pm.PackageManager#getSystemAvailableFeatures()}. The |
| Store application then passes the features list up to Google Play |
| when establishing the session for the user.</p> |
| |
| <p>Each time you upload an application to the Google Play publisher site, |
| Google Play scans the application's manifest file. It looks for |
| <code><uses-feature></code> elements and evaluates them in combination |
| with other elements, in some cases, such as <code><uses-sdk></code> and |
| <code><uses-permission></code> elements. After establishing the |
| application's set of required features, it stores that list internally as |
| metadata associated with the application <code>.apk</code> and the application |
| version. </p> |
| |
| <p>When a user searches or browses for applications using the Google Play |
| application, the service compares the features needed by each application with |
| the features available on the user's device. If all of an application's required |
| features are present on the device, Google Play allows the user to see the |
| application and potentially download it. If any required feature is not |
| supported by the device, Google Play filters the application so that it is |
| not visible to the user and not available for download. </p> |
| |
| <p>Because the features you declare in <code><uses-feature></code> |
| elements directly affect how Google Play filters your application, it's |
| important to understand how Google Play evaluates the application's manifest |
| and establishes the set of required features. The sections below provide more |
| information. </p> |
| |
| <h3 id="declared">Filtering based on explicitly declared features</h3> |
| |
| <p>An explicitly declared feature is one that your application declares in a |
| <code><uses-feature></code> element. The feature declaration can include |
| an <code>android:required=["true" | "false"]</code> attribute (if you are |
| compiling against API level 5 or higher), which lets you specify whether the |
| application absolutely requires the feature and cannot function properly without |
| it (<code>"true"</code>), or whether the application prefers to use the feature |
| if available, but is designed to run without it (<code>"false"</code>).</p> |
| |
| <p>Google Play handles explicitly declared features in this way: </p> |
| |
| <ul> |
| <li>If a feature is explicitly declared as being required, Google Play adds |
| the feature to the list of required features for the application. It then |
| filters the application from users on devices that do not provide that feature. |
| For example: |
| <pre><uses-feature android:name="android.hardware.camera" android:required="true" /></pre></li> |
| <li>If a feature is explicitly declared as <em>not</em> being required, Google |
| Play <em>does not</em> add the feature to the list of required features. For |
| that reason, an explicitly declared non-required feature is never considered when |
| filtering the application. Even if the device does not provide the declared |
| feature, Google Play will still consider the application compatible with the |
| device and will show it to the user, unless other filtering rules apply. For |
| example: |
| <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre></li> |
| <li>If a feature is explicitly declared, but without an |
| <code>android:required</code> attribute, Google Play assumes that the feature |
| is required and sets up filtering on it. </li> |
| </ul> |
| |
| <p>In general, if your application is designed to run on Android 1.6 and earlier |
| versions, the <code>android:required</code> attribute is not available in the |
| API and Google Play assumes that any and all |
| <code><uses-feature></code> declarations are required. </p> |
| |
| <p class="note"><strong>Note:</strong> By declaring a feature explicitly and |
| including an <code>android:required="false"</code> attribute, you can |
| effectively disable all filtering on Google Play for the specified feature. |
| </p> |
| |
| |
| <h3 id="implicit">Filtering based on implicit features</h3> |
| |
| <p>An <em>implicit</em> feature is one that an application requires in order to |
| function properly, but which is <em>not</em> declared in a |
| <code><uses-feature></code> element in the manifest file. Strictly |
| speaking, every application should <em>always</em> declare all features that it |
| uses or requires, so the absence of a declaration for a feature used by an |
| application should be considered an error. However, as a safeguard for users and |
| developers, Google Play looks for implicit features in each application and |
| sets up filters for those features, just as it would do for an explicitly |
| declared feature. </p> |
| |
| <p>An application might require a feature but not declare it because: </p> |
| |
| <ul> |
| <li>The application was compiled against an older version of the Android library |
| (Android 1.5 or earlier) and the <code><uses-feature></code> element was |
| not available.</li> |
| <li>The developer incorrectly assumed that the feature would be present on all |
| devices and a declaration was unnecessary.</li> |
| <li>The developer omitted the feature declaration accidentally.</li> |
| <li>The developer declared the feature explicitly, but the declaration was not |
| valid. For example, a spelling error in the <code><uses-feature></code> |
| element name or an unrecognized string value for the |
| <code>android:name</code> attribute would invalidate the feature declaration. |
| </li> |
| </ul> |
| |
| <p>To account for the cases above, Google Play attempts to discover an |
| application's implied feature requirements by examining <em>other elements</em> |
| declared in the manifest file, specifically, |
| <code><uses-permission></code> elements.</p> |
| |
| <p>If an application requests hardware-related permissions, Google Play |
| <em>assumes that the application uses the underlying hardware features and |
| therefore requires those features</em>, even though there might be no |
| corresponding to <code><uses-feature></code> declarations. For such |
| permissions, Google Play adds the underlying hardware features to the |
| metadata that it stores for the application and sets up filters for them.</p> |
| |
| <p>For example, if an application requests the <code>CAMERA</code> permission |
| but does not declare a <code><uses-feature></code> element for |
| <code>android.hardware.camera</code>, Google Play considers that the |
| application requires a camera and should not be shown to users whose devices do |
| not offer a camera.</p> |
| |
| <p>If you don't want Google Play to filter based on a specific implied |
| feature, you can disable that behavior. To do so, declare the feature explicitly |
| in a <code><uses-feature></code> element and include an |
| <code>android:required="false"</code> attribute. For example, to disable |
| filtering derived from the <code>CAMERA</code> permission, you would declare |
| the feature as shown below.</p> |
| |
| <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre> |
| |
| <p class="caution">It's important to understand that the permissions that you |
| request in <code><uses-permission></code> elements can directly affect how |
| Google Play filters your application. The reference section <a |
| href="#permissions">Permissions that Imply Feature Requirements</a>, |
| below, lists the full set of permissions that imply feature requirements and |
| therefore trigger filtering.</p> |
| |
| <h3 id="bt-permission-handling">Special handling for Bluetooth feature</h3> |
| |
| <p>Google Play applies slightly different rules than described above, when |
| determining filtering for Bluetooth.</p> |
| |
| <p>If an application declares a Bluetooth permission in a |
| <code><uses-permission></code> element, but does not explicitly declare |
| the Bluetooth feature in a <code><uses-feature></code> element, Google |
| Play checks the version(s) of the Android platform on which the application is |
| designed to run, as specified in the <code><uses-sdk></code> element. </p> |
| |
| <p>As shown in the table below, Google Play enables filtering for the |
| Bluetooth feature only if the application declares its lowest or targeted |
| platform as Android 2.0 (API level 5) or higher. However, note that Google |
| Play applies the normal rules for filtering when the application explicitly |
| declares the Bluetooth feature in a <code><uses-feature></code> element. |
| </p> |
| |
| <p class="caption"><strong>Table 1.</strong> How Google Play determines the |
| Bluetooth feature requirement for an application that requests a Bluetooth |
| permission but does not declare the Bluetooth feature in a |
| <code><uses-feature></code> element.</p> |
| |
| <table style="margin-top:1em;"> |
| <tr> |
| <th><nobr>If <code>minSdkVersion</code> is ...</nobr></th> |
| <th><nobr>or <code>targetSdkVersion</code> is</nobr></th> |
| <th>Result</th> |
| </tr> |
| <tr> |
| <td><nobr><=4 (or uses-sdk is not declared)</nobr></td> |
| <td><=4</td> |
| <td>Google Play <em>will not</em> filter the application from any devices |
| based on their reported support for the <code>android.hardware.bluetooth</code> |
| feature.</td> |
| </tr> |
| <tr> |
| <td><=4</td> |
| <td>>=5</td> |
| <td rowspan="2">Google Play filters the application from any devices that |
| do not support the <code>android.hardware.bluetooth</code> feature (including |
| older releases).</td> |
| </tr> |
| <tr> |
| <td>>=5</td> |
| <td>>=5</td> |
| </tr> |
| </table> |
| |
| <p>The examples below illustrate the different filtering effects, based on how |
| Google Play handles the Bluetooth feature. </p> |
| |
| <dl> |
| <dt>In first example, an application that is designed to run on older API levels |
| declares a Bluetooth permission, but does not declare the Bluetooth feature in a |
| <code><uses-feature></code> element.</dt> |
| <dd><em>Result:</em> Google Play does not filter the application from any device.</dd> |
| </dl> |
| |
| <pre><manifest ...> |
| <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> |
| <uses-sdk android:minSdkVersion="3" /> |
| ... |
| </manifest></pre> |
| |
| <dl> |
| <dt>In the second example, below, the same application also declares a target |
| API level of "5". </dt> |
| <dd><em>Result:</em> Google Play now assumes that the feature is required and |
| will filter the application from all devices that do not report Bluetooth support, |
| including devices running older versions of the platform. </dd> |
| </dl> |
| |
| <pre><manifest ...> |
| <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> |
| <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> |
| ... |
| </manifest></pre> |
| |
| <dl> |
| <dt>Here the same application now specifically declares the Bluetooth feature.</dt> |
| <dd><em>Result:</em> Identical to the previous example (filtering is applied).</dd> |
| </dl> |
| |
| <pre><manifest ...> |
| <uses-feature android:name="android.hardware.bluetooth" /> |
| <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> |
| <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> |
| ... |
| </manifest></pre> |
| |
| <dl> |
| <dt>Finally, in the case below, the same application adds an |
| <code>android:required="false"</code> attribute.</dt> |
| <dd><em>Result:</em> Google Play disables filtering based on Bluetooth |
| feature support, for all devices.</dd> |
| </dl> |
| |
| <pre><manifest ...> |
| <uses-feature android:name="android.hardware.bluetooth" android:required="false" /> |
| <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> |
| <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> |
| ... |
| </manifest></pre> |
| |
| |
| |
| <h3 id="testing">Testing the features required by your application</h3> |
| |
| <p>You can use the <code>aapt</code> tool, included in the Android SDK, to |
| determine how Google Play will filter your application, based on its declared |
| features and permissions. To do so, run <code>aapt</code> with the <code>dump |
| badging</code> command. This causes <code>aapt</code> to parse your |
| application's manifest and apply the same rules as used by Google Play to |
| determine the features that your application requires. </p> |
| |
| <p>To use the tool, follow these steps: </p> |
| |
| <ol> |
| <li>First, build and export your application as an unsigned <code>.apk</code>. |
| If you are developing in Eclipse with ADT, right-click the project and select |
| <strong>Android Tools</strong> > <strong>Export Unsigned Application |
| Package</strong>. Select a destination filename and path and click |
| <strong>OK</strong>. </li> |
| <li>Next, locate the <code>aapt</code> tool, if it is not already in your PATH. |
| If you are using SDK Tools r8 or higher, you can find <code>aapt</code> in the |
| <code><<em>SDK</em>>/platform-tools/</code> directory. |
| <p class="note"><strong>Note:</strong> You must use the version of |
| <code>aapt</code> that is provided for the latest Platform-Tools component available. If |
| you do not have the latest Platform-Tools component, download it using the <a |
| href="{@docRoot}sdk/adding-components.html">Android SDK Manager</a>. |
| </p></li> |
| <li>Run <code>aapt</code> using this syntax: </li> |
| </ol> |
| |
| <pre>$ aapt dump badging <<em>path_to_exported_.apk</em>></pre> |
| |
| <p>Here's an example of the command output for the second Bluetooth example, above: </p> |
| |
| <pre>$ ./aapt dump badging BTExample.apk |
| package: name='com.example.android.btexample' versionCode='' versionName='' |
| <strong>uses-permission:'android.permission.BLUETOOTH_ADMIN'</strong> |
| <strong>uses-feature:'android.hardware.bluetooth'</strong> |
| sdkVersion:'3' |
| targetSdkVersion:'5' |
| application: label='BT Example' icon='res/drawable/app_bt_ex.png' |
| launchable activity name='com.example.android.btexample.MyActivity'label='' icon='' |
| uses-feature:'android.hardware.touchscreen' |
| main |
| supports-screens: 'small' 'normal' 'large' |
| locales: '--_--' |
| densities: '160' |
| </pre> |
| |
| |
| <h2 id=features-reference>Features Reference</h2> |
| |
| <p>The tables below provide reference information about hardware and software |
| features and the permissions that can imply them on Google Play. </p> |
| |
| <h3 id="hw-features">Hardware features</h3> |
| |
| <p>The table below describes the hardware feature descriptors supported by the |
| most current platform release. To signal that your application uses or requires |
| a hardware feature, declare each value in a <code>android:name</code> attribute |
| in a separate <code><uses-feature></code> element. </p> |
| |
| <table> |
| <tr> |
| <th>Feature Type</th> |
| <th>Feature Descriptor</th> |
| <th style="min-width:170px">Description</th> |
| <th>Comments</th> |
| </tr> |
| <tr> |
| <td>Audio</td> |
| <td><code>android.hardware.audio.low_latency</td> |
| <td>The application uses a low-latency audio pipeline on the device and |
| is sensitive to delays or lag in sound input or output.</td> |
| <td> |
| </td> |
| </tr> |
| <tr> |
| <td>Bluetooth</td> |
| <td><code>android.hardware.bluetooth</td> |
| <td>The application uses Bluetooth radio features in the device.</td> |
| <td> |
| </td> |
| </tr> |
| <tr> |
| <td rowspan="4">Camera</td> |
| <td><code>android.hardware.camera</code></td> |
| <td>The application uses the device's camera. If the device supports |
| multiple cameras, the application uses the camera that facing |
| away from the screen.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.camera.autofocus</code></td> |
| <td>Subfeature. The application uses the device camera's autofocus capability.</td> |
| <td rowspan="3">These subfeatures implicitly declare the |
| <code>android.hardware.camera</code> parent feature, unless declared with |
| <code>android:required="false"</code>.</td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.camera.flash</code></td> |
| <td>Subfeature. The application uses the device camera's flash.</td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.camera.front</code></td> |
| <td>Subfeature. The application uses a front-facing camera on the device.</td> |
| </tr> |
| |
| <tr> |
| <td rowspan="3">Location</td> |
| <td><code>android.hardware.location</code></td> |
| <td>The application uses one or more features on the device for determining |
| location, such as GPS location, network location, or cell location.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.location.network</code></td> |
| <td>Subfeature. The application uses coarse location coordinates obtained from |
| a network-based geolocation system supported on the device.</td> |
| <td rowspan="2">These subfeatures implicitly declare the |
| <code>android.hardware.location</code> parent feature, unless declared with |
| <code>android:required="false"</code>. </td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.location.gps</code></td> |
| <td>Subfeature. The application uses precise location coordinates obtained |
| from a Global Positioning System receiver on the device. </td> |
| </tr> |
| <tr> |
| <td>Microphone</td> |
| <td><code>android.hardware.microphone</code></td> |
| <td>The application uses a microphone on the device. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td>NFC</td> |
| <td><code>android.hardware.nfc</td> |
| <td>The application uses Near Field Communications radio features in the device.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td rowspan="6">Sensors</td> |
| <td><code>android.hardware.sensor.accelerometer</code></td> |
| <td>The application uses motion readings from an accelerometer on the |
| device.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.sensor.barometer</code></td> |
| <td>The application uses the device's barometer.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.sensor.compass</code></td> |
| <td>The application uses directional readings from a magnetometer (compass) on |
| the device.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.sensor.gyroscope</code></td> |
| <td>The application uses the device's gyroscope sensor.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.sensor.light</code></td> |
| <td>The application uses the device's light sensor.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.sensor.proximity</code></td> |
| <td>The application uses the device's proximity sensor.</td> |
| <td></td> |
| </tr> |
| |
| <tr> |
| <td rowspan="2">Screen</td> |
| <td><code>android.hardware.screen.landscape</code></td> |
| <td>The application requires landscape orientation.</td> |
| <td rowspan="2"> |
| <p>For example, if your app requires portrait orientation, you should declare |
| <code><uses-feature android:name="android.hardware.screen.portrait"/></code> so that only devices |
| that support portrait orientation (whether always or by user choice) can install your app. If your |
| application <em>supports</em> both orientations, then you don't need to declare either.</p> |
| <p>Both orientations are assumed <em>not required</em>, by default, so your app may be installed |
| on devices that support one or both orientations. However, if any of your activities request that |
| they run in a specific orientation, using the <a |
| href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code |
| android:screenOrientation}</a> attribute, then this also declares that the application requires that |
| orientation. For example, if you declare <a |
| href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code |
| android:screenOrientation}</a> with either {@code "landscape"}, {@code "reverseLandscape"}, or |
| {@code "sensorLandscape"}, then your application will be available only to devices that support |
| landscape orientation. As a best practice, you should still declare your requirement for this |
| orientation using a {@code <uses-feature>} element. If you declare an orientation for your |
| activity using <a href="{@docRoot}guide/topics/manifest/activity-element.html#screen">{@code |
| android:screenOrientation}</a>, but don't actually <em>require</em> it, you can disable the |
| requirement by declaring the orientation with a {@code <uses-feature>} element and include |
| {@code android:required="false"}.</p> |
| <p>For backwards compatibility, any device running a platform version that supports only API |
| level 12 or lower is assumed to support both landscape and portrait.</p> |
| </td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.screen.portrait</code></td> |
| <td>The application requires portrait orientation.</td> |
| </tr> |
| |
| <tr> |
| <td rowspan="3">Telephony</td> |
| <td><code>android.hardware.telephony</code></td> |
| <td>The application uses telephony features on the device, such as telephony |
| radio with data communication services.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.telephony.cdma</code></td> |
| <td>Subfeature. The application uses CDMA telephony radio features on the |
| device. </td> |
| <td rowspan="2">These subfeatures implicitly declare the |
| <code>android.hardware.telephony</code> parent feature, unless declared with |
| <code>android:required="false"</code>. </td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.telephony.gsm</code></td> |
| <td>Subfeature. The application uses GSM telephony radio features on the |
| device.</td> |
| </tr> |
| |
| <tr> |
| <td rowspan="7">Touchscreen</td> |
| <td><code>android.hardware.faketouch</code></td> |
| <td>The application uses basic touch interaction events, such as "click down", "click |
| up", and drag.</td> |
| <td><p>When declared as required, this indicates that the application is compatible with a device |
| only if it offers an emulated touchscreen ("fake touch" interface), or better. A device that offers |
| a fake touch interface provides a user input system that emulates a subset of touchscreen |
| capabilities. For example, a mouse or remote control that drives an on-screen cursor provides a fake |
| touch interface. If your application requires basic point and click interaction (in other |
| words, it won't work with <em>only</em> a d-pad controller), you should declare this feature. |
| Because this is the minimum level of touch interaction, your app will also be compatible with |
| devices that offer more complex touch interfaces.</p> |
| <p class="note"><strong>Note:</strong> Because applications require the {@code |
| android.hardware.touchscreen} feature by default, if you want your application to be available to |
| devices that provide a fake touch interface, you must also explicitly declare that a touch screen is |
| <em>not</em> required by declaring {@code <uses-feature |
| android:name="android.hardware.touchscreen" <strong>android:required="false"</strong> |
| />}</p></td> |
| </tr> |
| |
| <tr> |
| <td><code>android.hardware.faketouch.multitouch.distinct</code></td> |
| <td>The application performs distinct tracking of two or more "fingers" on a fake touch |
| interface. This is a superset of the faketouch feature.</td> |
| <td><p>When declared as required, this indicates that the application is compatible with a device |
| only if it supports touch emulation for events that supports distinct tracking of two or more |
| fingers, or better.</p> |
| <p>Unlike the distinct multitouch defined by {@code |
| android.hardware.touchscreen.multitouch.distinct}, input devices that support distinct multi-touch |
| with a fake touch interface will not support all two-finger gestures, because the input is |
| being transformed to cursor movement on the screen. That is, single finger gestures on such a device |
| move a cursor; two-finger swipes will result in single-finger touch events; other two-finger |
| gestures will result in the corresponding two-finger touch event. An example device that supports |
| distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement |
| which also supports two or more fingers.</p></td> |
| </tr> |
| |
| <tr> |
| <td><code>android.hardware.faketouch.multitouch.jazzhand</code></td> |
| <td>The application performs distinct tracking of five or more "fingers" on a fake touch |
| interface. This is a superset of the faketouch feature.</td> |
| <td><p>When declared as required, this indicates that the application is compatible with a device |
| only if it supports touch emulation for events that supports distinct tracking of five or more |
| fingers.</p> |
| <p>Unlike the distinct multitouch defined by {@code |
| android.hardware.touchscreen.multitouch.jazzhand}, input devices that support jazzhand multi-touch |
| with a fake touch interface will not support all five-finger gestures, because the input is being |
| transformed to cursor movement on the screen. That is, single finger gestures on such a device move |
| a cursor; multi-finger gestures will result in single-finger touch events; other multi-finger |
| gestures will result in the corresponding multi-finger touch event. An example device that supports |
| distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement |
| which also supports five or more fingers.</p></td> |
| </tr> |
| |
| <tr> |
| <td><code>android.hardware.touchscreen</code></td> |
| <td>The application uses touchscreen capabilities for gestures that are more interactive |
| than basic touch events, such as a fling. This is a superset of the basic faketouch feature.</td> |
| <td><p>By default, your application requires this. As such, your application is <em>not</em> |
| available to devices that provide only an emulated touch interface ("fake touch"), by default. If |
| you want your application available to devices that provide a fake touch interface (or even devices |
| that provide only a d-pad controller), you must explicitly declare that a touch screen is not |
| required, by declaring {@code android.hardware.touchscreen} with {@code android:required="false"}. |
| You should do so even if your application uses—but does not <em>require</em>—a real |
| touch screen interface.</p> |
| <p>If your application <em>does require</em> a touch interface (in order to perform touch |
| gestures such as a fling), then you don't need to do anything, because this is required by default. |
| However, it's best if you explicitly declare all features used by your application, so you should |
| still declare this if your app uses it.</p> |
| <p>If you require more complex touch interaction, such as multi-finger gestures, you |
| should declare the advanced touch screen features below.</p></td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.touchscreen.multitouch</code></td> |
| <td>The application uses basic two-point multitouch capabilities on the device |
| screen, such as for pinch gestures, but does not need to track touches independently. This |
| is a superset of touchscreen feature.</td> |
| <td>This implicitly declares the <code>android.hardware.touchscreen</code> parent feature, unless |
| declared with <code>android:required="false"</code>. </td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.touchscreen.multitouch.distinct</code></td> |
| <td>Subfeature. The application uses advanced multipoint multitouch |
| capabilities on the device screen, such as for tracking two or more points fully |
| independently. This is a superset of multitouch feature.</td> |
| <td rowspan="2">This implicitly declares the <code>android.hardware.touchscreen.multitouch</code> |
| parent feature, unless declared with <code>android:required="false"</code>. </td> |
| </tr> |
| <tr> |
| <td><code>android.hardware.touchscreen.multitouch.jazzhand</code></td> |
| <td>The application uses advanced multipoint multitouch |
| capabilities on the device screen, for tracking up to five points fully |
| independently. This is a superset of distinct multitouch feature.</td> |
| </tr> |
| |
| <tr> |
| <td rowspan="2">USB</td> |
| <td><code>android.hardware.usb.host</code></td> |
| <td>The application uses USB host mode features (behaves as the host and connects to USB |
| devices).</td> |
| <td></td> |
| </tr> |
| |
| <tr> |
| <td><code>android.hardware.usb.accessory</code></td> |
| <td>The application uses USB accessory features (behaves as the USB device and connects to USB |
| hosts).</td> |
| <td></td> |
| </tr> |
| |
| <tr> |
| <td>Wifi</td> |
| <td><code>android.hardware.wifi</code></td> |
| <td>The application uses 802.11 networking (wifi) features on the device.</td> |
| <td></td> |
| </tr> |
| |
| </table> |
| |
| <h3 id="sw-features">Software features</h3> |
| |
| <p>The table below describes the software feature descriptors supported by the |
| most current platform release. To signal that your application uses or requires |
| a software feature, declare each value in a <code>android:name</code> attribute |
| in a separate <code><uses-feature></code> element. </p> |
| |
| |
| <table> |
| <tr> |
| <th>Feature</th> |
| <th>Attribute Value</th> |
| <th>Description</th> |
| <th>Comments</th> |
| </tr> |
| <tr> |
| <td>Live Wallpaper</td> |
| <td><code>android.software.live_wallpaper</code></td> |
| <td>The application uses or provides Live Wallpapers.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td rowspan="2">SIP/VOIP</td> |
| <td><code>android.software.sip</code></td> |
| <td>The application uses SIP service on the device. |
| </td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><code>android.software.sip.voip</code></td> |
| <td>Subfeature. The application uses SIP-based VOIP service on the device. |
| </td> |
| <td>This subfeature implicitly declares the <code>android.software.sip</code> parent feature, |
| unless declared with <code>android:required="false"</code>.</td> |
| </tr> |
| </table> |
| |
| |
| <h3 id="permissions">Permissions that Imply Feature Requirements</h3> |
| |
| <p>Some feature constants listed in the tables above were made available to |
| applications <em>after</em> the corresponding API; for example, the |
| <code>android.hardware.bluetooth</code> feature was added in Android 2.2 (API |
| level 8), but the bluetooth API that it refers to was added in Android 2.0 (API |
| level 5). Because of this, some apps were able to use the API before they had |
| the ability to declare that they require the API via the |
| <code><uses-feature></code> system. </p> |
| |
| <p>To prevent those apps from being made available unintentionally, Google |
| Play assumes that certain hardware-related permissions indicate that the |
| underlying hardware features are required by default. For instance, applications |
| that use Bluetooth must request the <code>BLUETOOTH</code> permission in a |
| <code><uses-permission></code> element — for legacy apps, Google |
| Play assumes that the permission declaration means that the underlying |
| <code>android.hardware.bluetooth</code> feature is required by the application |
| and sets up filtering based on that feature. </p> |
| |
| <p>The table below lists permissions that imply feature requirements |
| equivalent to those declared in <code><uses-feature></code> elements. Note |
| that <code><uses-feature></code> declarations, including any declared |
| <code>android:required</code> attribute, always take precedence over features |
| implied by the permissions below. </p> |
| |
| <p>For any of the permissions below, you can disable filtering based on the |
| implied feature by explicitly declaring the implied feature explicitly, in a |
| <code><uses-feature></code> element, with an |
| <code>android:required="false"</code> attribute. For example, to disable any |
| filtering based on the <code>CAMERA</code> permission, you would add this |
| <code><uses-feature></code> declaration to the manifest file:</p> |
| |
| <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre> |
| |
| <table id="permissions-features" > |
| <tr> |
| <th>Category</th> |
| <th>This Permission...</th> |
| <th>Implies This Feature Requirement</th> |
| <!-- <th>Comments</th> --> |
| </tr> |
| |
| |
| <tr> |
| <td rowspan="2">Bluetooth</td> |
| <td><code>BLUETOOTH</code></td> |
| <td><code>android.hardware.bluetooth</code> |
| <p>(See <a href="#bt-permission-handling">Special handling for Bluetooth feature</a> for details.)</p></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>BLUETOOTH_ADMIN</code></td> |
| <td><code>android.hardware.bluetooth</code></td> |
| <!-- <td></td> --> |
| </tr> |
| |
| <tr> |
| <td>Camera</td> |
| <td><code>CAMERA</code></td> |
| <td><code>android.hardware.camera</code> <em>and</em> |
| <br><code>android.hardware.camera.autofocus</code></td> |
| <!-- <td></td> --> |
| </tr> |
| |
| <tr> |
| <td rowspan="5">Location</td> |
| <td><code>ACCESS_MOCK_LOCATION</code></td> |
| <td><code>android.hardware.location</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>ACCESS_LOCATION_EXTRA_COMMANDS</code></td> |
| <td><code>android.hardware.location</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>INSTALL_LOCATION_PROVIDER</code></td> |
| <td><code>android.hardware.location</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>ACCESS_COARSE_LOCATION</code></td> |
| <td><code>android.hardware.location.network</code> <em>and</em> |
| <br><code>android.hardware.location</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>ACCESS_FINE_LOCATION</code></td> |
| <td><code>android.hardware.location.gps</code> <em>and</em> |
| <br><code>android.hardware.location</code></td> |
| <!-- <td></td> --> |
| </tr> |
| |
| <tr> |
| <td>Microphone</td> |
| <td><code>RECORD_AUDIO</code></td> |
| <td><code>android.hardware.microphone</code></td> |
| <!-- <td></td> --> |
| </tr> |
| |
| <tr> |
| <td rowspan="11">Telephony</td> |
| <td><code>CALL_PHONE</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>CALL_PRIVILEGED</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| |
| <tr> |
| <td><code>MODIFY_PHONE_STATE</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>PROCESS_OUTGOING_CALLS</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>READ_SMS</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>RECEIVE_SMS</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>RECEIVE_MMS</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>RECEIVE_WAP_PUSH</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>SEND_SMS</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>WRITE_APN_SETTINGS</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>WRITE_SMS</code></td> |
| <td><code>android.hardware.telephony</code></td> |
| <!-- <td></td> --> |
| </tr> |
| |
| <tr> |
| <td rowspan="3">Wifi</td> |
| <td><code>ACCESS_WIFI_STATE</code></td> |
| <td><code>android.hardware.wifi</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>CHANGE_WIFI_STATE</code></td> |
| <td><code>android.hardware.wifi</code></td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>CHANGE_WIFI_MULTICAST_STATE</code></td> |
| <td><code>android.hardware.wifi</code></td> |
| <!-- <td></td> --> |
| </tr> |
| </table> |