| page.title=<uses-feature> |
| page.tags=filtering,features,google play filters,permissions |
| @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> |
| |
| <div class="sidebox-wrapper"> |
| <div class="sidebox"> |
| <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> |
| <p style="color:#669999;padding-top:1em;">Google Play Filtering</p> |
| <p style="padding-top:1em;">Google Play uses the <code><uses-feature></code> |
| elements declared in your app manifest to filter your app from devices |
| that do not meet its hardware and software feature requirements. </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>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> |
| |
| <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> |
| |
| <dt>description:</dt> |
| <dd itemprop="description">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> sections |
| 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 attribute values are listed in the <a href= |
| "#hw-features">Hardware features</a> and <a href="#sw-features">Software |
| features</a> sections. These attribute values are case-sensitive. |
| </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", or to specify OpenGL ES 3.2, you would set the value as "0x00030002". |
| |
| <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> |
| |
| <p>For more information about using OpenGL ES, including how to check the supported OpenGL ES |
| version at runtime, see the <a href="{@docRoot}guide/topics/graphics/opengl.html">OpenGL ES |
| API guide</a>.</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}google/play/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> sections 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 Developer Console, |
| 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> 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 Android Studio, build your application with Gradle: |
| <ol TYPE=a> |
| <li>Open the project and select <strong>Run > Edit Configurations</strong>. |
| <li>Select the plus sign near the top-left corner of the <strong>Run/Debug |
| Configurations</strong> window. |
| <li>Select <strong>Gradle.</strong> |
| <li>Enter <code>Unsigned APK</code> in <strong>Name</strong>. |
| <li>Choose your module from the <strong>Gradle project</strong> section. |
| <li>Enter <code>assemble</code> in <strong>Tasks</strong>. |
| <li>Select <strong>OK</strong> to complete the new configuration. |
| <li>Make sure the <strong>Unsigned APK</strong> run configuration is selected |
| in the toolbar and select <strong>Run > Run 'Unsigned APK'</strong>.</li> |
| </ol> |
| You can find your unsigned <code>.apk</code> in the |
| <code><<em>ProjectName</em>>/app/build/outputs/apk/</code> directory. |
| |
| <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>>/build-tools/<<em>tools version number</em>></code> |
| directory. |
| <p class="note"><strong>Note:</strong> You must use the version of |
| <code>aapt</code> that is provided for the latest Build-Tools component available. If |
| you do not have the latest Build-Tools component, download it using the <a |
| href="{@docRoot}studio/intro/update.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 following sections provide reference information about hardware features, |
| software features, and sets of permissions that imply specific feature |
| requirements. |
| </p> |
| |
| <h3 id="hw-features"> |
| Hardware features |
| </h3> |
| |
| <p> |
| This section presents the hardware features supported by the most current |
| platform release. To indicate that your app uses or requires a hardware |
| feature, declare the corresponding value (beginning with |
| <code>"android.hardware"</code>) in an <code>android:name</code> attribute. |
| Each time you declare a hardware feature, use a separate |
| <code><uses-feature></code> element. |
| </p> |
| |
| <h4 id="audio-hw-features"> |
| Audio hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.audio.low_latency</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's low-latency audio pipeline, which reduces lag and |
| delays when processing sound input or output. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.audio.output</code> |
| </dt> |
| |
| <dd> |
| The app transmits sound using the device's speakers, audio jack, Bluetooth |
| streaming capabilities, or a similar mechanism. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.audio.pro</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's high-end audio functionality and performance |
| capabilities. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.microphone</code> |
| </dt> |
| |
| <dd> |
| The app records audio using the device's microphone. |
| </dd> |
| </dl> |
| |
| <h4 id="bluetooth-hw-features"> |
| Bluetooth hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.bluetooth</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's Bluetooth features, usually to communicate with |
| other Bluetooth-enabled devices. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.bluetooth_le</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's Bluetooth Low Energy radio features. |
| </dd> |
| </dl> |
| |
| <h4 id="camera-hw-features"> |
| Camera hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.camera</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's back-facing camera. Devices with only a |
| front-facing camera do not list this feature, so use the |
| <code>android.hardware.camera.any</code> feature instead if your app can |
| communicate with any camera, regardless of which direction the camera |
| faces. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.any</code> |
| </dt> |
| |
| <dd> |
| The app uses one of the device's cameras, or an external camera that the |
| user connects to the device. Use this value instead of |
| <code>android.hardware.camera</code> if your app does not require the |
| camera to be a back-facing one. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.autofocus</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the autofocus feature that the device's camera supports. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.camera</code> feature, unless this parent feature |
| is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.capability.manual_post_processing</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the <code>MANUAL_POST_PROCESSING</code> feature that the |
| device's camera supports. |
| </p> |
| |
| <p> |
| This feature allows your app to override the camera's auto white balance |
| functionality. Use <code>android.colorCorrection.transform</code>, |
| <code>android.colorCorrection.gains</code>, and an |
| <code>android.colorCorrection.mode</code> of |
| <code>TRANSFORM_MATRIX</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.capability.manual_sensor</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the <code>MANUAL_SENSOR</code> feature that the device's |
| camera supports. |
| </p> |
| |
| <p> |
| This feature implies support for auto-exposure locking |
| (<code>android.control.aeLock</code>), which allows the camera's exposure |
| time and sensitivity to remain fixed at specific values. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.capability.raw</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the <code>RAW</code> feature that the device's camera |
| supports. |
| </p> |
| |
| <p> |
| This feature implies that the device can save DNG (raw) files and that |
| the device's camera provides the DNG-related metadata necessary for your |
| app to process these raw images directly. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.external</code> |
| </dt> |
| |
| <dd> |
| The app communicates with an external camera that the user connects to the |
| device. This feature does not guarantee, however, that the external camera |
| is available for your app to use. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.flash</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the flash feature that the device's camera supports. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.camera</code> feature, unless this parent feature |
| is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.front</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the device's front-facing camera. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.camera</code> feature, unless this parent feature |
| is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.camera.level.full</code> |
| </dt> |
| |
| <dd> |
| The app uses the <code>FULL</code>-level image-capturing support that at |
| least one of the device's cameras provides. Cameras with <code>FULL</code> |
| support provide burst-capture capabilities, per-frame control, and manual |
| post-processing control. |
| </dd> |
| </dl> |
| |
| <h4 id="device-ui-hw-features"> |
| Device UI hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.type.automotive</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app is designed to show its UI on a set of screens inside a vehicle. |
| The user interacts with the app using hard buttons, touch, rotary |
| controllers, and mouse-like interfaces. The vehicle's screens usually |
| appear in the center console or the instrument cluster of a vehicle. These |
| screens usually have limited size and resolution. |
| </p> |
| |
| <p class="note"> |
| <strong>Note: </strong>It's important to keep in mind that, since the user |
| is driving while using this type of app UI, the app must minimize driver |
| distraction. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.type.television</code> |
| </dt> |
| |
| <dd> |
| <p> |
| (Deprecated; use <a href="#media-sw-features"> |
| <code>android.software.leanback</code></a> instead.) |
| </p> |
| |
| <p> |
| The app is designed to show its UI on a television. This feature defines |
| "television" to be a typical living room television experience: displayed |
| on a big screen, where the user is sitting far away and the dominant form |
| of input is something like a d-pad, and generally not using a mouse, |
| pointer, or touch device. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.type.watch</code> |
| </dt> |
| |
| <dd> |
| The app is designed to show its UI on a watch. A watch is worn on the body, |
| such as on the wrist. The user is very close to the device while |
| interacting with it. |
| </dd> |
| </dl> |
| |
| <h4 id="fingerprint-hw-features"> |
| Fingerprint hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.fingerprint</code> |
| </dt> |
| |
| <dd> |
| The app reads fingerprints using the device's biometric hardware. |
| </dd> |
| </dl> |
| |
| <h4 id="gamepad-hw-features"> |
| Gamepad hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.gamepad</code> |
| </dt> |
| |
| <dd> |
| The app captures game controller input, either from the device itself or |
| from a connected gamepad. |
| </dd> |
| </dl> |
| |
| <h4 id="infrared-hw-features"> |
| Infrared hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.consumerir</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's infrared (IR) capabilities, usually to |
| communicate with other consumer IR devices. |
| </dd> |
| </dl> |
| |
| <h4 id="location-hw-features"> |
| Location hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.location</code> |
| </dt> |
| |
| <dd> |
| The app uses one or more features on the device for determining location, |
| such as GPS location, network location, or cell location. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.location.gps</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses precise location coordinates obtained from a Global |
| Positioning System (GPS) receiver on the device. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.location</code> feature, unless this parent |
| feature is declared with the attribute |
| <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.location.network</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses coarse location coordinates obtained from a network-based |
| geolocation system supported on the device. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.location</code> feature, unless this parent |
| feature is declared with the attribute |
| <code>android:required="false"</code>. |
| </p> |
| </dd> |
| </dl> |
| |
| <h4 id="nfc-hw-features"> |
| NFC hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.nfc</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's Near-Field Communication (NFC) radio features. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.nfc.hce</code> |
| </dt> |
| |
| <dd> |
| <p> |
| (Deprecated.) |
| </p> |
| |
| <p> |
| The app uses NFC card emulation that is hosted on the device. |
| </p> |
| </dd> |
| </dl> |
| |
| <h4 id="opengl-es-hw-features"> |
| OpenGL ES hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.opengles.aep</code> |
| </dt> |
| |
| <dd> |
| The app uses the <a href= |
| "http://www.khronos.org/registry/gles/extensions/ANDROID/ANDROID_extension_pack_es31a.txt" |
| class="external-link">OpenGL ES Android Extension Pack</a>that is installed |
| on the device. |
| </dd> |
| </dl> |
| |
| <h4 id="sensor-hw-features"> |
| Sensor hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.sensor.accelerometer</code> |
| </dt> |
| |
| <dd> |
| The app uses motion readings from the device's accelerometer to detect |
| the device's current orientation. For example, an app could use |
| accelerometer readings to determine when to switch between portrait and |
| landscape orientations. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.ambient_temperature</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's ambient (environmental) temperature sensor. For |
| example, a weather app could report indoor or outdoor temperature. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.barometer</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's barometer. For example, a weather app could |
| report air pressure. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.compass</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's magnetometer (compass). For example, a navigation |
| app could show the current direction a user faces. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.gyroscope</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's gyroscope to detect rotation and twist, creating |
| a six-axis orientation system. By using this sensor, an app can detect more |
| smoothly whether it needs to switch between portrait and landscape |
| orientations. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.hifi_sensors</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's high fidelity (Hi-Fi) sensors. For example, a |
| gaming app could detect the user's high-precision movements. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.heartrate</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's heart rate monitor. For example, a fitness app |
| could report trends in a user's heart rate over time. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.heartrate.ecg</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's elcardiogram (ECG) heart rate sensor. For |
| example, a fitness app could report more detailed information about a |
| user's heart rate. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.light</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's light sensor. For example, an app could display |
| one of two different color schemes based on the ambient lighting |
| conditions. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.proximity</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's proximity sensor. For example, a telephony app |
| could turn off the device's screen when the app detects that the user is |
| holding the device close to their body. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.relative_humidity</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's relative humidity sensor. For example, a weather |
| app could use the humidity to calculate and report the current dewpoint. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.stepcounter</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's step counter. For example, a fitness app could |
| report the number of steps a user needs to take to achieve their daily step |
| count goal. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.sensor.stepdetector</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's step detector. For example, a fitness app could |
| use the time interval between steps to infer the type of exercise that the |
| user is doing. |
| </dd> |
| </dl> |
| |
| <h4 id="screen-hw-features"> |
| Screen hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.screen.landscape</code> |
| </dt> |
| |
| <dt> |
| <code>android.hardware.screen.portrait</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app requires the device to use the portrait or landscape orientation. |
| If your app supports both orientations, then you don't need to declare |
| either feature. |
| </p> |
| |
| <p> |
| For example, if your app requires portrait orientation, you should |
| declare the following feature so that only the devices that support |
| portrait orientation (always or by user choice) can run your app: |
| </p> |
| <pre><uses-feature android:name="android.hardware.screen.portrait" /></pre> |
| |
| <p> |
| Both orientations are assumed not required 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 declaration implies |
| that your app 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 app will be |
| available only on devices that support landscape orientation. |
| </p> |
| |
| <p> |
| 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 require 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 backward compatibility, any device running Android 3.1 (API level 12) |
| or lower supports both landscape and portrait orientations. |
| </p> |
| </dd> |
| </dl> |
| |
| <h4 id="telephony-hw-features"> |
| Telephony hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.telephony</code> |
| </dt> |
| |
| <dd> |
| The app uses the device's telephony features, such as telephony radio with |
| data communication services. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.telephony.cdma</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the Code Division Multiple Access (CDMA) telephony radio |
| system. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.telephony</code> feature, unless this parent |
| feature is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.telephony.gsm</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the Global System for Mobile Communications (GSM) telephony |
| radio system. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.telephony</code> feature, unless this parent |
| feature is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| </dl> |
| |
| <h4 id="touchscreen-hw-features"> |
| Touchscreen hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.faketouch</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses basic touch interaction events, such as tapping and |
| dragging. |
| </p> |
| |
| <p> |
| When declared as required, this feature indicates that the app is |
| compatible with a device only if that device emulates a touchscreen |
| ("fake touch" interface) or has an actual touchscreen. |
| </p> |
| |
| <p> |
| A device that offers a fake touch interface provides a user input system |
| that emulates a subset of a touchscreen's capabilities. For example, a |
| mouse or remote control could drive an on-screen cursor. If your app |
| requires basic point and click interaction (in other words, it won't work |
| with only a d-pad controller), you should declare this feature. Because |
| this is the minimum level of touch interaction, you can also use an app |
| that declares this feature on devices that offer more complex touch |
| interfaces. |
| </p> |
| |
| <p class="note"> |
| <strong>Note:</strong> Apps require the {@code android.hardware.touchscreen} |
| feature by default. If you want your app to be available to devices that |
| provide a fake touch interface, you must also explicitly declare that a |
| touchscreen is not required as follows: |
| </p> |
| <pre><uses-feature android:name="android.hardware.touchscreen" <strong>android:required="false"</strong> /></pre> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.faketouch.multitouch.distinct</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app tracks two or more distinct "fingers" on a fake touch interface. |
| This is a superset of the <code>android.hardware.faketouch</code> |
| feature. When declared as required, this feature indicates that the app |
| is compatible with a device only if that device emulates distinct |
| tracking of two or more fingers or has an actual touchscreen. |
| </p> |
| |
| <p> |
| Unlike the distinct multitouch defined by {@code |
| android.hardware.touchscreen.multitouch.distinct}, input devices that |
| support distinct multitouch with a fake touch interface don't support all |
| two-finger gestures because the input in transformed to cursor movement |
| on the screen. That is, single-finger gestures on such a device move a |
| cursor, two-finger swipes cause single-finger touch events to occur, and |
| other two-finger gestures trigger the corresponding two-finger touch |
| events. |
| </p> |
| |
| <p> |
| A device that provides a two-finger touch trackpad for cursor movement |
| can support this feature. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.faketouch.multitouch.jazzhand</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app tracks five or more distinct "fingers" on a fake touch interface. |
| This is a superset of the <code>android.hardware.faketouch</code> |
| feature. When declared as required, this feature indicates that the app |
| is compatible with a device only if that device emulates distinct |
| tracking of five or more fingers or has an actual touchscreen. |
| </p> |
| |
| <p> |
| Unlike the distinct multitouch defined by {@code |
| android.hardware.touchscreen.multitouch.jazzhand}, input devices that |
| support jazzhand multitouch with a fake touch interface don't support all |
| five-finger gestures because the input in transformed to cursor movement |
| on the screen. That is, single-finger gestures on such a device move a |
| cursor, multi-finger gestures cause single-finger touch events to occur, |
| and other multi-finger gestures trigger the corresponding multi-finger |
| touch events. |
| </p> |
| |
| <p> |
| A device that provides a five-finger touch trackpad for cursor movement |
| can support this feature. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.touchscreen</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the device's touchscreen capabilities for gestures that are |
| more interactive than basic touch events, such as a fling. This is a |
| superset of the <code>android.hardware.faketouch</code> feature. |
| </p> |
| |
| <p> |
| By default, your app requires this feature. As such, your app is not |
| available to devices that provide only an emulated touch interface ("fake |
| touch") by default. If you want to make your app available on devices |
| that provide a fake touch interface (or even on devices that provide only |
| a d-pad controller), you must explicitly declare that a touchscreen is |
| not required by declaring {@code android.hardware.touchscreen} with |
| {@code android:required="false"}. You should add this declaration if your |
| app uses—but does not require—a real touchscreen interface. |
| </p> |
| |
| <p> |
| If your app in fact requires a touch interface (to perform more advanced |
| touch gestures such as fling), then you don't need to declare any touch |
| interface features because they're required by default. However, it's |
| best if you explicitly declare all features that your app uses. |
| </p> |
| |
| <p> |
| If you require more complex touch interaction, such as multi-finger |
| gestures, you should declare that your app uses advanced touchscreen |
| features. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.touchscreen.multitouch</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the device's basic two-point multitouch capabilities, such |
| as for pinch gestures, but the app does not need to track touches |
| independently. This is a superset of the |
| <code>android.hardware.touchscreen</code> feature. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.touchscreen</code> feature, unless this parent |
| feature is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.touchscreen.multitouch.distinct</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the device's advanced multitouch capabilities for tracking |
| two or more points independently. This feature is a superset of the |
| <code>android.hardware.touchscreen.multitouch</code> feature. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.touchscreen.multitouch</code> feature, unless this |
| parent feature is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.hardware.touchscreen.multitouch.jazzhand</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses the device's advanced multitouch capabilities for tracking |
| five or more points independently. This feature is a superset of the |
| <code>android.hardware.touchscreen.multitouch</code> feature. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.hardware.touchscreen.multitouch</code> feature, unless this |
| parent feature is declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| </dl> |
| |
| <h4 id="usb-hw-features"> |
| USB hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.usb.accessory</code> |
| </dt> |
| |
| <dd> |
| The app behaves as the USB device and connects to USB hosts. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.usb.host</code> |
| </dt> |
| |
| <dd> |
| The app uses the USB accessories that are connected to the device. The |
| device serves as the USB host. |
| </dd> |
| </dl> |
| |
| <h4 id="wi-fi-hw-features"> |
| Wi-Fi hardware features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.hardware.wifi</code> |
| </dt> |
| |
| <dd> |
| The app uses 802.11 networking (Wi-Fi) features on the device. |
| </dd> |
| |
| <dt> |
| <code>android.hardware.wifi.direct</code> |
| </dt> |
| |
| <dd> |
| The app uses the Wi-Fi Direct networking features on the device. |
| </dd> |
| </dl> |
| |
| <h3 id="sw-features"> |
| Software features |
| </h3> |
| |
| <p> |
| This section presents the software features supported by the most current |
| platform release. To indicate that your app uses or requires a software |
| feature, declare the corresponding value (beginning with |
| <code>"android.software"</code>) in an <code>android:name</code> attribute. |
| Each time you declare a software feature, use a separate |
| <code><uses-feature></code> element. |
| </p> |
| |
| <h4 id="communication-sw-features"> |
| Communication software features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.software.sip</code> |
| </dt> |
| |
| <dd> |
| The app uses Session Initiation Protocol (SIP) services. By using SIP, the |
| app can support internet telephony operations, such as video conferencing |
| and instant messaging. |
| </dd> |
| |
| <dt> |
| <code>android.software.sip.voip</code> |
| </dt> |
| |
| <dd> |
| <p> |
| The app uses SIP-based Voice Over Internet Protocol (VoIP) services. By |
| using VoIP, the app can support real-time internet telephony operations, |
| such as two-way video conferencing. |
| </p> |
| |
| <p> |
| By using this feature, an app implies that it also uses the |
| <code>android.software.sip</code> feature, unless this parent feature is |
| declared with <code>android:required="false"</code>. |
| </p> |
| </dd> |
| |
| <dt> |
| <code>android.software.webview</code> |
| </dt> |
| |
| <dd> |
| The app displays content from the internet. |
| </dd> |
| </dl> |
| |
| <h4 id="custom-input-sw-features"> |
| Custom input software features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.software.input_methods</code> |
| </dt> |
| |
| <dd> |
| The app uses a new input method, which the developer defines in an <a href= |
| "{@docRoot}reference/android/inputmethodservice/InputMethodService.html">{@code |
| InputMethodService}</a>. |
| </dd> |
| </dl> |
| |
| <h4 id="device-management-sw-features"> |
| Device management software features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.software.backup</code> |
| </dt> |
| |
| <dd> |
| The app includes logic to handle a backup and restore operation. |
| </dd> |
| |
| <dt> |
| <code>android.software.device_admin</code> |
| </dt> |
| |
| <dd> |
| The app uses device administrators to enforce a device policy. |
| </dd> |
| |
| <dt> |
| <code>android.software.managed_users</code> |
| </dt> |
| |
| <dd> |
| The app supports secondary users and managed profiles. |
| </dd> |
| |
| <dt> |
| <code>android.software.securely_removes_users</code> |
| </dt> |
| |
| <dd> |
| The app can <strong>permanently</strong> remove users and their associated |
| data. |
| </dd> |
| |
| <dt> |
| <code>android.software.verified_boot</code> |
| </dt> |
| |
| <dd> |
| The app includes logic to handle results from the device's verified boot |
| feature, which detects whether the device's configuration changes during a |
| restart operation. |
| </dd> |
| </dl> |
| |
| <h4 id="media-sw-features"> |
| Media software features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.software.midi</code> |
| </dt> |
| |
| <dd> |
| The app connects to musical instruments or outputs sound using the Musical |
| Instrument Digital Interface (MIDI) protocol. |
| </dd> |
| |
| <dt> |
| <code>android.software.print</code> |
| </dt> |
| |
| <dd> |
| The app includes commands for printing documents displayed on the device. |
| </dd> |
| |
| <dt> |
| <code>android.software.leanback</code> |
| </dt> |
| |
| <dd> |
| The app presents a UI that is designed for viewing on a large screen, such |
| as a television. |
| </dd> |
| |
| <dt> |
| <code>android.software.live_tv</code> |
| </dt> |
| |
| <dd> |
| The app streams live television programs. |
| </dd> |
| </dl> |
| |
| <h4 id="screen-interface-sw-features"> |
| Screen interface software features |
| </h4> |
| |
| <dl> |
| <dt> |
| <code>android.software.app_widgets</code> |
| </dt> |
| |
| <dd> |
| The app uses or provides App Widgets and should be installed only on |
| devices that include a Home screen or similar location where users can |
| embed App Widgets. |
| </dd> |
| |
| <dt> |
| <code>android.software.home_screen</code> |
| </dt> |
| |
| <dd> |
| The app behaves as a replacement to the device's Home screen. |
| </dd> |
| |
| <dt> |
| <code>android.software.live_wallpaper</code> |
| </dt> |
| |
| <dd> |
| The app uses or provides wallpapers that include animation. |
| </dd> |
| </dl> |
| |
| <h3 id="permissions"> |
| Permissions that Imply Feature Requirements |
| </h3> |
| |
| <p> |
| Some of the hardware and software feature constants were made available to |
| applications after 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 using 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. Table 2 lists |
| permissions that imply feature requirements equivalent to those declared in |
| <code><uses-feature></code> elements. |
| </p> |
| |
| <p> |
| Note that <code><uses-feature></code> declarations, including any |
| declared <code>android:required</code> attribute, always take precedence over |
| features implied by the permissions in table 2. For any of these permissions, |
| 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> |
| |
| <p class="caution"> |
| <strong>Caution:</strong> If your app targets Android 5.0 (API level 21) or |
| higher and uses the <code>ACCESS_COARSE_LOCATION</code> or |
| <code>ACCESS_FINE_LOCATION</code> permission in order to receive location |
| updates from the network or a GPS, respectively, you must also explicitly |
| declare that your app uses the <code>android.hardware.location.network</code> |
| or <code>android.hardware.location.gps</code> hardware features. |
| </p> |
| |
| <p class="table-caption" id="permissions-features"> |
| <strong>Table 2. </strong>Device permissions that imply device hardware use. |
| </p> |
| <table> |
| <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> |
| <p> |
| <code>android.hardware.location</code> |
| </p> |
| <p> |
| <code>android.hardware.location.network</code> |
| (Only when target API level is 20 or lower.) |
| </p> |
| </td> |
| <!-- <td></td> --> |
| </tr> |
| <tr> |
| <td><code>ACCESS_FINE_LOCATION</code></td> |
| <td> |
| <p> |
| <code>android.hardware.location</code> |
| </p> |
| <p> |
| <code>android.hardware.location.gps</code> |
| (Only when target API level is 20 or lower.) |
| </p> |
| </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">Wi-Fi</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> |