Android开发者指南-Manifest.xml-<uses-feature>

Android Market会对用户所见到的应用程序进行过滤，因此用户只能看见并下载那些与自己设备兼容的应用程序。Market过滤应用的一种方式是根据feature的兼容性。

为了实现feature的过滤，Market会检查每个应用程序manifest文件的<uses-feature>元素，并建立feature需求。然后根据用户设备可用的feature，Market对用户显示或隐藏应用程序。

通过指定应用程序所需的feature，可以让Android Market只向符合feature需求的设备提供应用程序，而不是提供给所有用户。关于Android Market如何将features用作过滤条件的重要信息，请参阅下文Android Market和基于Feature的过滤。

语法：

<uses-featureandroid:name="string"

            android:required=["true" | "false"]

            android:glEsVersion="integer"/>

 

包含于：

<manifest>

 

说明：

声明一个应用程序用到的软硬件特性feature。

声明<uses-feature>的目的是为了把应用程序所依赖的软硬件特性feature通知给外部实体。本元素提供一个required属性，指定应用程序是否必需此feature，即不声明此feature的话就无法正常运行；或者虽然期望提供此feature，不过没有的话也能运行。由于对feature的支持依Android设备而各不相同，<uses-feature>元素将为应用程序描述所需的各种设备feature发挥重要作用。

应用程序声明的可用feature集应与Android PackageManager中的feature常量集相一致，在本文底部的Feature参考表中已列出以便查找。

由于每一个feature必须放在单独的元素中指定，如果应用程序需要多个feature，应该声明多个<uses-feature>元素。比如，应用程序需要使用设备中的蓝牙和摄像头，则应声明两个元素：

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

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

通常应确保总是为程序需要的所有feature都声明<uses-feature>元素。

<uses-feature>元素的声明仅仅是通知性质的，这意味着Android系统本身不会在安装程序前检查设备是否支持feature。当然，其它服务（诸如Android Market）或者应用程序可以检查此<uses-feature>声明来进行处理或与本应用程序进行交互。因此，声明需用到的所有feature（如下表列出）是非常重要的。

有些feature可能会拥有特殊的属性，用于定义feature的版本，比如Open GL版本（用glEsVersion声明）。其它的设备feature，比如摄像头，用name属性进行声明。

尽管<uses-feature>元素仅对API Level 4以上版本的设备才有效，仍然建议为所有应用程序包含本元素，即使minSdkVersion小于等于“3”也应如此。运行早期版本的设备将会忽略本元素。

注意：如果声明了一个feature，请记得必须同时请求响应的权限。比如在访问摄像头APi之前，还必须申请CAMERA权限。权限申请可向应用程序授权访问相应软硬件，而声明应用程序所用到的feature可以确保合适的设备兼容性。

 

属性:

android:name

指定一个应用程序所用到的软、硬件feature，用作描述符。合法的描述符值在下文的硬件feature和软件feature 表中列出。

android:required

布尔值，指明应用程序是否需要android:name指定的feature。

· 如果对feature声明了"android:required="true"，则表示设备不提供指定feature应用程序就不能正常运行或未设计成正常运行。

· 如果对feature声明了"android:required="false"，则意味着设备提供则应用程序愿意使用此feature，但程序是为不存在指定feature也能正常工作而设计的。

如果未声明android:required，则缺省值是"true"。

android:glEsVersion

应用程序所需的OpenGL ES版本。高16位代表大版本号，低16位代表小版本号。比如要指定OpenGL ES 2.0，应该设为“0x00020000”。要指定OpenGL ES 2.1，应该设为“0x00020001”。

应用程序应该在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可用。）

 

引入于：

API Level 4

 

参阅：

· PackageManager

· FeatureInfo

· ConfigurationInfo

· <uses-permission>

· AndroidMarket过滤器

 

 

Android Market和基于Feature的过滤

