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 it's 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>.
</dd>
</dl>
<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>>/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}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="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><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">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>