http://developer.android.com/guide/topics/manifest/uses-feature-element.html
AndroidManifest.xml文件详解(uses-feature)
语法(SYNTAX):
<uses-featureandroid:name="string"
android:required=["true" | "false"]
android:glEsVersion="integer"/>
被包含于(CONTAINED IN):
<manifest>
说明(DESCRIPTION):
这个元素用于声明一个单独的被应用程序使用的硬件或软件功能。
<uses-feature>声明的目的是通知其他外部实体,该应用程序所依赖的硬件和软件功能。这个元素提供的required属性会让你指定应用程序在所需的功能不存在时,应用程序是否能够正常运行。因为功能能够所支持的Android设备不同,所以<uses-feature>元素被用于描述应用程序所依赖的、重要的、可用的设备功能。
应用程序所声明的一组可用功能对应着一组由Android的PackageManager类定义的可用的功能常量,为了方便,这些常量会在《Google Play和基于功能的过滤》的“功能参考”表中被列出。
如果应用程序需要多个功能,就要分别使用<uses-feature>元素来指定所需的每一个功能,例如:需要设备中带有蓝牙和camera功能的应用程序,要声明两个<uses-feature>元素:
<uses-feature android:name="android.hardware.bluetooth" />
<uses-feature android:name="android.hardware.camera" />
通常应该确保使用<uses-feature>元素来声明应用程序所需的所有功能。
被声明的<uses-feature>元素只是信息化的,这意味着Android系统本身在安装应用程序之前,不会检查设备上所支持的功能的匹配性。但是其他的服务(如Google Play)或应用程序可以检查该应用程序的<uses-feature>声明,把它作为与该应用程序交互的一部分。由于这个原因,声明应用程序要使用的所有的外部功能是至关重要的。
对于某些功能,有可能存在一个特定的属性,以便定义功能的版本,如被使用的Open GL的版本(用glEsVersion来声明)。而有些功能则不需要指定版本属性,如照相机,就只使用name属性来声明。
尽管<uses-feature>元素只在运行API Level 4或更高的版本上才有效,但是还是推荐在所有的应用程序中包含这个元素,即使minSdkVersion的值是3或更低的版本,那么这些运行旧的平台版本的设备会简单忽略掉这个元素。
注意:在声明一个功能时,要记住必须申请相应的权限。例如,在应用程序能够访问Camera的API之前,必须申请CAMERA权限。申请权限是让应用程序能够访问相应的软/硬件,而声明应用程序所使用的功能是为了确保正确的设备兼容性。
属性(ATTRIBUTES):
android:name
这个属性用描述性的字符串,指定该应用程序所使用的软/硬件功能。有效描述符在《Google Play和基于功能的过滤》的“硬件功能”和“软件功能”表中被列出。
android:required
这个属性用一个布尔值来指定应用程序是否需要在android:name属性中所指定的功能。
true:在设备上不存在指定的功能时,则该应用不能够正常运行。
false:如果设备上存在指定的功能,则应用程序会倾向使用这个功能,但是如果需要,也可设计成没被指定的功能也能够正常运行。
如果没有声明,这个属性的默认值是true。
android:qlEsVersion
这个属性用于声明应用程序所需要的OpenGL ES的版本。它的高16位代表主版本号,低16位代表次要版本号,如:要是指定OpenGL ES的版本号是2.0,那么就要设置为0x00020000。要指定的OpenGL ES的版本号是2.1,就要设置为0x00020001。
应用程序在它的清单中应该最多只能指定一个android:glEsVersion属性,如果指定了多个,那么只会使用版本最高的那个android:glEsVersion属性,而其他的将会被忽略。
如果应用程序没有指定一个android:glEsVersion属性,那么就假定应用程序仅需要OpenGL ES1.0,它是在所有的Android设备上都支持的版本。
应用程序能够假设,如果一个平台支持设定的OpenGL ES版本,那么它还会支持所有被设定版本低的OpenGL ES版本,因此,需要OpenGL ES1.0和OpenGL ES2.0的应用程序,必须要指定它所需要的版本时OpenGL ES2.0。
能够用任何版本的OpenGL ES来工作的应用程序,应该仅指定应用所需的最低版本的OpenGL ES。(应用程序能够在运行时检查较高版本的OpenGL ES是否可用。)
被引入的版本(INTRODUCED IN):
API Level 4
Google Play和基于功能的过滤(一)
Google Play会过滤出那些对用户可见的应用程序,因此用户只能看到和下载那些跟他们的设备兼容的应用程序。通过功能的兼容性是过滤应用程序的方法之一。
Google Play通过把以下两项内容进行比较,来判断应用程序跟给定用户设备是否兼容:
1. 应用程序需要的功能---指应用程序在它自己的清单的<uses-feature>元素中声明的功能;
2. 在设备上有效的硬/软件功能---值设备用只读的系统属性所报告的它所支持的功能。
为了确保功能的准确比较,Android包管理器提供了一个共享的功能常量集合,应用程序和设备都使用这些常量来声明各自所需要和支持的功能。可用的功能常量在本文下面的功能参考表中被列出。
当用户启动Google Play时,应用程序通过调用getSystemAvailableFeatures()方法,来查询包管理器中所列出的设备上可用的功能列表。然后在建立用户会话的时候,软件商店(The Store)应用程序会把这个功能列表上传给Google Play。
每次把应用程序上传给Google Play的发布网站时,Google Play都会扫描应用程序的清单文件。它会查找清单中的<uses-feature>元素,并且在某些情况下,会把它们跟其他元素组合在一起来评估,如<uses-sdk>和<uses-permission>元素。在建立了应用程序所需的功能集合之后,Google Play会把这个功能列表做为跟应用程序的.apk和版本相关联的内部元数据来保存。
当用户使用Google Play应用程序查询或浏览应用程序时,服务就会把每个应用程序所需的功能跟用户设备上可用的功能进行比较。如果应用程序所需要的功能在设备上都存在,那么Google Play就允许用户看到该应用程序,并程序潜在的可下载应用程序。如果应用所需的任何一个功能不被设备所支持,Google Play就过滤掉该应用程序,这样用户就看不到并且也不能够下载。
因为在<uses-feature>元素中声明的功能直接影响到Google Play如何过滤应用程序,因此理解Google Play是如何评估应用程序的清单和建立需求功能的集合是至关重要的,以下章节会详细说明。
基于明确声明功能的过滤
一个明确声明的功能就是应用程序在其清单中声明的一个<uses-feature>元素。功能声明能够包含一个android:required=[“true”|”false”]属性(如果在API Leve 5以上的版本上编译),这个属性指定了应用程序是否绝对的需要该功能,并且目标设备上不存在该功能时,该应用程序就不能正常的运行(true的场合),或指定应用程序在功能有效的时候就使用该功能,而在该功能无效的时候,应用程序也被设计成可以运行(false的场合)。
Google Play用以下方法来处理明确声明的功能:
1. 如果一个功能被明确声明为时必须的,则Google Play就会把应用程序需要的功能列表添加到一个列表中。然后把列表中的功能需求与用户设备提供的功能进行比较,从而把应用程序从没有提供该应用所需功能的设备中过滤掉。例如:
<uses-featureandroid:name="android.hardware.camera"android:required="true"/>
2. 如果一个功能被设计成非必须的功能,Google Play就不会把这样的功能添加到功能需求列表中。由于这个原因,明确声明的非必须功能,在Google Play过滤应用程序时就不会被考虑。即使设备不提供该声明的功能,Google Play依然会认为该应用程序与设备是兼容的,并允许显示给用户,除非使用了其他过滤规则。例如:
<uses-featureandroid:name="android.hardware.camera"android:required="false"/>
3. 如果一个功能被明确声明,但没有设置android:required属性,那么Google Play就会假定该功能是必须的,并且要针对该功能进行过滤。
通常,如果应用程序被设计成要运行在Android1.6或更早的版本上,那么在API中android:required属性是无效的,并且Google Play会假定应用程序所声明的所有的功能<uses-feature>都是必须的。
注意:通过声明一个包含android:required=”false”属性的功能,能够禁止Google Play针对该功能的所有过滤。
Google Play和基于功能的过滤(二)
基于暗示功能的过滤
一个暗示的功能是为了让应用程序正确运行所需的功能,但是,这个功能不在清单的<uses-feature>元素中声明。严格的说,应用程序应用始终声明它所使用和需要的所有功能,因此对于应用程序使用的,但却没有声明的功能,应该被认为是一个错误。但是,出于对用户和开发者的保护,Google Play会查看每个应用程序的暗示功能,并基于这些功能来过滤应用程序,就像是明确声明的功能所做的处理一样。
应用程序可能需要一个功能,但却不声明,这是因为:
1. 应用程序是针对较旧的Android类库版本(Android1.5或更早)来编译的,并且<uses-feature>元素是无效的;
2. 开发者错误的假设所需要的功能在所有的设备上都存在,而没有必要声明;
3. 开发者不小心忽略的该功能的声明;
4. 开发者明确的声明了该功能,但该声明是无效的。例如:<uses-feature>元素名的一个拼写错误或给android:name属性设定一个无法识别的字符串,这些都会导致功能声明无效。
基于以上原因的考虑,Google Play会尝试通过检查清单文件中其他元素的声明(特别是<uses-permission>元素)来发现被应用暗示的功能需求。
如果一个应用程序申请了硬件相关的权限,那么Google Play就会假定应用程序要使用底层的硬件功能,并因此而需要那些功能,即使可能没有响应的<uses-feature>声明。针对这样的权限申请,Google Play也会把底层的硬件功能添加到它所保持的对应的应用程序的元数据中,并基于这些信息来过滤要显示给用户应用程序。
例如,如果应用程序申请了CAMERA权限,但却没有声明一个对应android.hardware.camera功能的<uses-feature>元素,那么Google Play就会认为应用程序需要照相机功能,并且该应用程序不应该显示给没有提供照相机功能的那些用户设备。
如果不想要Google Play基于某个特殊的暗示功能来过滤应用程序,就要禁止这种行为。通过在其清单文件中明确的声明<uses-feature>元素,幷包含一个android:required=”false”属性,可以达到禁止Google Play过滤应用程序的目的。例如:要禁止由CAMERA权限所派生出来的过滤,就要向下面这样在应用的清单中声明一个<uses-feature>元素:
<uses-featureandroid:name="android.hardware.camera"android:required="false"/>
理解用<uses-permision>元素声明的权限能够直接影响Google Play对应用程序的过滤是至关重要的。在下面的“暗示功能需求的权限”章节中,列出了所有的暗示功能需求的权限集,并因此而引发的过滤处理。
对于蓝牙功能的特殊处理
当Google Play针对蓝牙功能来判断过滤时,它会使用比以上描述稍微不同的规则。
如果应用程序在其清单的一个<uses-permission>元素中声明了一个蓝牙权限,但没有明确的在<uses-feature>元素中声明蓝牙功能,那么Google Play会检查应用程序被设计成要运行在哪个Android平台的版本上,这个版本在<uses-sdk>元素中被指定。
如下表所示,Google Play只会在应用程序把Android2.0(API Leve 5)或更高的版本作为最低版本或目标平台时,才会启用针对蓝牙功能的过滤。但是,要注意的是,当应用程序在<uses-feature>元素中明确声明了蓝牙功能时,Google Play会使用普通的规则来进行过滤处理。
表1:Google Play如何判断申请了蓝牙权限但却没有在<uses-feature>元素中声明蓝牙功能的应用程序的蓝牙功能需求:
minSdkVersion |
或targetSdkVersion |
结果 |
<=4(或者没有声明) |
<=4 |
对于任何报告其支持android.hardware.bluetooth功能的设备,Google Play不会把应用程序过滤掉。 |
<=4 |
>=5 |
对于任何不支持android.hardware.bluetooth功能的设备,Google Play都会把该应用程序过滤掉。 |
>=5 |
>=5 |
以下的例子,基于Google Play处理蓝牙功能的方式,演示了不同的过滤效果。
第一个例子,声明了蓝牙权限的应用程序被设计成要运行在比较旧的API Level上,但是它没有在其<uses-feature>元素中声明蓝牙功能。
结果:Google Play不会把应用程序从任何设备上过滤掉。
<manifest ...>
<uses-permissionandroid:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-sdkandroid:minSdkVersion="3"/>
...
</manifest>
第二个例子,相同的应用程序,还声明了一个目标API Level是5的属性。
结果:Google Play会假设应用程序需要蓝牙功能,并把应用程序从那些没有报告支持蓝牙功能的设备上过滤掉,包括那些运行较旧平台版本的的设备。
<manifest ...>
<uses-permissionandroid:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-sdkandroid:minSdkVersion="3"android:targetSdkVersion="5"/>
...
</manifest>
第三个例子,相同的应用程序,但声明的蓝牙功能需求。
结果:与第二个例子相同。
<manifest ...>
<uses-featureandroid:name="android.hardware.bluetooth"/>
<uses-permissionandroid:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-sdkandroid:minSdkVersion="3"android:targetSdkVersion="5"/>
...
</manifest>
最后一个例子。相同的应用程序,但<use-feature>元素中添加了android:required=”false”属性。
结果:Google Play会针对所有设备禁止使用基于蓝牙功能支持的过滤。
<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>
测试应用程序所需要的功能
可以使用包含在Android SDK中的aapt工具,来判断Google Play会怎样过滤自己的应用程序(基于应用声明的功能和权限)。用dump badging命令来运行aapt工具,执行该项测试工作。aapt工具会解析应用程序的清单文件,并且使用与Googl Play相同的规则,来判断应用程序所申请的功能。
以下是使用这个工具的步骤:
1. 首先,把应用程序作为一个未签名的.apk来编译并导出。如果使用带有ADT的Eclipse来开发应用程序,那么右击功能名,并选择Android Toos->Export Unsigned Application Package。选择目标文件名和路径,点击OK按钮。
2. 接下来,定位aapt工具,如果在环境变量PATH中没有设置它的路径,而且使用的是SDK Tools r8或更高的版本,那么可以在<SDK>/platform-tools/目录中找到该工具。
注意:所使用的aapt工具版本必须是提供给最新的可用的平台工具组件。如果没有,可以使用Android SDK Manager来下载。
3. 使用以下语法来运行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和基于功能的过滤(三)---硬件功能参考
功能参考
下面列出了关于软/硬件功能,以及能够暗示Google Play的权限的参考信息。
硬件功能
下面列出了被大多数当前发布的平台所支持的硬件功能描述。对于应用程序所使用或需求的每一个硬件功能,都要在一个独立的<uses-feature>元素的android:name属性中声明。
功能类型:Audio
功能描述符:Android.hardware.audio.low_latency
说明:
应用程序使用设备上的低延迟的音频通道,并且对于输入或的延迟或之后是敏感的。
备注:
功能类型:Audio
功能描述符:Android.hardware.audio.low_latency
说明:
应用程序要使用设备中的蓝牙无线电功能。
备注:
功能类型:Camera
功能描述符:android.hardware.camera
说明:
应用程序要使用设备的摄像头,如果设备支持多个摄像头,那么应用程序会使用屏幕背面的那个。
备注:
功能类型:Camera
功能描述符:android.hardware.camera.autofocus
说明:
摄像头的子功能。应用程序要使用设备摄像头的自动对焦能力。
备注:
功能类型:Camera
功能描述符:android.hardware.camera.flash
说明:
摄像头的子功能。应用程序要使用设备摄像头的闪光灯能力。
备注:
功能类型:Camera
功能描述符:android.hardware.camera.front
说明:
摄像头的子功能。应用程序要使用设备上的前置摄像头。
备注:
注意:声明Camera类型的子功能时,就暗示着声明了android.hardware.camera的父功能,除非声明了android:required=”false”。
功能类型:Location
功能描述符:android.hardware.location
说明:
应用程序会使用设备上的多种功能来判断位置,如GPS位置、网络位置、或蜂窝位置。
备注:
功能类型:Location
功能描述符:android.hardware.location.network
说明:
子功能,应用程序要从设备上所支持的基于网络的定位系统来获取大概的位置座标。
备注:
功能类型:Location
功能描述符:android.hardware.location.gps
说明:
子功能,应用程序使用了从设备上的全球定位系统接收器中获取精确的座标。
备注:
注意:声明Location的子功能时,就暗示着声明了android.hardware.location父功能,除非其声明了android:require=”false”
功能类型:Microphone
功能描述符:android.hardware.microphone
说明:
应用程序要使用设备上的麦克风。
备注:
功能类型:NFC
功能描述符:android.hardware.nfc
说明:
应用程序要使用设备中的近距离无线通信功能。
备注:
功能类型:Sensors
功能描述符:android.hardware.sensor.accelerometer
说明:
应用程序要使用设备上的加速度传感器的运动读数。
备注:
功能类型:Sensors
功能描述符:android.hardware.sensor.barometer
说明:
应用程序要使用设备的压力传感器。
备注:
功能类型:Sensors
功能描述符:android.hardware.sensor.compass
说明:
应用程序要使用设备上的罗盘来读取方向读数。
备注:
功能类型:Sensors
功能描述符:android.hardware.sensor.gyroscope
说明:
应用程序要使用设备上的陀螺仪。
备注:
功能类型:Sensors
功能描述符:android.hardware.sensor.light
说明:
应用程序要使用设备的亮度传感器。
备注:
功能类型:Sensors
功能描述符:android.hardware.sensor.proximity
说明:
应用程序要使用设备的近距离传感器。
备注:
功能类型:Screen
功能描述符:andrid.hardware.screen.landscape
说明:
应用程序需要横向屏幕
备注:
功能类型:Screen
功能描述符:android.hardware.screen.portrait
说明:
应用程序需要纵向屏幕
备注
注:例如:如果应用程序需要纵向屏幕,就应该声明<uses-feature android:name=”android.hardware.screen.portrait>,以便只有支持纵向的设备能够按照该应用程序。如果应用程序两个方向都支持,那么就不需要做任何声明。
默认情况下,这两个方向都被假定为不需要,因此应用程序可以安装在支持一个方向或两个方向都支持的设备上。但是,如果使用android:screenOrientation属性,设定应用程序要运行在一个特俗的设备上,那么还用这个功能声明给应用程序申请方向功能。例如,如果给android:screenOrientation属性声明了landscape、reverseLandscape、或sensorlandscape值,那么应用程序只对支持横向屏幕的设备有效。最好的实践是,依然使用<uses-feature>元素声明一个方向的功能请求。如果使用android:screenOrientation属性给Activity声明了一个方向,但实际却不需要该Activity,那么就能够通过使用包含android:require=”false”属性声明的<uses-feature>元素所声明的方向来禁止该功能需求。
为了向后兼容,任何运行只支持API Level 12或更低的平台版本的设备,都被假定为同时支持横向和纵向屏幕。
功能类型:Telephony
功能描述符:android.hardware.telephony
说明:
应用程序要使用设备设备上的电话功能,如带有数据通信服务的的无线电话。
备注:
功能类型:Telephony
功能描述符:android.hardware.telephony.cdma
说明:
子功能,应用程序要使用设备上的CDMA无线电话功能
备注:
功能类型:Telephony
功能描述符:android.hardware.telephony.gsm
说明:
子功能,应用程序要使用设备上的GSM无线电话功能。
备注:
注:这些子功能暗示着也声明了android.hardware.telephony父功能,除非该功能需求声明了android:require=”false”属性。
功能类型:Touchscreen
功能描述符:android.hardware.faketouch
说明:
应用程序要使用基本的触屏事件,如“click down”、“click up”和“drag”
备注:
当应用程序声明了这个功能需求时,则表明该应用程序只能跟提供了模拟触屏(fake touch 接口)操作的设备兼容。提供fake touch接口的设备会给用户提供一种模拟触屏能力的输入系统。例如,驱动屏幕光标提供fake touch接口的鼠标或远程控制。如果应用程序需要基本的点和click交互(换句话说,只有一个方向板(d-pad),应用程序是不会工作的),就应该声明这个功能,因为这是触屏交互的最低级别,这样应用程序也会跟提供更复杂的触屏交互的设备兼容。
注意:默认情况下,因为应用程序需要android.hardware.touchscreen功能,所以如果想要应用程序对提供了fake touch接口的设备有效,那么就必须通过声明<uses-feature android:name=”android.hardware.touchscreen” android:reuired=”false”>,来明确的声明触屏不是必须的。
功能类型:Touchscreen
功能描述符:android.hardware.multitouch.distinct
说明:
应用程序要在fake touch(假触屏)表面上执行区分两点以上触摸的轨迹的操作,这是fake touce功能的一个超集。
备注:
当应用程序声明了这个需求时,表明该应用程序只跟支持区分两点以上的模拟触屏事件的设备兼容。
跟通过android.hardware.touchscreen.multitouch.distinct定义的多点触控不同,支持在fake touch表面进行两点以上触控输入的设备,它不支持所有的双指手势,因为当前输入会被转换成平面上的光标移动。也就是说,在这样设备上的单指手势会移动光标,双指碰擦会导致单指的触屏事件;其他的双指手势会导致相应的双指触屏事件。例如:提供了移动光标的和多指触控的轨迹板,就是一种支持在fake touch表面执行区分多点触控的设备。
功能类型:Touchscreen
功能描述符:android.hardware.multitouch.jazzhand
说明:
应用程序要在fake touch(假触屏)表面上执行区分五点以上触摸的轨迹的操作,这是fake touce功能的一个超集。
备注:
当应用程序声明这个功能需求时,表明该应用程序只会跟支持区分五点以上轨迹的模拟触屏设备兼容。
跟通过android.hardware.touchscreen.multitouch.jazzhand定义的多点触控不同,该功能定义的输入设备表面不会支持所有的五指手势,因为该输入会转换成屏幕上的光标移动。也就是说,单指手势会移动设备上的光标,多指触碰手势会导致一个单指触碰事件;其他的多指手势会导致相应的多指触碰事件。例如:提供了移动光标的和多指触控的轨迹板,就是一种支持在fake touch表面执行区分多点触控的设备。
功能类型:Touchscreen
功能描述符:android.hardware.touchscreen
说明:
应用程序要使用比基本的触屏事件还要多的手势交互功能,如,抛物手势。该功能是基本faketouch功能的一个超集。
备注:
默认情况下,应用程序需要这个功能。因此,默认情况下,应用程序对只提供模拟触摸屏(fake touch)的设备是无效的。如果想要应用程序对提供模拟触摸屏的设备有效,就必须明确的声明触摸屏不是必须的,声明方式如下:<uses-feature name=”android:hardware.touchscreen” android:required=”false” />。即使应用程序不需要使用一个实际的触摸屏。
如果应用程序需要一个触摸屏(为了执行一些触碰手势),那么不需要做任何该功能的定义,因为默认这个功能是必须的。但是,最好还是明确的声明应用程序所要使用的全部功能,因此如果应用程序要使用该功能,依然还应该声明它。
如果需要更复杂的触摸交互,如多指手势,就应该声明下面的高级触屏功能。
功能类型:Touchscreen
功能描述符:android.hardware.touchscreen.multitouch
说明:
应用程序要使用多点触屏上的基本双点触摸功能,如掐捏手势,但不需要独立的轨迹跟踪。该功能是touchscreen功能的一个超集。
备注:
声明该功能,暗示着也声明了android.hardware.touchscreen父功能,除非该功能声明了android:required=”false”属性。
功能类型:Touchscreen
功能描述符:android.hardware.touchscreen.multitouch.distinct
说明:
子功能,应用程序要使用多点触屏设备的高级多点触摸功能,如两个以上完全独立的点的轨迹跟踪。它是multitouch功能的子集。
备注:
声明该功能,暗示着也声明了android.hardware.touchscreen.multitouch父功能,除非该功能声明了android:required=”false”属性。
功能类型:Touchscreen
功能描述符:android.hardware.touchscreen.multitouch.jazzhand
说明:
该应用程序要使用多点触屏设备的多点触摸功能,如五个以上完全独立的点的轨迹跟踪。它是multitouch功能的子集。
备注:
声明该功能,暗示着也声明了android.hardware.touchscreen.multitouch父功能,除非该功能声明了android:required=”false”属性。
功能类型:USB
功能描述符:android.hardware.usb.host
说明:
应用程序要使用USB主机模式功能(应用程序以主机的方式连接到USB设备上)
备注:
功能类型:USB
功能描述符:android.hardware.usb.accessory
说明:
应用程序要使用访问USB的功能(应用程序以USB设备的方式连接到USB主机上)。
备注:
功能类型:Wifi
功能描述符:Android.hardware.wifi
说明:
应用程序要使用设备上的802.11网络(wifi)功能。
备注:
Google Play和基于功能的过滤(四)
软件功能参考
下表中列出了由当前大多数发布的发布的Android平台所支持的软件功能描述符。对于应用程序要使用或需要的单一功能,都要在应用程序的清单的<uses-feature>元素中使用android:name属性来进行声明。
功能 |
属性值 |
说明 |
注释 |
Live Wallpaper |
android.software.live_wallpaper |
应用程序使用或提供Live Wallpapers |
|
SIP/VOIP |
android.software.sip |
应用程序要使用设备上的SIP服务 |
|
android.software.sip.voip |
子功能。应用程序要使用设备上的基于SIP的VOIP服务。 |
声明这个子功能,暗示着声明了android.software.sip父功能,除非声明该功能时也声明了android:required=”false” |
暗示功能需求的权限
在上面列出的一些功能常量中,要在相应的API发布之后,才对应用有效。例如,在Android2.2(API Level 8)中添加了android.hardware.bluetooth功能常量,但是它所指向的蓝牙API是在Android2.0(API Level 5)中被添加的。正因为这样,某些应用能够在有能力通过<uses-feature>元素声明其所需的API功能之前,就能够使用这些API。
要防止无意间让某些功能对应用程序有效,Google Play会假定某些相关硬件的权限,来指定默认情况下所需要的底层硬件功能。例如,使用蓝牙功能的应用程序必须在<uses-permission>元素中申请BLUETOOTH权限,对于旧版应用程序,Google Play会假定权限的声明,意味着应用程序需要底层的android.hardware.bluetooth功能,并且会基于该功能来过滤应用程序。
下表中列出的暗示功能需求的权限,等同于那些在<uses-feature>元素中声明的功能需求。要注意的是那些包含android:required属性的<uses-feature>声明,它的优先级要始终高于下表中所暗示的功能需求。
对于下表中的任何权限,都能够用带有android:required=”false”属性的<uses-feature>元素来明确的禁止基于暗示功能的过滤。例如,要禁止基于CAMERA权限的任何过滤,可以在其清单文件中添加以下<uses-feature>元素的声明:
<uses-featureandroid:name="android.hardware.camera"android:required="false"/>
分类 |
权限 |
暗示的功能需求 |
Bluetooth |
BLUETOOTH |
android.hardware.bluetooth (See Special handling for Bluetooth feature for details.) |
BLUETOOTH_ADMIN |
android.hardware.bluetooth |
|
Camera |
CAMERA |
android.hardware.cameraand |
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.networkand |
|
ACCESS_FINE_LOCATION |
android.hardware.location.gpsand |
|
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 |