Android Market会对用户所见到的应用程序进行过滤，因此用户只能看到并下载与自己的设备兼容的那些应用程序。Market过滤应用的一种方式是根据feature兼容性。

为了确定应用程序的feature与给定用户设备的兼容性，Android Market服务将对比：

· 应用程序所需的feature——应用程序在manifest的<uses-feature>元素中声明的feature 和

· 设备可用的硬件或软件feature——设备以系统只读属性报告的所支持的feature。

为了确保feature的精确匹配，Android包管理器提供了一组共享的feature常量集，应用程序和设备都能用它来声明feature需求及支持。可用的feature常量已在本文底部的Features参考表中列出，同时也列在PackageManager类的文档中。

当用户启动Market应用程序时，它会查询包管理器并通过调用getSystemAvailableFeatures()列出设备可用的feature。在与用户建立连接后，Market应用程序会把feature列表上传给Android Market服务。

每次把应用程序上传给Android Market发布网站时，Android Market会扫描应用程序的manifest文件。它会查找<uses-feature>元素并综合其它元素进行判断，比如<uses-sdk>和<uses-permission>元素。建立应用程序所需的feature集之后，它会将此列表作为与应用程序.apk及版本相关联的元数据进行内部保存。

当用户在Android Market上搜索或查看应用程序时，后台服务会把程序需要的feature与用户设备可用的feature进行比较。如果对程序所需的所有feature设备都能提供，Android Market就允许用户看见此应用并提供下载。只要任一个所需的feature不能被设备支持，Android Market就会滤除这个应用，用户看不到此应用程序也无法下载它。

因为在<uses-feature>元素中声明的feature直接会影响Android Market对应用程序的过滤，理解Android Market如何判断应用程序的manifest并建立所需的feature集，是非常重要的。以下章节提供了更为详细的信息。

 

基于显式声明的feature进行过滤

已显式声明的feature是指应用程序在<uses-feature>元素中声明过的feature。feature的声明可以包含一个android:required=["true" | "false"]属性（假定是以API level 5以上版本编译），此属性可以指明应用程序是否一定需要本feature，也即不为（"true"）的话就无法正常运行；或者应用程序在feature可用时是否期望使用它，但设计为不为（"false"）情况下运行的。（译者注：此处意思似乎与前文android:required的说明不符，应该是为false时而设计。）

Android Market用以下方式处理显式声明过的feature：

· 如果feature显式声明为必需的，Android Market将把此feature加入应用程序的feature需求列表中，然后对用户滤除那些设备不支持此feature的应用程序。例如：

<uses-featureandroid:name="android.hardware.camera"android:required="true"/>

· 如果feature显式声明为不需要。Android Market将不会把此feature加入到feature需求列表中。因此，对应用程序的过滤会忽略那些显式声明为不需要的feature。即使设备不支持已声明的feature，但只要其它过滤条件许可，Android Market仍然会考虑应用程序与设备的兼容性并显示给用户。例如：

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

· 如果feature已显式声明，但却不带有android:required属性，Android Market将假定此feature是必需的并根据它进行过滤。

一般情况下，如果应用程序是设计为在Android 1.6以下版本运行的，则API是不支持android:required属性的，Android Market假定所有的<uses-feature>声明都是必需的。

注意：通过显式声明feature并包含android:required="false"属性，可以有效地禁止Android Market针对指定feature的所有过滤行为。

 

基于隐含feature进行过滤

隐含feature是指应用程序正常运行所必需的，但不在manifest文件的<uses-feature>元素中声明的那些feature。从严格意义上说，每个应用程序应该总是对其需要的或用到的所有feature进行声明，所以对用到的feature缺少声明应该是被视为错误。然而作为对用户和开发人员的保护措施，Android Market会查找每个应用程序的隐含feature并为其建立过滤器，就如这些feature已经显式声明过一样。

因为以下原因，应用程序可能未对必需的feature进行声明：

