<uses-feature>

英文原文：http://developer.android.com/guide/topics/manifest/uses-feature-element.html
采集（更新）日期：2014-7-7
搬迁自原博客：http://blog.sina.com.cn/s/blog_48d491300100zmwf.htmlhtml

在本文中

Google Play 的过滤机制android

经过应用程序 Manifest 文件中声明的 <uses-feature> 元素， Google Play 将会把不知足软硬件特性需求的设备过滤出去。网络

经过指定应用程序的设备特性需求，可使得 Google Play 仅向设备特性知足要求的用户提供该应用程序，而不是向全部用户开放。app

关于 Google Play 如何将设备特性做为过滤条件的关键性信息，请参阅后续章节 Google Play 和基于设备特性的过滤机制,ide

语法：

<uses-feature 
  android:name="string" 
  android:required=["true" | "false"] 
  android:glEsVersion="integer" />

包含于：

<manifest>

说明：

声明一项应用程序须要用到的软、硬件特性。

声明一项 <uses-feature> 的目的，是为了把应用程序所依赖的软硬件特性告知应用程序以外的对象。本元素给出了一个 required 属性，用于指定应用程序是否必需该项特性，也即不声明该项特性的话就没法正常运行；或者最好是提供该项特性，但没有的话也能运行。因为每种 Android 设备提供的特性各不相同， <uses-feature> 元素发挥着重要做用，应用程序能够用它来描述其用到的各类设备特性。工具

应用程序声明的多项设备特性应该对应于 Android PackageManager 中的相关常量，为了方便起见，在本文最后的 Features 参考手册中已将这些常量列出。post

因为每一项设备特性必须放在独立的一条 <uses-feature> 元素中声明，若是应用程序须要用到多项特性，就须要声明多个 <uses-feature> 元素。例如，假设应用程序须要使用蓝牙和摄像头设备，则应声明两个元素：测试

<uses-feature android:name="android.hardware.bluetooth" />  

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

一般，应该确保为应用程序须要的全部特性均声明了 <uses-feature> 元素。ui

<uses-feature> 元素的声明仅仅是告知性质的，这意味着 Android 系统自己不会在安装程序前检查设备是否支持这些特性。不过，其余服务（如 Google Play ）或者其余应用程序能够检查 <uses-feature> 声明来进行相应处理或与本应用程序进行交互。所以，对须要用到的全部特性都进行声明（以下表所示）是很是重要的。google

有些设备特性可能会存在一些特殊的属性，用于定义该特性的版本，好比 Open GL 版本（用 glEsVersion声明）。其余的一些与硬件是否就绪有关的特性，好比摄像头，则经过 name 属性进行声明。

尽管 <uses-feature> 元素仅对 API 级别 4 以上版本的设备才有效，仍然建议全部应用程序都要包含本元素，即便 minSdkVersion 小于等于“3”也应如此。只是运行较低版本系统的设备会忽略本元素罢了。

注意一旦声明了一项特性，请记得必须同时申请相应的权限。例如，在使用摄像头 API 以前，还必须申请 CAMERA 权限。权限申请使得应用程序有权访问相应的软、硬件，而声明须要用到的特性能够保证合适的设备兼容性。

属性：

android:name

定义一项应用程序须要用到的软、硬件特性，用字符串格式的描述符表示。合法的描述符值在下文的硬件特性和软件特性表中列出。这些描述符是大小写敏感的。

android:required

布尔值，指明应用程序是否须要用到 android:name 属性给出的特性。

若是对某项特性声明了“android:required="true"”，则表示当设备不提供指定特性时，应用程序就不能正常运行或未设计为可以正常运行。
若是对某项特性声明了“android:required="false"”，则意味着若是设备支持则应用程序将优先使用此特性，但设计程序时是考虑没有该项特性也能正常工做的。

如未明确给出声明，则android:required 的默认值是“true”

android:glEsVersion

应用程序须要的 OpenGL ES 版本。高 16 位表明大版本号，低 16 位表明小版本号。例如，要指定为 OpenGL ES 2.0，应该设为“0x00020000”。要指定为 OpenGL ES 2.1，应该设为“0x00020001”。要指定为 OpenGL ES 3.0，则应该设为“0x00030000”。

应用程序应该在 Manifest 中至少定义一项android:glEsVersion 属性。若是定义了两项以上的 android:glEsVersion ，将会采用数字最大的那个值，其余值将被忽略。

