From da90584135a0b19f9f38abd93ef27f3f045cd3de Mon Sep 17 00:00:00 2001 From: Kevin Hufnagle Date: Fri, 29 Apr 2016 10:40:47 -0700 Subject: [PATCH] Cherry pick: docs: Edited "Features Reference" section in "" page. The "Features Reference" section now lists all hardware and software features that apps can use on devices running Marshmallow, and some existing features now have more descriptive examples. Converted the tables listing hardware and software features to h4 elements and definition lists to make the page more reader-friendly, particularly on handheld devices. Bug: 27803596 Change-Id: I3490f5dcde6a838d69940c70e06d9cd2cb8a7bdc --- .../topics/manifest/uses-feature-element.jd | 1612 ++++++++++++----- 1 file changed, 1144 insertions(+), 468 deletions(-) diff --git a/docs/html/guide/topics/manifest/uses-feature-element.jd b/docs/html/guide/topics/manifest/uses-feature-element.jd index 74ab8f2804fa4..5d163c0d5d56b 100755 --- a/docs/html/guide/topics/manifest/uses-feature-element.jd +++ b/docs/html/guide/topics/manifest/uses-feature-element.jd @@ -77,7 +77,7 @@ application describe the device-variable features that it uses.

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 Features Reference tables +convenience in the Features Reference sections at the bottom of this document.

You must specify each feature in a separate <uses-feature> @@ -131,17 +131,27 @@ device compatibility.