· 应用程序是用低版本Android库（Android 1.5以下）编译的，当时<uses-feature>元素还未获支持。

· 开发人员错误地认为所有设备都应提供此feature，也就没必要声明了。

· 开发人员无意中遗漏了feature声明。

· 开发人员显示声明了feature但声明不合法。比如，<uses-feature>元素名称拼写错误，或把无法识别的字符串赋值给android:name属性，都会导致声明不合法。

为了考虑以上这些情况，Android Market试图通过检查manifest文件中的其它元素来发现应用程序隐含的feature需求，特别是<uses-permission>元素。

如果应用程序请求了硬件相关的访问权限，即使缺少相应的<uses-feature>声明，Android 
Market也会假定应用程序会使用底层硬件feature并需要这些feature。根据这些权限，Android Market把对应的底层硬件feature加入到应用程序的元数据中并为其建立过滤器。

例如，假设应用程序请求CAMERA权限但未对android.hardware.camera声明<uses-feature>元素，Android Market就认为应用程序需要摄像头，对于设备不提供摄像头的用户就不会显示出此程序。

如果不希望Android Market根据隐含的feature进行过滤，也可以禁用此功能，只要在<uses-feature>元素中显式声明feature并包含android:required="false"属性即可。例如：要禁用源自CAMERA权限的过滤，可以如下声明feature：

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

<uses-permission>元素中的权限请求可能直接影响Android Market对应用程序的过滤行为，理解这一点十分重要。下文隐含了Feature需求的权限章节列出了所有隐含feature需求且会触发过滤行为的权限列表。

 

对蓝牙feature的特殊处理

在对蓝牙feature确定过滤条件时，Android Market应用的规则与上述稍有差别。

如果应用程序在<uses-permission>元素中声明了Bluetooth权限，但未在<uses-feature>元素中显式声明Bluetooth feature，Android Market将检查应用程序设计运行的在<uses-sdk>元素中指定的Android平台版本。

如下表所列，仅当程序声明了最低版本为Android 2.0 (API level 5)以上时，Android Market才会启用对蓝牙feature的过滤。当然请注意，如果程序在<uses-feature>元素中显式声明了Bluetooth feature，Android Market仍将适用正常过滤规则。

表1。对已请求蓝牙权限但未在<uses-feature>元素中声明Bluetooth feature的应用程序，Android Market如何确定蓝牙feature需求。

如果minSdkVersion是

或者 targetSdkVersion是

结果

<=4 (或未声明uses-sdk)

<=4

Android Market将不过滤应用程序（根据设备报告的对android.hardware.bluetooth feature的支持）。

<=4

>=5

Android Market对不支持android.hardware.bluetooth feature的设备（包括低版本平台）将滤除应用程序。

>=5

>=5

根据Android Market如何处理蓝牙feature，以下例子展示了各种过滤的效果。

第一例中，应用程序是设计运行于低版本API，声明了Bluetooth权限，但未在元素中声明Bluetooth feature。

结果：Android Market不对任何设备进行过滤。

<manifest ...>

  <uses-permissionandroid:name="android.permission.BLUETOOTH_ADMIN"/>

  <uses-sdkandroid:minSdkVersion="3"/>

  ...

</manifest>

下面的第二例中，还是同一个程序但声明了目标API level是 "5"。

结果：Android Market现在假定需要蓝牙feature，并将对未报告支持蓝牙的设备进行滤除，包括那些运行低版本平台的设备。

<manifest ...>

  <uses-permissionandroid:name="android.permission.BLUETOOTH_ADMIN"/>

  <uses-sdkandroid:minSdkVersion="3"android:targetSdkVersion="5"/>

  ...

</manifest>

下面还是同一个程序，但现在特地声明了Bluetooth feature。

结果：与前例相同（过滤生效）。

<manifest ...>

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

  <uses-permissionandroid:name="android.permission.BLUETOOTH_ADMIN"/>

  <uses-sdkandroid:minSdkVersion="3"android:targetSdkVersion="5"/>

  ...