若是应用程序未指定 android:glEsVersion 属性，则假定该应用程序仅须要使用 OpenGL ES 1.0，全部 Android 平台的设备都支持该版本。

应用程序能够认为：若是系统支持给定的 OpenGL ES 版本，则同时也支持版本更低的 OpenGL ES。所以，若是应用程序同时须要使用 OpenGL ES 1.0 和 OpenGL ES 2.0，则必须指定为 OpenGL ES 2.0。

可在多种版本 OpenGL ES 上运行的应用程序只要指定所需的最低版本号便可。（能够在运行时检测是否有高版本的 OpenGL ES 可用。）

有关使用 OpenGL ES 的详细信息，包括如何在运行时检测 OpenGL ES 的当前版本，请参阅 OpenGL ES 指南。

引入自：

API 级别 4

参阅：

Google Play 和基于设备特性的过滤机制

Google Play 会对应用程序的用户可见性进行过滤，所以用户只能看到和下载那些与本身的设备兼容的应用程序。其中一种过滤方式是根据设备特性的兼容性。

为了肯定应用程序与给定用户设备的兼容性， Google Play 将对比：

应用程序须要的设备特性 — 应用程序 Manifest 文件的 <uses-feature> 元素中声明的特性
和
设备提供的硬件或软件特性 — 设备以系统只读属性的形式报告的特性。

为了保证设备特性的精确匹配，Android 包管理器给出了一组公开的特性常量，应用程序和设备共同使用这组常量来声明特性需求和支持。合法的特性常量已在本文底部的设备特性参考表中列出，同时也在 PackageManager 类的文档中给出。

当用户打开 Google Play 时，应用程序会调用 getSystemAvailableFeatures() 查询包管理器以列出设备可用的特性。在与用户创建链接时， Store 程序会把设备特性清单上传给 Google Play 。

每次把应用程序上传到 Google Play Developer Console 时， Google Play 会扫描该应用程序的 Manifest 文件。它会查找 <uses-feature> 元素并综合其余元素进行评估，好比某些时候会参考 <uses-sdk> 和 <uses-permission> 元素。在收集完应用程序的设备特性需求后，它会将此清单做为与应用程序的 .apk 及版本相关联的基础元数据进行内部保存。

当用户在 Google Play 上搜索或浏览应用程序时，后台服务会把程序需求与用户设备可用的特性进行比较。若是设备可以知足某个应用程序全部的特性需求， Google Play 就容许用户看见该应用，天然也会提供下载。只要任何一个特性需求不能被设备支持， Google Play 就会滤除该应用，因而用户就看不到此应用程序，也就没法下载。

由于在 <uses-feature> 元素中声明的设备特性会直接影响 Google Play 对应用程序的过滤行为，因此请理解 Google Play 如何评估应用程序的 Manifest 文件并创建特性需求清单，这点很是重要。下一章节里给出了更为详细的说明。

基于显式声明的特性需求进行过滤

显式声明的特性是指应用程序在 <uses-feature> 元素中声明的那些设备特性。特性的声明能够包含一个 android:required=["true" | "false"] 属性（假定以 API 级别 5 以上版本编译），该属性能够声明应用程序是否必定须要本特性，也即不为（“true”）的话就没法正常运行；或者当可用时应用程序是否优先使用它，但设计时是考虑没有该特性也能运行的（为“false”）。

Google Play 按照如下方式对待显式声明过的特性：

若是某个特性被显式声明为必需的，则 Google Play 会把该特性加入应用程序的需求列表中。而后，它会在不支持该特性的用户设备上滤除这些应用程序。例如：
```
<uses-feature android:name="android.hardware.camera" android:required="true" /> 
```
若是某个特性被显式声明为不须要，Google Play 将不会把它加入到特性需求列表中。这样，在过滤应用程序时就确定不会考虑这些显式声明为不须要的特性需求。即便设备不支持这些特性，但只要其余过滤规则许可，Google Play 仍然会认为该应用程序与设备兼容，并显示给用户。例如：
```
<uses-feature android:name="android.hardware.camera" android:required="false" /> 
```
若是某特性已经显式声明，但没有带 android:required 属性，则 Google Play 将假定此项特性是必需的，并据此进行过滤。