+
+ android:name +
-
android:name
-
Specifies a single hardware or software feature used by the application, -as a descriptor string. Valid descriptor values are listed in the Hardware features and Software -features tables, below. Descriptor string values are case-sensitive.
+
+ Specifies a single hardware or software feature used by the application, as + a descriptor string. Valid attribute values are listed in the Hardware features and Software + features sections. These attribute values are case-sensitive. +
-
android:required
-
Boolean value that indicates whether the application requires - the feature specified in android:name. +
+ android:required +
+ +
+ Boolean value that indicates whether the application requires the feature + specified in android:name. +
+
  • When you declare android:required="true" for a feature, you are specifying that the application cannot function, or is not @@ -163,7 +173,7 @@ feature, if necessary.
    • 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.0, you would set the value as "0x00030000". +"0x00020000", or to specify OpenGL ES 3.2, you would set the value as "0x00030002".

    An application should specify at most one android:glEsVersion attribute in its manifest. If it specifies more than one, the @@ -184,8 +194,8 @@ 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.)

    For more information about using OpenGL ES, including how to check the supported OpenGL ES -version at runtime, see the OpenGL ES -API guide.

    +version at runtime, see the OpenGL ES +API guide.

    @@ -229,7 +239,7 @@ a device reports the features it supports as read-only system properties.

    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 Features Reference tables at +are listed in the Features Reference sections at the bottom of this document, and in the class documentation for {@link android.content.pm.PackageManager}.

    @@ -362,8 +372,8 @@ the feature as shown below.

    It's important to understand that the permissions that you request in <uses-permission> elements can directly affect how Google Play filters your application. The reference section Permissions that Imply Feature Requirements, -below, lists the full set of permissions that imply feature requirements and +href="#permissions">Permissions that Imply Feature Requirements lists the +full set of permissions that imply feature requirements and therefore trigger filtering.

    Special handling for Bluetooth feature

    @@ -532,493 +542,1159 @@ locales: '--_--' densities: '160' +

    + Features Reference +

    -

    Features Reference

    +

    + The following sections provide reference information about hardware features, + software features, and sets of permissions that imply specific feature + requirements. +

    -

    The tables below provide reference information about hardware and software -features and the permissions that can imply them on Google Play.

    +

    + Hardware features +

    -

    Hardware features

    +

    + 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 + "android.hardware") in an android:name attribute. + Each time you declare a hardware feature, use a separate + <uses-feature> element. +

    -

    The table below describes the hardware feature descriptors supported by the -most current platform release. To signal that your application uses or requires -a hardware feature, declare each value in a android:name attribute -in a separate <uses-feature> element.

    +

    + Audio hardware features +

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
    +
    + android.hardware.audio.low_latency +
    -
    - - - - - +
    + The app uses the device's low-latency audio pipeline, which reduces lag and + delays when processing sound input or output. +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
    + android.hardware.audio.output +
    - - - - - - - - - - +
    + The app transmits sound using the device's speakers, audio jack, Bluetooth + streaming capabilities, or a similar mechanism. +
    - - - - - - - - - - - - - - - +
    + android.hardware.audio.pro +
    - - - - - - +
    + The app uses the device's high-end audio functionality and performance + capabilities. +
    - - - - - - +
    + android.hardware.microphone +
    - - - - - +
    + The app records audio using the device's microphone. +
    + - - - - - +

    + Bluetooth hardware features +

    - - - - - - - - - - - - - - - - - - - +
    +
    + android.hardware.bluetooth +
    -
    - - - - - +
    + The app uses the device's Bluetooth features, usually to communicate with + other Bluetooth-enabled devices. +
    - - - - - +
    + android.hardware.bluetooth_le +
    - - - - - - - - - - +
    + The app uses the device's Bluetooth Low Energy radio features. +
    + -
    Feature TypeFeature DescriptorDescriptionComments
    Audioandroid.hardware.audio.low_latencyThe application uses a low-latency audio pipeline on the device and - is sensitive to delays or lag in sound input or output.
    android.hardware.audio.proThe application uses high-end audio functionality and performance.
    android.hardware.microphoneThe application records audio via a microphone.
    android.hardware.outputThe application produces at least one form of audio output, such as speakers, audio jack - or streaming over bluetooth.
    Bluetoothandroid.hardware.bluetoothThe application uses Bluetooth radio features in the device.
    android.hardware.bluetooth_leThe application uses Bluetooth Low Energy radio features in the device.
    Cameraandroid.hardware.cameraThe application uses the device's back-facing (main) camera.Devices with only a front-facing camera do not list this feature, so - the android.hardware.camera.any feature should be used - instead if a camera facing any direction is acceptable for the - application.
    android.hardware.camera.autofocusSubfeature. The application uses the device camera's autofocus capability.These subfeatures implicitly declare the -android.hardware.camera parent feature, unless declared with -android:required="false".
    android.hardware.camera.flashSubfeature. The application uses the device camera's flash.
    android.hardware.camera.frontSubfeature. The application uses a front-facing camera on the device.
    android.hardware.camera.anyThe application uses at least one camera facing in any direction, or an -external camera device if one is connected. Use this in preference to -android.hardware.camera if a back-facing camera is not required. -
    android.hardware.camera.externalThe application uses an external camera device if one is connected.
    android.hardware.camera.level.fullThe application uses a camera device with FULL-level support.
    android.hardware.camera.capability.manual_sensorThe application uses a a camera device with the MANUAL_SENSOR capability.
    android.hardware.camera.capability.manual_post_processingThe application uses a a camera device with the MANUAL_POST_PROCESSING capability.
    android.hardware.camera.capability.rawThe application uses a a camera device with the RAW capability.
    Infraredandroid.hardware.consumerirThe application uses the consumer IR capabilities on the device.
    Locationandroid.hardware.locationThe application uses one or more features on the device for determining -location, such as GPS location, network location, or cell location.
    android.hardware.location.networkSubfeature. The application uses coarse location coordinates obtained from -a network-based geolocation system supported on the device.These subfeatures implicitly declare the -android.hardware.location parent feature, unless declared with -android:required="false".
    android.hardware.location.gpsSubfeature. The application uses precise location coordinates obtained -from a Global Positioning System receiver on the device.
    Microphoneandroid.hardware.microphoneThe application uses a microphone on the device. -
    NFCandroid.hardware.nfcThe application uses Near Field Communications radio features in the device.
    android.hardware.nfc.hceThe application uses the NFC card emulation feature in the device.
    Sensorsandroid.hardware.sensor.accelerometerThe application uses motion readings from an accelerometer on the -device.
    android.hardware.sensor.barometerThe application uses the device's barometer.
    android.hardware.sensor.compassThe application uses directional readings from a magnetometer (compass) on -the device.
    android.hardware.sensor.gyroscopeThe application uses the device's gyroscope sensor.
    android.hardware.sensor.lightThe application uses the device's light sensor.
    android.hardware.sensor.proximityThe application uses the device's proximity sensor.
    android.hardware.sensor.stepcounterThe application uses the device's step counter.
    android.hardware.sensor.stepdetectorThe application uses the device's step detector.
    Screenandroid.hardware.screen.landscapeThe application requires landscape orientation. -

    For example, if your app requires portrait orientation, you should declare -<uses-feature android:name="android.hardware.screen.portrait"/> so that only devices -that support portrait orientation (whether always or by user choice) can install your app. If your -application supports both orientations, then you don't need to declare either.

    -

    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 {@code -android:screenOrientation} attribute, then this also declares that the application requires that -orientation. For example, if you declare {@code -android:screenOrientation} with either {@code "landscape"}, {@code "reverseLandscape"}, or -{@code "sensorLandscape"}, then your application will be available only to devices that support -landscape orientation. As a best practice, you should still declare your requirement for this -orientation using a {@code <uses-feature>} element. If you declare an orientation for your -activity using {@code -android:screenOrientation}, 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"}.

    -

    For backwards compatibility, any device running a platform version that supports only API -level 12 or lower is assumed to support both landscape and portrait.

    -
    android.hardware.screen.portraitThe application requires portrait orientation.
    Telephonyandroid.hardware.telephonyThe application uses telephony features on the device, such as telephony -radio with data communication services.
    android.hardware.telephony.cdmaSubfeature. The application uses CDMA telephony radio features on the -device. These subfeatures implicitly declare the -android.hardware.telephony parent feature, unless declared with -android:required="false".
    android.hardware.telephony.gsmSubfeature. The application uses GSM telephony radio features on the -device.
    Televisionandroid.hardware.type.televisionThe application is designed for a television user experience.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 through touch or a - mouse/pointer-device.
    Touchscreenandroid.hardware.faketouchThe application uses basic touch interaction events, such as "click down", "click -up", and drag.

    When declared as required, this indicates that the application is compatible with a device -only if it offers an emulated touchscreen ("fake touch" interface), or better. A device that offers -a fake touch interface provides a user input system that emulates a subset of touchscreen -capabilities. For example, a mouse or remote control that drives an on-screen cursor provides a fake -touch interface. If your application requires basic point and click interaction (in other -words, it won't work with only a d-pad controller), you should declare this feature. -Because this is the minimum level of touch interaction, your app will also be compatible with -devices that offer more complex touch interfaces.

    -

    Note: Because applications require the {@code -android.hardware.touchscreen} feature by default, if you want your application to be available to -devices that provide a fake touch interface, you must also explicitly declare that a touch screen is -not required by declaring {@code <uses-feature -android:name="android.hardware.touchscreen" android:required="false" -/>}

    android.hardware.faketouch.multitouch.distinctThe application performs distinct tracking of two or more "fingers" on a fake touch -interface. This is a superset of the faketouch feature.

    When declared as required, this indicates that the application is compatible with a device -only if it supports touch emulation for events that supports distinct tracking of two or more -fingers, or better.

    -

    Unlike the distinct multitouch defined by {@code -android.hardware.touchscreen.multitouch.distinct}, input devices that support distinct multi-touch -with a fake touch interface will not support all two-finger gestures, because the input is -being transformed to cursor movement on the screen. That is, single finger gestures on such a device -move a cursor; two-finger swipes will result in single-finger touch events; other two-finger -gestures will result in the corresponding two-finger touch event. An example device that supports -distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement -which also supports two or more fingers.

    android.hardware.faketouch.multitouch.jazzhandThe application performs distinct tracking of five or more "fingers" on a fake touch -interface. This is a superset of the faketouch feature.

    When declared as required, this indicates that the application is compatible with a device -only if it supports touch emulation for events that supports distinct tracking of five or more -fingers.

    -

    Unlike the distinct multitouch defined by {@code -android.hardware.touchscreen.multitouch.jazzhand}, input devices that support jazzhand multi-touch -with a fake touch interface will not support all five-finger gestures, because the input is being -transformed to cursor movement on the screen. That is, single finger gestures on such a device move -a cursor; multi-finger gestures will result in single-finger touch events; other multi-finger -gestures will result in the corresponding multi-finger touch event. An example device that supports -distinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movement -which also supports five or more fingers.

    android.hardware.touchscreenThe application uses touchscreen capabilities for gestures that are more interactive -than basic touch events, such as a fling. This is a superset of the basic faketouch feature.

    By default, your application requires this. As such, your application is not -available to devices that provide only an emulated touch interface ("fake touch"), by default. If -you want your application available to devices that provide a fake touch interface (or even devices -that provide only a d-pad controller), you must explicitly declare that a touch screen is not -required, by declaring {@code android.hardware.touchscreen} with {@code android:required="false"}. -You should do so even if your application uses—but does not require—a real -touch screen interface.

    -

    If your application does require a touch interface (in order to perform touch -gestures such as a fling), then you don't need to do anything, because this is required by default. -However, it's best if you explicitly declare all features used by your application, so you should -still declare this if your app uses it.

    -

    If you require more complex touch interaction, such as multi-finger gestures, you -should declare the advanced touch screen features below.

    android.hardware.touchscreen.multitouchThe application uses basic two-point multitouch capabilities on the device -screen, such as for pinch gestures, but does not need to track touches independently. This -is a superset of touchscreen feature.This implicitly declares the android.hardware.touchscreen parent feature, unless -declared with android:required="false".
    android.hardware.touchscreen.multitouch.distinctSubfeature. The application uses advanced multipoint multitouch -capabilities on the device screen, such as for tracking two or more points fully -independently. This is a superset of multitouch feature.This implicitly declares the android.hardware.touchscreen.multitouch -parent feature, unless declared with android:required="false".
    android.hardware.touchscreen.multitouch.jazzhandThe application uses advanced multipoint multitouch -capabilities on the device screen, for tracking up to five points fully -independently. This is a superset of distinct multitouch feature.
    USBandroid.hardware.usb.hostThe application uses USB host mode features (behaves as the host and connects to USB -devices).
    android.hardware.usb.accessoryThe application uses USB accessory features (behaves as the USB device and connects to USB -hosts).
    Wi-Fiandroid.hardware.wifiThe application uses 802.11 networking (Wi-Fi) features on the device.
    android.hardware.wifi.directThe application uses the Wi-Fi Direct networking features on the device.
    +

    + Camera hardware features +

    -

    Software features

    +
    +
    + android.hardware.camera +
    -

    The table below describes the software feature descriptors supported by the -most current platform release. To signal that your application uses or requires -a software feature, declare each value in a android:name attribute -in a separate <uses-feature> element.

    +
    + The app uses the device's back-facing camera. Devices with only a + front-facing camera do not list this feature, so use the + android.hardware.camera.any feature instead if your app can + communicate with any camera, regardless of which direction the camera + faces. +
    +
    + android.hardware.camera.any +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    FeatureAttribute ValueDescription
    App Widgetsandroid.software.app_widgetsThe application 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.
    Device Managementandroid.software.device_adminThe application uses device policy enforcement via device administrators.
    Home Screenandroid.software.home_screenThe application behaves as a Home screen replacement and should be installed only on - devices that support third-party Home screen apps.
    Input Methodandroid.software.input_methodsThe application provides a custom input method and should be installed only on devices that - support third-party input methods.
    Live Wallpaperandroid.software.live_wallpaperThe application uses or provides Live Wallpapers and should be installed only on devices that - support Live Wallpapers.
    MIDIandroid.software.midiThe application connects to musical instruments or outputs sound - using the Musical Instrument Digital Interface (MIDI) protocol.
    SIP/VOIPandroid.software.sipThe application uses SIP service on the device and should be installed only on devices that - support SIP. -
    android.software.sip.voip

    Subfeature. The application uses SIP-based VOIP service on the device. -

    This subfeature implicitly declares the android.software.sip parent feature, -unless declared with android:required="false".

    +
    + 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 + android.hardware.camera if your app does not require the + camera to be a back-facing one. +
    +
    + android.hardware.camera.autofocus +
    -

    Permissions that Imply Feature Requirements

    +
    +

    + The app uses the autofocus feature that the device's camera supports. +

    -

    Some feature constants listed in the tables above were made available to -applications after the corresponding API; for example, the -android.hardware.bluetooth feature was added in Android 2.2 (API -level 8), but the bluetooth API that it refers to was added in Android 2.0 (API -level 5). Because of this, some apps were able to use the API before they had -the ability to declare that they require the API via the -<uses-feature> system.

    +

    + By using this feature, an app implies that it also uses the + android.hardware.camera feature, unless this parent feature + is declared with android:required="false". +

    +
    -

    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 BLUETOOTH permission in a -<uses-permission> element — for legacy apps, Google -Play assumes that the permission declaration means that the underlying -android.hardware.bluetooth feature is required by the application -and sets up filtering based on that feature.

    +
    + android.hardware.camera.capability.manual_post_processing +
    -

    The table below lists permissions that imply feature requirements -equivalent to those declared in <uses-feature> elements. Note -that <uses-feature> declarations, including any declared -android:required attribute, always take precedence over features -implied by the permissions below.

    +
    +

    + The app uses the MANUAL_POST_PROCESSING feature that the + device's camera supports. +

    -

    For any of the permissions below, you can disable filtering based on the -implied feature by explicitly declaring the implied feature explicitly, in a -<uses-feature> element, with an -android:required="false" attribute. For example, to disable any -filtering based on the CAMERA permission, you would add this -<uses-feature> declaration to the manifest file:

    +

    + This feature allows your app to override the camera's auto white balance + functionality. Use android.colorCorrection.transform, + android.colorCorrection.gains, and an + android.colorCorrection.mode of + TRANSFORM_MATRIX. +

    +
    + +
    + android.hardware.camera.capability.manual_sensor +
    + +
    +

    + The app uses the MANUAL_SENSOR feature that the device's + camera supports. +

    + +

    + This feature implies support for auto-exposure locking + (android.control.aeLock), which allows the camera's exposure + time and sensitivity to remain fixed at specific values. +

    +
    + +
    + android.hardware.camera.capability.raw +
    + +
    +

    + The app uses the RAW feature that the device's camera + supports. +

    + +

    + 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. +

    +
    + +
    + android.hardware.camera.external +
    + +
    + 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. +
    + +
    + android.hardware.camera.flash +
    + +
    +

    + The app uses the flash feature that the device's camera supports. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.camera feature, unless this parent feature + is declared with android:required="false". +

    +
    + +
    + android.hardware.camera.front +
    + +
    +

    + The app uses the device's front-facing camera. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.camera feature, unless this parent feature + is declared with android:required="false". +

    +
    + +
    + android.hardware.camera.level.full +
    + +
    + The app uses the FULL-level image-capturing support that at + least one of the device's cameras provides. Cameras with FULL + support provide burst-capture capabilities, per-frame control, and manual + post-processing control. +
    +
    + +

    + Device UI hardware features +

    + +
    +
    + android.hardware.type.automotive +
    + +
    +

    + 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. +

    + +

    + Note: 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. +

    +
    + +
    + android.hardware.type.television +
    + +
    +

    + (Deprecated; use + android.software.leanback instead.) +

    + +

    + 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. +

    +
    + +
    + android.hardware.type.watch +
    + +
    + 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. +
    +
    + +

    + Fingerprint hardware features +

    + +
    +
    + android.hardware.fingerprint +
    + +
    + The app reads fingerprints using the device's biometric hardware. +
    +
    + +

    + Gamepad hardware features +

    + +
    +
    + android.hardware.gamepad +
    + +
    + The app captures game controller input, either from the device itself or + from a connected gamepad. +
    +
    + +

    + Infrared hardware features +

    + +
    +
    + android.hardware.consumerir +
    + +
    + The app uses the device's infrared (IR) capabilities, usually to + communicate with other consumer IR devices. +
    +
    + +

    + Location hardware features +

    + +
    +
    + android.hardware.location +
    + +
    + The app uses one or more features on the device for determining location, + such as GPS location, network location, or cell location. +
    + +
    + android.hardware.location.gps +
    + +
    +

    + The app uses precise location coordinates obtained from a Global + Positioning System (GPS) receiver on the device. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.location feature, unless this parent + feature is declared with the attribute + android:required="false". +

    +
    + +
    + android.hardware.location.network +
    + +
    +

    + The app uses coarse location coordinates obtained from a network-based + geolocation system supported on the device. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.location feature, unless this parent + feature is declared with the attribute + android:required="false". +

    +
    +
    + +

    + NFC hardware features +

    + +
    +
    + android.hardware.nfc +
    + +
    + The app uses the device's Near-Field Communication (NFC) radio features. +
    + +
    + android.hardware.nfc.hce +
    + +
    +

    + (Deprecated.) +

    + +

    + The app uses NFC card emulation that is hosted on the device. +

    +
    +
    + +

    + OpenGL ES hardware features +

    + +
    +
    + android.hardware.opengles.aep +
    + +
    + The app uses the OpenGL ES Android Extension Packthat is installed + on the device. +
    +
    + +

    + Sensor hardware features +

    + +
    +
    + android.hardware.sensor.accelerometer +
    + +
    + 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. +
    + +
    + android.hardware.sensor.ambient_temperature +
    + +
    + The app uses the device's ambient (environmental) temperature sensor. For + example, a weather app could report indoor or outdoor temperature. +
    + +
    + android.hardware.sensor.barometer +
    + +
    + The app uses the device's barometer. For example, a weather app could + report air pressure. +
    + +
    + android.hardware.sensor.compass +
    + +
    + The app uses the device's magnetometer (compass). For example, a navigation + app could show the current direction a user faces. +
    + +
    + android.hardware.sensor.gyroscope +
    + +
    + 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. +
    + +
    + android.hardware.sensor.hifi_sensors +
    + +
    + The app uses the device's high fidelity (Hi-Fi) sensors. For example, a + gaming app could detect the user's high-precision movements. +
    + +
    + android.hardware.sensor.heartrate +
    + +
    + 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. +
    + +
    + android.hardware.sensor.heartrate.ecg +
    + +
    + 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. +
    + +
    + android.hardware.sensor.light +
    + +
    + 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. +
    + +
    + android.hardware.sensor.proximity +
    + +
    + 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. +
    + +
    + android.hardware.sensor.relative_humidity +
    + +
    + 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. +
    + +
    + android.hardware.sensor.stepcounter +
    + +
    + 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. +
    + +
    + android.hardware.sensor.stepdetector +
    + +
    + 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. +
    +
    + +

    + Screen hardware features +

    + +
    +
    + android.hardware.screen.landscape +
    + +
    + android.hardware.screen.portrait +
    + +
    +

    + 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. +

    + +

    + 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: +

    + 
    <uses-feature android:name="android.hardware.screen.portrait" />
    + +

    + 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 {@code + android:screenOrientation} attribute, then this declaration implies + that your app requires that orientation. For example, if you declare + {@code + android:screenOrientation} with either {@code "landscape"}, {@code + "reverseLandscape"}, or {@code "sensorLandscape"}, then your app will be + available only on devices that support landscape orientation. +

    + +

    + As a best practice, you should still declare your requirement for this + orientation using a {@code <uses-feature>} element. If you declare + an orientation for your activity using {@code + android:screenOrientation}, 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"}. +

    + +

    + For backward compatibility, any device running Android 3.1 (API level 12) + or lower supports both landscape and portrait orientations. +

    +
    +
    + +

    + Telephony hardware features +

    + +
    +
    + android.hardware.telephony +
    + +
    + The app uses the device's telephony features, such as telephony radio with + data communication services. +
    + +
    + android.hardware.telephony.cdma +
    + +
    +

    + The app uses the Code Division Multiple Access (CDMA) telephony radio + system. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.telephony feature, unless this parent + feature is declared with android:required="false". +

    +
    + +
    + android.hardware.telephony.gsm +
    + +
    +

    + The app uses the Global System for Mobile Communications (GSM) telephony + radio system. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.telephony feature, unless this parent + feature is declared with android:required="false". +

    +
    +
    + +

    + Touchscreen hardware features +

    + +
    +
    + android.hardware.faketouch +
    + +
    +

    + The app uses basic touch interaction events, such as tapping and + dragging. +

    + +

    + 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. +

    + +

    + 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. +

    + +

    + Note: 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: +

    + 
    <uses-feature android:name="android.hardware.touchscreen" android:required="false" />
    +
    + +
    + android.hardware.faketouch.multitouch.distinct +
    + +
    +

    + The app tracks two or more distinct "fingers" on a fake touch interface. + This is a superset of the android.hardware.faketouch + 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. +

    + +

    + 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. +

    + +

    + A device that provides a two-finger touch trackpad for cursor movement + can support this feature. +

    +
    + +
    + android.hardware.faketouch.multitouch.jazzhand +
    + +
    +

    + The app tracks five or more distinct "fingers" on a fake touch interface. + This is a superset of the android.hardware.faketouch + 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. +

    + +

    + 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. +

    + +

    + A device that provides a five-finger touch trackpad for cursor movement + can support this feature. +

    +
    + +
    + android.hardware.touchscreen +
    + +
    +

    + 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 android.hardware.faketouch feature. +

    + +

    + 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. +

    + +

    + 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. +

    + +

    + If you require more complex touch interaction, such as multi-finger + gestures, you should declare that your app uses advanced touchscreen + features. +

    +
    + +
    + android.hardware.touchscreen.multitouch +
    + +
    +

    + 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 + android.hardware.touchscreen feature. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.touchscreen feature, unless this parent + feature is declared with android:required="false". +

    +
    + +
    + android.hardware.touchscreen.multitouch.distinct +
    + +
    +

    + The app uses the device's advanced multitouch capabilities for tracking + two or more points independently. This feature is a superset of the + android.hardware.touchscreen.multitouch feature. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.touchscreen.multitouch feature, unless this + parent feature is declared with android:required="false". +

    +
    + +
    + android.hardware.touchscreen.multitouch.jazzhand +
    + +
    +

    + The app uses the device's advanced multitouch capabilities for tracking + five or more points independently. This feature is a superset of the + android.hardware.touchscreen.multitouch feature. +

    + +

    + By using this feature, an app implies that it also uses the + android.hardware.touchscreen.multitouch feature, unless this + parent feature is declared with android:required="false". +

    +
    +
    + +

    + USB hardware features +

    + +
    +
    + android.hardware.usb.accessory +
    + +
    + The app behaves as the USB device and connects to USB hosts. +
    + +
    + android.hardware.usb.host +
    + +
    + The app uses the USB accessories that are connected to the device. The + device serves as the USB host. +
    +
    + +

    + Wi-Fi hardware features +

    + +
    +
    + android.hardware.wifi +
    + +
    + The app uses 802.11 networking (Wi-Fi) features on the device. +
    + +
    + android.hardware.wifi.direct +
    + +
    + The app uses the Wi-Fi Direct networking features on the device. +
    +
    + +

    + Software features +

    + +

    + 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 + "android.software") in an android:name attribute. + Each time you declare a software feature, use a separate + <uses-feature> element. +

    + +

    + Communication software features +

    + +
    +
    + android.software.sip +
    + +
    + 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. +
    + +
    + android.software.sip.voip +
    + +
    +

    + 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. +

    + +

    + By using this feature, an app implies that it also uses the + android.software.sip feature, unless this parent feature is + declared with android:required="false". +

    +
    + +
    + android.software.webview +
    + +
    + The app displays content from the internet. +
    +
    + +

    + Custom input software features +

    + +
    +
    + android.software.input_methods +
    + +
    + The app uses a new input method, which the developer defines in an {@code + InputMethodService}. +
    +
    + +

    + Device management software features +

    + +
    +
    + android.software.backup +
    + +
    + The app includes logic to handle a backup and restore operation. +
    + +
    + android.software.device_admin +
    + +
    + The app uses device administrators to enforce a device policy. +
    + +
    + android.software.managed_users +
    + +
    + The app supports secondary users and managed profiles. +
    + +
    + android.software.securely_removes_users +
    + +
    + The app can permanently remove users and their associated + data. +
    + +
    + android.software.verified_boot +
    + +
    + 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. +
    +
    + +

    + Media software features +

    + +
    +
    + android.software.midi +
    + +
    + The app connects to musical instruments or outputs sound using the Musical + Instrument Digital Interface (MIDI) protocol. +
    + +
    + android.software.print +
    + +
    + The app includes commands for printing documents displayed on the device. +
    + +
    + android.software.leanback +
    + +
    + The app presents a UI that is designed for viewing on a large screen, such + as a television. +
    + +
    + android.software.live_tv +
    + +
    + The app streams live television programs. +
    +
    + +

    + Screen interface software features +

    + +
    +
    + android.software.app_widgets +
    + +
    + 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. +
    + +
    + android.software.home_screen +
    + +
    + The app behaves as a replacement to the device's Home screen. +
    + +
    + android.software.live_wallpaper +
    + +
    + The app uses or provides wallpapers that include animation. +
    +
    + +

    + Permissions that Imply Feature Requirements +

    + +

    + Some of the hardware and software feature constants were made available to + applications after the corresponding API; for example, the + android.hardware.bluetooth 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 + <uses-feature> system. +

    + +

    + 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 BLUETOOTH + permission in a <uses-permission> element — for legacy + apps, Google Play assumes that the permission declaration means that the + underlying android.hardware.bluetooth 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 + <uses-feature> elements. +

    + +

    + Note that <uses-feature> declarations, including any + declared android:required 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 + <uses-feature> element, with an + android:required="false" attribute. For example, to disable any + filtering based on the CAMERA permission, you would add this + <uses-feature> declaration to the manifest file: +

    <uses-feature android:name="android.hardware.camera" android:required="false" />
    - +

    + Table 2. Device permissions that imply device hardware use. +

    +
    - +
    Category This Permission...Implies This Feature Requirement...Implies This Feature Requirement