</manifest>

最后，以下情况还是同一个程序，但增加了android:required="false"属性。

结果：Android Market对所有设备关闭基于Bluetooth feature支持的过滤，

<manifest ...>

  <uses-featureandroid:name="android.hardware.bluetooth"android:required="false"/>

  <uses-permissionandroid:name="android.permission.BLUETOOTH_ADMIN"/>

  <uses-sdkandroid:minSdkVersion="3"android:targetSdkVersion="5"/>

  ...

</manifest>

 

测试应用程序所需的feature

可以用Android SDK内含的aapt工具来确定Android Market是否会根据声明的feature和权限滤除应用程序，带dump badging命令行参数运行aapt即可。这会使得aapt解析manifest文件并应用与Android Market相同的规则来确定程序所需的feature。

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

首先，创建程序并生成未签名的.apk。如果使用带ADT的Eclipse进行开发，右键点击project并选择Android Tools > Export Unsigned Application Package。选中目标文件名和路径并点击OK。

1. 下一步，如果未在PATH中包含运行路径，则找到aapt工具。如果正在使用SDK Tools r8以上版本，可以在<SDK>/platform-tools/目录下找到aapt。

注意：必须使用最新版本Platform-Tools组件所提供的aapt。如果没有最新版本的Platform-Tools组件，用Android SDK和AVD Manager去下载。

2. 用以下格式运行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'

 

Feature参考

下表列出了软硬件feature信息及可在Android Market中隐含feature的权限。

硬件feature

下表说明了平台当前大多数版本所支持的硬件feature描述符。用于程序中的标识或者声明硬件feature的需求，在单独的<uses-feature>元素中声明android:name属性值即可。

Feature类型

Feature描述符

说明

备注

Audio

android.hardware.audio.low_latency

应用程序用到设备上的低延迟音频通道，并对声音的输入输出延迟较为敏感。

 

Bluetooth

android.hardware.bluetooth

应用程序用到设备的蓝牙无线feature。

 

Camera

android.hardware.camera

应用程序用到设备的摄像头。如果设备支持多个摄像头，程序使用背朝屏幕的那个。

 

android.hardware.camera.autofocus

子特性。应用程序用到设备摄像头的自动对焦功能。

这些子特性隐含声明了父featureandroid.hardware.camera，除非它声明了android:required="false"。

android.hardware.camera.flash

子特性。应用程序用到设备摄像头的闪光灯功能。

android.hardware.camera.front

子特性。应用程序用到设备上正面的摄像头。

Location

android.hardware.location

应用程序用到设备上一个或多个定位feature，例如GPS定位、网络定位或蜂窝定位。

 

android.hardware.location.network

子特性。应用程序用到粗略的位置坐标，此坐标来源于设备支持的基于网络的定位系统。

这些子特性隐含声明了父featureandroid.hardware.location，除非它声明了android:required="false"。

android.hardware.location.gps

子特性。应用程序用到精确的位置坐标，此坐标来源于设备上的全球定位系统GPS接收器。

Microphone

android.hardware.microphone

应用程序用到设备上的话筒。

 

NFC

android.hardware.nfc

应用程序用到设备上的近距离无线通信Near Field Communication features。

 

Sensors

android.hardware.sensor.accelerometer

应用程序用到来自设备上加速度传感器的动作数据。

 

android.hardware.sensor.barometer

应用程序用到设备上的气压计。

 

android.hardware.sensor.compass

应用程序用到来自设备上磁力指南针的方向数据。

 

android.hardware.sensor.gyroscope

应用程序用到设备上的陀螺传感器。

 

android.hardware.sensor.light

应用程序用到设备上的光线传感器。

 

android.hardware.sensor.proximity

应用程序用到设备上的临近性传感器。

 

Screen

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声明了方向，但实际上却不需要用到，可以通过包含android:required="false"的<uses-feature>方向声明来禁用此需求。