通常状况下，若是应用程序是为 Android 1.6 如下版本进行设计的，那么系统 API 是不支持 android:required 属性的， Google Play 会假定全部的 <uses-feature> 声明都是必须知足的。

注意： 经过显式声明某项特性并包含 android:required="false" 属性，能够有效地禁用 Google Play 对该特性的全部过滤行为。

基于隐含的特性需求进行过滤

隐含特性是指程序正常运行所必需的，但未在 Manifest 文件的 <uses-feature> 元素中声明的那些特性需求。严格意义上说，全部应用程序都应该确保对其须要的或用到的所有设备特性进行声明，所以对用到的特性缺乏声明应该被视为差错。然而，做为对用户和开发人员的保护措施， Google Play 会查找每一个应用程序的隐含特性需求并为其进行过滤，就如同这些特性已经显式声明过同样。

应用程序也许须要用到某个特性，但却没有进行声明，缘由多是：

该应用程序是用较低版本的 Android 库（ Android 1.5 如下）编译的，当时还不支持 <uses-feature> 元素。
开发人员错误地认为全部设备都应提供此项特性，也就不必声明了。
开发人员无心间遗漏了特性的声明。
开发人员明确声明了某特性需求，但声明不合法。好比， <uses-feature> 元素的名称拼写错了，或把没法识别的字符串赋值给了 android:name 属性，这些都会致使声明不合法。

考虑到上述状况， Google Play 会尝试检查 Manifest 文件中的其余元素，以便发现应用程序隐含的特性需求，特别是 <uses-permission> 元素。

若是应用程序申请了硬件相关的访问权限，即使缺乏相应的 <uses-feature> 声明， Google Play 也会 假定应用程序须要使用这些底层硬件，也就是有这些特性需求 。根据这些权限，Google Play 会把相应的底层硬件特性加入到应用程序的基础元数据中，并为其创建过滤器。

例如，假设应用程序请求了 CAMERA 权限，但却没有声明对应 android.hardware.camera 的 <uses-feature> 元素， Google Play 将认为该应用程序须要使用摄像头，那么设备不提供摄像头的用户也就不会看到该应用程序。

若是不但愿 Google Play 根据隐含的特性需求进行过滤，也能够禁用此功能。只要声明一条 <uses-feature> 元素中显式声明该特性，且包含 android:required="false" 属性便可。例如：为了禁用由 CAMERA 权限引起的过滤，能够将该特性声明以下：

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

请了解 <uses-permission> 元素中的权限请求可能直接影响 Google Play 对应用程序的过滤行为，这一点很是重要。后续章节隐含了特性需求的权限中列出了所有隐含了特性需求并将触发过滤行为的权限列表。

对蓝牙特性的特殊处理

在为蓝牙特性肯定过滤条件时， Google Play 适用的规则与上述状况略有不一样。

若是应用程序在 <uses-permission> 元素中声明了 Bluetooth 权限，但未在 <uses-feature> 元素中显式声明 Bluetooth 特性， Google Play 将会检查应用程序设计时在 <uses-sdk> 元素中指定的目标 Android 平台版本。

以下表所列，仅当程序声明最低目标版本为 Android 2.0 （API 级别 5）以上时， Google Play 才会启用对蓝牙特性的过滤。不过请注意，若是程序在 <uses-feature> 元素中显式声明了 Bluetooth 特性，则 Google Play 仍将适用正常的过滤规则。

表 1 对已请求蓝牙权限但未在 <uses-feature> 元素中声明 Bluetooth 特性的应用程序，Google Play 对蓝牙特性需求的肯定规则：

若是 `minSdkVersion` 是	或者 `targetSdkVersion`是	结果
<=4 （或未声明 uses-sdk ）	<=4	Google Play 不会根据 `android.hardware.bluetooth` 的声明进行任何过滤
<=4	> =5	Google Play 将对不提供 `android.hardware.bluetooth` 特性的设备进行过滤（包括低版本的系统）
> =5	> =5

下面举例说明根据 Google Play 对蓝牙特性进行过滤的各类效果。

在第一个例子中，应用程序设计时是运行于低版本 API 的，它声明了 Bluetooth 权限，但未在 <uses-feature> 元素中声明 Bluetooth 特性。: 结果： Google Play 不对任何设备进行过滤。

<manifest ...>  
     <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />  
     <uses-sdk android:minSdkVersion="3" />  
    ... 
 </manifest>

