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:nameandroid:requiredandroid:name.
+ android:required
+ android:name.
+ android:required="true" for a feature,
you are specifying that the application cannot function, or is not
@@ -163,7 +173,7 @@ feature, if necessary. 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.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.
+ 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.
+
+ 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.
| Feature Type | -Feature Descriptor | -Description | -Comments | -
|---|---|---|---|
| Audio | -android.hardware.audio.low_latency |
- The 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.pro |
- The application uses high-end audio functionality and performance. | -- | |
android.hardware.microphone |
- The application records audio via a microphone. | -- | android.hardware.output |
- The application produces at least one form of audio output, such as speakers, audio jack - or streaming over bluetooth. | -- - |
| Bluetooth | -android.hardware.bluetooth |
- The application uses Bluetooth radio features in the device. | -- |
android.hardware.bluetooth_le |
- The application uses Bluetooth Low Energy radio features in the device. | -- | |
| Camera | -android.hardware.camera |
- The 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.autofocus |
- Subfeature. 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.flash |
- Subfeature. The application uses the device camera's flash. | -||
android.hardware.camera.front |
- Subfeature. The application uses a front-facing camera on the device. | -||
android.hardware.camera.any |
- The 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.external |
- The application uses an external camera device if one is connected. | -||
android.hardware.camera.level.full |
- The application uses a camera device with FULL-level support. |
-||
android.hardware.camera.capability.manual_sensor |
- The application uses a a camera device with the MANUAL_SENSOR capability. |
-||
android.hardware.camera.capability.manual_post_processing |
- The application uses a a camera device with the MANUAL_POST_PROCESSING capability. |
-||
android.hardware.camera.capability.raw |
- The application uses a a camera device with the RAW capability. |
-||
| Infrared | -android.hardware.consumerir |
- The application uses the consumer IR capabilities on the device. | -- |
| Location | -android.hardware.location |
- The application uses one or more features on the device for determining -location, such as GPS location, network location, or cell location. | -- |
android.hardware.location.network |
- Subfeature. 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.gps |
- Subfeature. The application uses precise location coordinates obtained -from a Global Positioning System receiver on the device. | -||
| Microphone | -android.hardware.microphone |
- The application uses a microphone on the device. - | -- |
| NFC | -android.hardware.nfc |
- The application uses Near Field Communications radio features in the device. | -- |
android.hardware.nfc.hce |
- The application uses the NFC card emulation feature in the device. | -- | |
| Sensors | -android.hardware.sensor.accelerometer |
- The application uses motion readings from an accelerometer on the -device. | -- |
android.hardware.sensor.barometer |
- The application uses the device's barometer. | -- | |
android.hardware.sensor.compass |
- The application uses directional readings from a magnetometer (compass) on -the device. | -- | |
android.hardware.sensor.gyroscope |
- The application uses the device's gyroscope sensor. | -- | |
android.hardware.sensor.light |
- The application uses the device's light sensor. | -- | |
android.hardware.sensor.proximity |
- The application uses the device's proximity sensor. | -- | |
android.hardware.sensor.stepcounter |
- The application uses the device's step counter. | -- | |
android.hardware.sensor.stepdetector |
- The application uses the device's step detector. | -- | |
| Screen | -android.hardware.screen.landscape |
- The application requires landscape orientation. | -
- For example, if your app requires portrait orientation, you should declare
- 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 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.portrait |
- The application requires portrait orientation. | -||
| Telephony | -android.hardware.telephony |
- The application uses telephony features on the device, such as telephony -radio with data communication services. | -- |
android.hardware.telephony.cdma |
- Subfeature. 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.gsm |
- Subfeature. The application uses GSM telephony radio features on the -device. | -||
| Television | -android.hardware.type.television |
- The 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. | -
| Touchscreen | -android.hardware.faketouch |
- The 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 |
-
android.hardware.faketouch.multitouch.distinct |
- The 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.jazzhand |
- The 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.touchscreen |
- The application uses touchscreen capabilities for gestures that are more interactive -than basic touch events, such as a fling. This is a superset of the basic faketouch feature. | -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.multitouch |
- The application uses basic two-point multitouch capabilities on the device -screen, such as for pinch gestures, but does not need to track touches independently. This -is a superset of touchscreen feature. | -This implicitly declares the android.hardware.touchscreen parent feature, unless
-declared with android:required="false". |
-|
android.hardware.touchscreen.multitouch.distinct |
- Subfeature. The application uses advanced multipoint multitouch -capabilities on the device screen, such as for tracking two or more points fully -independently. This is a superset of multitouch feature. | -This implicitly declares the android.hardware.touchscreen.multitouch
-parent feature, unless declared with android:required="false". |
-|
android.hardware.touchscreen.multitouch.jazzhand |
- The application uses advanced multipoint multitouch -capabilities on the device screen, for tracking up to five points fully -independently. This is a superset of distinct multitouch feature. | -||
| USB | -android.hardware.usb.host |
- The application uses USB host mode features (behaves as the host and connects to USB -devices). | -- |
android.hardware.usb.accessory |
- The application uses USB accessory features (behaves as the USB device and connects to USB -hosts). | -- | |
| Wi-Fi | -android.hardware.wifi |
- The application uses 802.11 networking (Wi-Fi) features on the device. | -- |
android.hardware.wifi.direct |
- The application uses the Wi-Fi Direct networking features on the device. | -
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.
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
+ | Feature | -Attribute Value | -Description | -
|---|---|---|
| App Widgets | -android.software.app_widgets |
- The 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 Management | -android.software.device_admin |
- The application uses device policy enforcement via device administrators. | -
| Home Screen | -android.software.home_screen |
- The application behaves as a Home screen replacement and should be installed only on - devices that support third-party Home screen apps. | -
| Input Method | -android.software.input_methods |
- The application provides a custom input method and should be installed only on devices that - support third-party input methods. | -
| Live Wallpaper | -android.software.live_wallpaper |
- The application uses or provides Live Wallpapers and should be installed only on devices that - support Live Wallpapers. | -
| MIDI | -android.software.midi |
- The application connects to musical instruments or outputs sound - using the Musical Instrument Digital Interface (MIDI) protocol. | -
| SIP/VOIP | -android.software.sip |
- The 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.hardware.camera if your app does not require the
+ camera to be a back-facing one.
+ android.hardware.camera.autofocus
+ + 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
+ 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
+ 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.
+ 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
+ android.hardware.fingerprint
+ android.hardware.gamepad
+ android.hardware.consumerir
+ android.hardware.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".
+
android.hardware.nfc
+ android.hardware.nfc.hce
+ + (Deprecated.) +
+ ++ The app uses NFC card emulation that is hosted on the device. +
+android.hardware.opengles.aep
+ android.hardware.sensor.accelerometer
+ android.hardware.sensor.ambient_temperature
+ android.hardware.sensor.barometer
+ android.hardware.sensor.compass
+ android.hardware.sensor.gyroscope
+ android.hardware.sensor.hifi_sensors
+ android.hardware.sensor.heartrate
+ android.hardware.sensor.heartrate.ecg
+ android.hardware.sensor.light
+ android.hardware.sensor.proximity
+ android.hardware.sensor.relative_humidity
+ android.hardware.sensor.stepcounter
+ android.hardware.sensor.stepdetector
+ 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. +
+android.hardware.telephony
+ 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".
+
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".
+
android.hardware.usb.accessory
+ android.hardware.usb.host
+ android.hardware.wifi
+ android.hardware.wifi.direct
+
+ 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.
+
android.software.sip
+ 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
+ android.software.input_methods
+ android.software.backup
+ android.software.device_admin
+ android.software.managed_users
+ android.software.securely_removes_users
+ android.software.verified_boot
+ android.software.midi
+ android.software.print
+ android.software.leanback
+ android.software.live_tv
+ android.software.app_widgets
+ android.software.home_screen
+ android.software.live_wallpaper
+
+ 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" />-
| Category | This Permission... | -Implies This Feature Requirement | +...Implies This Feature Requirement |
|---|