为了保持向下兼容性，任何运行API level 12以下版本平台的设备，被认为是对横向和纵向都能提供支持。

android.hardware.screen.portrait

应用程序需要屏幕纵向放置。

Telephony

android.hardware.telephony

应用程序用到设备上的电话feature，诸如电话的无线数据通讯服务。

 

android.hardware.telephony.cdma

子特性。应用程序用到设备上的CDMA 电话无线feature。

这些子特性隐含声明了父feature android.hardware.telephony，除非它用android:required="false"进行了声明。

android.hardware.telephony.gsm

子特性。应用程序用到设备上GSM电话无线feature。

Touchscreen

android.hardware.faketouch

应用程序用到了基本的触摸交互事件，诸如“按下”、“抬起”和拖动。

此声明表示应用程序只适用于支持仿真触摸（伪触摸屏faketouch）或更高级触摸屏的设备。

支持伪触摸屏界面的设备能向用户提供一种模仿了部分触摸屏功能的录入系统。比如，控制屏幕光标的鼠标或遥控器就提供了伪触摸接口。如果应用程序需要基本的点击交互（换句话说，仅用D-pad是无法正常运行的），就应该声明本feature。因为这是最低级别的触摸交互方式，应用程序也将能兼容支持更复杂触摸交互功能的设备。

注意：因为应用程序缺省是需要android.hardware.touchscreen feature的，如果期望程序适用于伪触摸接口，必须同时显式声明触摸屏不是必需的：<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

android.hardware.faketouch.multitouch.distinct

应用程序在伪触摸屏上对两个以上的手指进行独立的跟踪。这是faketouch的子特性。

声明此feature表示应用程序只适用于能支持单独跟踪两个手指以上轨迹的触摸仿真或更高级的设备上。

与android.hardware.touchscreen.multitouch.distinct定义的独立多点触摸不同，以伪触摸接口方式支持多点触摸的输入设备将不支持全部的双手指手势，因为输入实际上是转换成屏幕光标的移动的。也就是说，在这种设备上单个手指的手势将会移动光标；双手指的点击将触发单个手指的触摸事件；其它双手指的手势将导致双手指触摸事件冲突。用伪触摸接口支持独立多点触摸的设备，一个例子就是移动光标的轨迹板，它同时也支持两个以上手指的触摸。

android.hardware.faketouch.multitouch.jazzhand

应用程序在伪触摸屏上对五个以上的手指进行独立的跟踪。这是faketouch的子特性。

声明此feature表示应用程序只适用于能支持单独跟踪五个以上手指轨迹的触摸仿真或更高级的设备上。

与android.hardware.touchscreen.multitouch.jazzhand定义的独立jazzhand多点触摸不同，以伪触摸接口方式支持的jazzhand多点触摸不支持全部的五手指手势，因为输入会转换成屏幕的光标移动。也就是说，在这种设备上单个手指的手势将会移动光标；多手指的手势将触发单个手指的触摸事件；其它多手指的手势将会导致多手指触摸事件的冲突。用伪触摸接口支持独立多点触摸的设备，一个例子就是移动光标的轨迹板，它同时也支持五个以上手指的触摸。

android.hardware.touchscreen

应用程序用到比基本的触摸事件更复杂的手势触摸功能，比如滑动（fling）。这是基本faketouch feature的超集。

缺省情况下，应用程序是需要本feature的。这样应用程序默认不适用于仅能支持仿真触摸接口（fake touch）的设备。如果程序期望能用于支持仿真触摸接口的设备（甚至是仅提供d-pad的设备），必须用附带android:required="false"的android.hardware.touchscreen显式声明不需要触摸屏。即使程序是用到了——但不需要——真正的触摸屏接口，也需要如此显式声明。

如果应用程序确实需要触摸屏接口（为了处理诸如fling之类的触摸手势），就不必进行任何声明，因为这是缺省必需的。不过最好对所有用到的feature都进行显式声明，所以用到的话还是应该声明本feature。