在下面的第二个例子中，仍是同一个程序，但把目标 API 级别声明为 "5"。: 结果： Google Play 如今认为程序须要使用蓝牙特性，对于未提供蓝牙支持的设备将过滤掉该程序，这里包括那些运行低版本系统的设备。

<manifest ...>  
     <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />  
     <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />  
    ... 
</manifest>

下面仍是同一个程序，但特意声明了 Bluetooth 特性。: 结果： 与上个例子相同（过滤生效）。

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

最后，仍是同一个程序，但增长了 android:required="false" 属性。 Android Market对全部设备关闭基于Bluetooth feature支持的过滤，: 结果： Google Play 对全部设备禁用基于 Bluetooth 特性需求的过滤行为。

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

对应用程序须要的设备特性进行测试

能够利用 Android SDK 内的 aapt 工具来肯定 Google Play 是否会根据声明的特性和权限对应用程序进行过滤。只要运行带有 dump badging参数的 aapt 便可。 aapt 将会解析 Manifest 文件，并按照 Google Play 的规则来肯定应用程序须要的设备特性。

请按如下步骤使用此工具：

首先，建立程序并生成未签名的 .apk。若是使用带 ADT 的 Eclipse 进行开发，请右键点击 project 并选择 Android Tools > Export Unsigned Application Package。选中目标文件名和路径并点击 OK 。
其次，若是未在 PATH 环境变量中包含 aapt 工具的路径，则请定位到其所在目录。若是正在使用的 SDK 工具为 r8 以上版本，则能够在 <SDK> /platform-tools/ 目录中找到 aapt。
注意： 必须使用最新版的 Platform-Tool 组件所提供的 aapt 。若是没有最新版本的 Platform-Tool 组件，请用 Android SDK Manager 下载。
使用如下语法执行 aapt ：

$ aapt dump badging  < path_to_exported_.apk >

如下是前面第二个蓝牙例子的命令行输出示例：

$ ./aapt dump badging BTExample.apk 

package: name='com.example.android.btexample' versionCode='' versionName='' 
uses-permission:'android.permission.BLUETOOTH_ADMIN' 
uses-feature:'android.hardware.bluetooth' 
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'

设备特性参考手册

下列表格列出了与软、硬件特性相关的参考信息，以及可在 Google Play 中隐含声明特性的权限。

硬件特性

下表说明了最新版本的系统所支持的硬件特性描述符。若是应用程序须要声明对某个硬件特性的使用需求，只要在一项 <uses-feature> 元素的 android:name属性值中声明某个对应的描述符便可。

种类	描述符	说明	备注
音频设备	`android.hardware.audio.low_latency`	应用程序用到低延迟音频通道，并对声音的输入输出延迟较为敏感。
蓝牙	`android.hardware.bluetooth`	应用程序用到蓝牙通信特性。
蓝牙	`android.hardware.bluetooth_le`	应用程序用到低功耗蓝牙通信特性
摄像头	`android.hardware.camera`	应用程序用到摄像头。若是设备支持多个摄像头，则使用屏幕背面的后置摄像头。
	`android.hardware.camera.autofocus`	子特性。应用程序用到摄像头的自动对焦功能。	这些子特性隐含声明了父特性 `android.hardware.camera`，除非同时附带声明了`android:required="false"`。
	`android.hardware.camera.flash`	子特性。应用程序用到摄像头的闪光灯功能。
	`android.hardware.camera.front`	子特性。应用程序用到正面的前置摄像头。
	`android.hardware.camera.any`	应用程序至少用到一个摄像头，无所谓其朝向，若是有链接的外置摄像头也能够。若是不是非要使用后置摄像头的话，可优先选用本设置，而不是 `android.hardware.camera`。
	`android.hardware.camera.external`	若是存在的话，应用程序使用外置摄像头。
红外	`android.hardware.consumerir`	应用程序用到红外（Consumer IR）功能。
定位	`android.hardware.location`	应用程序用到一个以上的定位特性，例如 GPS 定位、网络定位或基站定位。
	`android.hardware.location.network`	子特性。应用程序用到粗略的定位坐标，此坐标来自基于网络的定位系统。	这些子特性隐含声明了父特性 `android.hardware.location`，除非同时附带声明了`android:required="false"`。
	`android.hardware.location.gps`	子特性。应用程序用到精确的定位坐标，此坐标来自全球定位系统 GPS 接收器。
话筒	`android.hardware.microphone`	应用程序用到话筒。
NFC	`android.hardware.nfc`	应用程序用到近场无线通讯（NFC）特性。
NFC	`android.hardware.nfc.hce`	应用程序用到 NFC 卡仿真特性
传感器	`android.hardware.sensor.accelerometer`	应用程序用到加速度传感器给出的运动数据。
	`android.hardware.sensor.barometer`	应用程序用到气压传感器。
	`android.hardware.sensor.compass`	应用程序用到来自地磁传感器（罗盘）给出的方向数据。
	`android.hardware.sensor.gyroscope`	应用程序用到陀螺仪传感器。
	`android.hardware.sensor.light`	应用程序用到光线传感器。
	`android.hardware.sensor.proximity`	应用程序用到接近度传感器。
	`android.hardware.sensor.stepcounter`	应用程序用到走步计数器。
	`android.hardware.sensor.stepdetector`	应用程序用到了走步探测器。
屏幕	`android.hardware.screen.landscape`	应用程序须要设备横向放置。	例如，若是程序须要纵向屏幕，应该声明 `<uses-feature android:name="android.hardware.screen.portrait"/>` ，这样只有提供纵向屏幕的设备（一直纵向或用户选择的纵向均可以）才能安装该应用程序。假如应用程序支持两种方向，那就一个方向都不要声明。默认状况下，两种方向都不是必需的，这样在支持一个或两个方向的设备上均可以安装应用程序。不过，只要有 Activity 须要运行于指定的方向上，并使用了 `android:screenOrientation` 属性，则代表该应用程序必需这个屏幕方向。例如，若是应用程序声明了带“`landscape`”、 “`reverseLandscape`”或“`sensorLandscape`”的 `android:screenOrientation` 属性，则该程序将仅适用于支持横向显示的设备。最好仍是用 `<uses-feature>` 元素声明这种屏幕方向的需求。若是用 `android:screenOrientation` 为 Activity 声明了屏幕方向，但实际上却不是必须用到，则能够禁用此需求，这经过用 `<uses-feature>` 声明方向需求并附带`android:required="false"`来实现。为了保持向下兼容，任何运行 API 级别 12 如下版本系统的设备，都被视为同时支持横向和纵向放置。
屏幕	`android.hardware.screen.portrait`	应用程序须要设备纵向放置。
电话	`android.hardware.telephony`	应用程序用到电话特性，好比电话的数据通信服务。
	`android.hardware.telephony.cdma`	子特性。应用程序用到 CDMA 电话特性。	这些子特性隐含声明了父特性 `android.hardware.telephony`，除非附带了 `android:required="false"`声明。
	`android.hardware.telephony.gsm`	子特性。应用程序用到 GSM 电话特性。