如果需要更复杂的触摸操作，比如多个手指的手势，应该声明下面更高级的触摸屏feature。

android.hardware.touchscreen.multitouch

应用程序用到基本的两点触摸功能，比如夹pinch手势，但不需要单独的跟踪触摸。这是touchscreen feature 的超集。

隐含声明了父feature android.hardware.touchscreen，除非声明时附带了android:required="false"。

android.hardware.touchscreen.multitouch.distinct

子特性。应用程序用到了高级

多点触摸功能，比如完全独立地跟踪两个以上的触点。这是multitouch feature的超集。

隐含声明了父feature android.hardware.touchscreen.multitouch，除非声明时附带了android:required="false"。

android.hardware.touchscreen.multitouch.jazzhand

应用程序用到了高级

多点触摸功能，完全独立地跟踪跟踪不超过5个点。这是 distinct multitouch feature 的超集。

USB

android.hardware.usb.host

应用程序用到了USB主机模式feature（作为主机连接USB设备）。

 

android.hardware.usb.accessory

应用程序用到了USB访问feature（作为USB设备连接USB主机）。

 

Wifi

android.hardware.wifi

应用程序用到了设备上的802.11 网络（wifi）feature。

 

 

软件feature

下表说明了平台目前的版本所支持的软件feature描述符。用于程序中的标识或者声明软件feature的需求，在单独的<uses-feature>元素中声明android:name属性值即可。

Feature

属性值

说明

备注

Live Wallpaper

android.software.live_wallpaper

应用程序用到或支持活动桌面壁纸Live Wallpapers。

 

SIP/VOIP

android.software.sip

应用程序用到设备上的会话发起协议SIP服务。

 

android.software.sip.voip

子个性。应用程序用到设备上基于SIP的网络电话VOIP服务。

本feature隐含声明了父feature android.software.sip，除非声明附带了android:required="false"。

 

隐含了Feature需求的权限

上表中的某些feature常量只适用于相应API版本之后的应用；比如android.hardware.bluetooth feature是Android 2.2 (API level 8)加入的，但它所用到的蓝牙API在Android 2.0 (API level 5)就已经加入了。因此，在能通过<uses-feature>系统来声明所需的API之前，应用程序已经可以使用这些API

为了保证这些应用程序的可用性，Android Market假定某些特定的硬件权限默认就标明了对底层硬件feature的需求。举例来说，用到蓝牙的应用程序必须在<uses-permission>元素中请求BLUETOOTH权限——用于老版本应用，Android Market认为此权限声明意味着程序需要底层android.hardware.bluetooth feature，并会建立基于此feature的过滤行为。

下表列出了隐含了feature需求声明的权限，等同于<uses-feature>元素声明的feature。请注意，包含了android:required属性的<uses-feature>声明总是会优先于一下权限隐含的feature。

对于以下所有权限，通过附带android:required="false"属性的<uses-feature>元素，都可以禁用基于隐含声明的过滤。例如，要禁用基于CAMERA权限的过滤行为，可以在<uses-feature>中加入以下声明来实现：

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

 

种类

权限

隐含的Feature需求

Bluetooth

BLUETOOTH

android.hardware.bluetooth

(详见蓝牙feature特殊处理)

BLUETOOTH_ADMIN

android.hardware.bluetooth

Camera

CAMERA

android.hardware.camera和android.hardware.camera.autofocus

Location

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

Microphone

RECORD_AUDIO

android.hardware.microphone

Telephony

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

Wifi

ACCESS_WIFI_STATE

android.hardware.wifi

CHANGE_WIFI_STATE

android.hardware.wifi

CHANGE_WIFI_MULTICAST_STATE

android.hardware.wifi

原文转载地址：http://www.cnblogs.com/zhengbeibei/archive/2013/04/24/3041188.html