电视	`android.hardware.type.television`	应用程序设计为电视机用户的体验方式。	本特性的“television”定义为典型的客厅电视用户体验方式：大屏幕显示，用户可坐得更远，主要的输入方式是方向键之类，通常不使用触摸屏或鼠标（指点设备）。
触摸屏	`android.hardware.faketouch`	应用程序用到了基本的触摸交互事件，好比“按下”、“抬起”和拖动。	一经声明，即表示应用程序兼容那些仅提供了仿真触摸屏（伪触摸屏）或更高级触摸屏的设备。提供伪触摸屏的设备可向用户提供一种模仿了部分触摸屏功能的录入系统。好比，可控制屏幕光标的鼠标或遥控器就提供了伪触摸屏功能。若是应用程序须要基本的指点和点击交互（换句话说，仅用方向键是没法正常工做的），就应该声明本特性。由于这是最低级别的触摸交互方式，应用程序也将能兼容那些可提供更复杂触摸交互方式的设备。注意：因为应用程序默认是须要 `android.hardware.touchscreen` 特性的，若是应用程序须要适用于提供伪触摸方式的设备，则必须同时显式声明触摸屏不是必需的，这可经过声明 `<uses-feature android:name="android.hardware.touchscreen" android:required="false" />` 来完成。
	`android.hardware.faketouch.multitouch.distinct`	应用程序在伪触摸屏上对两个以上的手指进行独立的跟踪。这是 faketouch 的子特性。	一经声明，即表示应用程序兼容那些仅能独立跟踪两个以上手指操做事件的仿真触摸屏或更高级的设备。与 `android.hardware.touchscreen.multitouch.distinct` 定义的独立多点触摸方式不一样，以伪触摸方式实现的多点触摸输入设备将不支持所有的双手指手势，由于这种输入方式其实是转换为屏幕光标的移动的。也就是说，在这种设备上，单个手指的手势将会移动光标，两个手指的点击将触发单手指触摸事件；其余的双手指手势将会致使和双手指触摸事件冲突。这种用伪触摸方式支持独立多点触摸的设备的例子，其中一个就是可移动光标的触摸板，它同时也支持两个以上手指的操做。
	`android.hardware.faketouch.multitouch.jazzhand`	应用程序在伪触摸屏上对五个以上的手指进行独立的跟踪。这是 faketouch 的子特性。	一经声明，即表示应用程序兼容那些仅能独立跟踪五个以上手指操做事件的仿真触摸设备。与 `android.hardware.touchscreen.multitouch.jazzhand` 定义的独立多点触摸方式不一样，以伪触摸方式实现的 jazzhand 多点触摸输入设备将不支持所有的五手指手势，由于这种输入方式将会转换成屏幕的光标移动。也就是说，在这种设备上，单个手指的手势将会移动光标，多手指的手势将触发单手指的触摸事件，其余的多手指手势将会致使和多手指触摸事件的冲突。这种用伪触摸方式支持独立多点触摸的设备的例子，其中一个就是可移动光标的触摸板，它同时也支持五个以上手指的操做。
	`android.hardware.touchscreen`	应用程序用到比基本触摸事件更加复杂的手势触摸功能，好比滑动。这是基本 faketouch 特性的超集。	默认状况下，应用程序是必须使用本特性的。这样，应用程序默认就不适用于那些仅能仿真触摸接口（fake touch）的设备。若是应用程序须要可以适用于提供仿真触摸接口的设备（甚至是仅提供方向键的设备），则必须用带有 `android:required="false"` 的 `android.hardware.touchscreen` 将触摸屏显式声明为非必需的。即使应用程序是用到了但不是必需真正的触摸屏接口，也应该进行这种声明。若是应用程序确实须要触摸屏接口（为了处理滑动之类的触摸手势），就没必要进行任何声明，由于默认这就是必需的。不过，最好仍是对全部要用到的特性都进行显式声明，所以必要的话仍是应该声明本特性。若是须要用到更复杂的触摸操做，好比多个手指的手势，则应该声明后续的更为高级的触摸屏特性。
	`android.hardware.touchscreen.multitouch`	应用程序用到基本的两点触摸功能（好比夹的手势），但不须要多点独立跟踪。这是 touchscreen 特性的超集。	本特性隐含声明了父特性 `android.hardware.touchscreen`，除非同时附带了 `android:required="false"` 声明。
	`android.hardware.touchscreen.multitouch.distinct`	子特性。应用程序用到了高级的多点触摸功能，好比彻底独立地跟踪两个以上的触点轨迹。这是 multitouch 特性的超集。	本特性隐含声明了父特性`android.hardware.touchscreen.multitouch`，除非同时附带了 `android:required="false"` 声明。
	`android.hardware.touchscreen.multitouch.jazzhand`	应用程序用到了高级的多点触摸功能，须要彻底跟踪不超过五个触点的轨迹。这是 distinct 多点触摸特性的超集。
USB	`android.hardware.usb.host`	应用程序用到 USB 主机模式特性（做为接受 USB 设备链接的主机）。
USB	`android.hardware.usb.accessory`	应用程序用到 USB 访问特性（做为 USB 设备并去链接 USB 主机）。
Wi-Fi	`android.hardware.wifi`	应用程序用到 802.11 网络（Wi-Fi）特性。
Wi-Fi	`android.hardware.wifi.direct`	应用程序用到 Wi-Fi Direct 网络特性。

软件特性

下表对最新版本系统支持的软件特性描述符给出了说明。若是应用程序须要声明对某个软件特性的使用需求，只要在一项 <uses-feature> 元素的 android:name属性值中声明某个对应的描述符便可。

特性	属性值	说明
App Widget	`android.software.app_widgets`	应用程序使用或提供了 App Widget，而且只能安装到提供主屏幕或相似地方的设备上，用户能够在这个地方嵌入多个 App Widget。
设备管理	`android.software.device_admin`	应用程序经过设备管理器使用设备强制策略。
主屏幕	`android.software.home_screen`	应用程序可替代主屏幕运行，且仅能在支持第三方主屏幕应用的设备上安装。
输入手段	`android.software.input_methods`	应用程序提供了自定义的输入手段，且仅能在支持第三方输入手段的设备上安装。
活动壁纸	`android.software.live_wallpaper`	应用程序用到或提供活动壁纸功能，且仅能在支持活动壁纸的设备上安装。
SIP/VOIP	`android.software.sip`	应用程序用到 SIP 服务，且仅能在支持 SIP 的设备上安装。
SIP/VOIP	`android.software.sip.voip`	子特性。应用程序用到基于 SIP 的 VOIP 服务。本特性隐含声明了父特性`android.software.sip`，除非附带了 `android:required="false"` 声明。

隐含了特性需求的权限

上述表格中的某些特性常量只适用于对应版本 API 以后的应用；例如，android.hardware.bluetooth 是从 Android 2.2 （API 级别 8）开始加入的，但它引用的蓝牙 API 自 Android 2.0 （API 级别 5）开始就已经加入了。所以，在能够经过 <uses-feature> 系统声明 API 需求以前，某些应用程序已经可使用这些 API 了。

为了防止无心之中使用到这些应用程序， Google Play 假定某些硬件相关的权限默认就声明了相应底层硬件特性的需求。举例来讲，用到蓝牙的应用程序必然会在 <uses-permission> 元素中请求 BLUETOOTH 权限 — 对于老版本的应用， Google Play 就假定此权限声明意味着应用程序须要底层的 android.hardware.bluetooth 特性，并会创建基于此特性的过滤机制。

下表列出了隐含了特性需求的权限，等同于这些特性已经在 <uses-feature> 元素中声明了。请注意， <uses-feature> 的声明（包括全部带有 android:required 属性的声明）老是优先于下述权限隐含的特性需求。

下述全部的权限，均可以禁用基于隐含声明的过滤行为，这经过声明附带 android:required="false" 属性的 <uses-feature> 元素来实现。例如，为了禁用基于 CAMERA 权限的过滤行为，能够在 Manifest 文件中加入如下 <uses-feature> 声明：

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

种类	权限	隐含的特性需求
蓝牙	`BLUETOOTH`	`android.hardware.bluetooth` （详情请参阅对蓝牙特性的特殊处理。)
蓝牙	`BLUETOOTH_ADMIN`	`android.hardware.bluetooth`
摄像头	`CAMERA`	`android.hardware.camera` 和 `android.hardware.camera.autofocus`
定位	`ACCESS_MOCK_LOCATION`	`android.hardware.location`
	`ACCESS_LOCATION_EXTRA_COMMANDS`	`android.hardware.location`
	`INSTALL_LOCATION_PROVIDER`	`android.hardware.location`
	`ACCESS_COARSE_LOCATION`	`android.hardware.location.network` 和 `android.hardware.location`
	`ACCESS_FINE_LOCATION`	`android.hardware.location.gps` 和 `android.hardware.location`
话筒	`RECORD_AUDIO`	`android.hardware.microphone`
电话	`CALL_PHONE`	`android.hardware.telephony`
	`CALL_PRIVILEGED`	`android.hardware.telephony`
	`MODIFY_PHONE_STATE`	`android.hardware.telephony`
	`PROCESS_OUTGOING_CALLS`	`android.hardware.telephony`
	`READ_SMS`	`android.hardware.telephony`
	`RECEIVE_SMS`	`android.hardware.telephony`
	`RECEIVE_MMS`	`android.hardware.telephony`
	`RECEIVE_WAP_PUSH`	`android.hardware.telephony`
	`SEND_SMS`	`android.hardware.telephony`
	`WRITE_APN_SETTINGS`	`android.hardware.telephony`
	`WRITE_SMS`	`android.hardware.telephony`
Wi-Fi	`ACCESS_WIFI_STATE`	`android.hardware.wifi`
	`CHANGE_WIFI_STATE`	`android.hardware.wifi`
	`CHANGE_WIFI_MULTICAST_STATE`	`android.hardware.wifi`

分类: Android

Android开发-API指南-

Android开发-API指南-<uses-feature>