Android学习之AndroidManifest.xml清单之<uses-feature>
浏览数：56 /
时间：2015年06月11日
无意之中看了几个小时的官方英文文档，关于<uses-feature>的介绍。有必要在这里记录一下，应该有很多人不知道<uses-feature>到底是做什么用的，因为我们平时根本就没有用到它，用的最多的就是<uses-permisstion>。
官方的文档现在需要翻墙才能访问到，所以国内有些许公司或个人做了一个镜像，挺好的，大家可以来这里看官网文档：http://www.android-doc.com/guide/topics/manifest/uses-feature-element.html
好了，不多说了，文档我就不照着翻译了，其实大多都是较浅的内容，无非就是告诉你这个是干啥的，怎么用，举举例子等。我直接将重点，切入主题。
先声明一点，自己可能英语阅读能力稍差，有可能理解错误的地方还望大家指出来，我只描述我所理解了的部分。
1.<uses-feature>一般只对你的APP发布在GooglePlay的时候其作用，它协助GooglePlay来过滤您的应用程序，比如你明确的在你的程序清单中描述了你的程序必须使用哪些硬件或者软件相关的功能，则如果某些设备在GooglePlay上搜索应用时或者在某个程序的详情页上就会过滤掉不支持你的设备的程序。
简单的举个例子，比如你的这个设备没有照相机这个硬件，而某个APP的功能清单中明确列出了俺这个程序需要使用到照相机，所以，你的设备将不被允许安装该应用，这个大家如果使用过GooglePlay应该都有体会，GooglePlay上的程序并不是所有的设备都能安装的。
2.一般情况下我们不会在我们的程序清单中罗列处所有的<uses-faetue>，官方说有很多原因，比如你的是编译版本是低版本的（1.5），或者开发者误以为不需要这个清单，或者开发者把功能描述符写错了个别字符，或者根本不存在的字符，这些都是有可能的，总之，会有很多情况，导致一个程序的清单中不存在或者存在错误的<uses-feature>清单。所以Google提供了一个应急策略吧，可以这么理解吧。
因为一般情况下，我们的应用会声明各种权限，这里有必须说明一点，要区别<uses-featrue>和<uses-permisstion>，你声明了一个<uses-featrue android="android.hardware.camera" />并不代表你就可以不写<android:name="android.permission.CAMERA"/>权限说明了，我在第1点其实已经说了，<uses-featrue>其实是供GooglePlay用的，而<uses-permisstion>是供你的Android系统使用的，你想使用某个硬件设备或者软件功能就必须申请这个权限。
好了，扯多了，接着前面的说了，我举例子说明，这样最好理解，比如我在程序清单描述了使用照相机的权限，但是没有描述相应的<uses-feature>，则GooglePlay自动的认为你描述了对应与照相机的相应的<uses-feature>，即<uses-featrue android="android.hardware.camera" />。
但是可能有特殊情况，虽然我使用了照相机功能，但是可能这只是我的程序的一个辅助功能，可有可无的那种，那么你肯定希望不希望被GooglePlay把你的程序列为<uses-featrue android="android.hardware.camera" />，为什么看第1点说明，所以这个时候我们有必要明确的说明<uses-featrue android="android.hardware.camera" android:requied="false"/>，相信你能看得懂哈。
针对蓝牙功能的特殊处理
以上说明的规则适用于全部的功能，但是蓝牙除了上述的规则之外，提供了些许不同的规则。
1.如果一个设备使用<uses-permission>描述了使用蓝牙的权限，但是没有使用<uses-feature>描述蓝牙功能，那么GooglePlay将会依据清单中的<uses-sdk>来决定过滤信息。
2.蓝牙功能的描述只在安卓的系统版本在2.0或者之后的更高级版本中即SDK>=5。还是看看下面的这个表格吧，说的详细点。
If minSdkVersion is ... or targetSdkVersion is Result
<=4 (or uses-sdk is not declared) <=4 A：Google Play will not filter the application from any devicesbased on their reported support for theandroid.hardware.bluetoothfeature.
<=4 >=5 B：Google Play filters the application from any devices that do not support theandroid.hardware.bluetooth feature (includingolder releases).
>=5 >=5
A：GooglePlay将不会依据清单中的android.hardware.bluetoothfeature来过滤任何设备。
B：GooglePlay将会过滤掉全部设备，如果清单中没有提供android.hardware.bluetoothfeature描述。
* 这个应该比较重要吧，如果你的程序应用到了蓝牙，需要注意下这个点。
举些例子来说明吧，这样最直观是不是，嘿嘿：
例子1：
比如清单中这么写：
[java]
<manifest ...>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-sdk android:minSdkVersion="3" />
...
</manifest>
那么结果是：GooglePlay不会过滤任何设备搜到或者安装您的应用程序。（只是针对蓝牙的限制的，如果其他的有不满足的，照样过滤）
例子2：
比如清单中这么写：
[java]
<manifest ...>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
...
</manifest>
那么结果是：GooglePlay会假定你的程序要求蓝牙功能，会执行相应的过滤哟，如果某设备不支持蓝牙，那么你的程序将不在可安装行列中，即不被支持。
看下清单3：
[java]
<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>
效果和清单2是一样的，这里，其实你只要照着上面的表格所描述的规则就知道到底过滤不过滤了。
再看最后一个清单：
[java]
<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>
这个清单和上面的类似，就增加了一个
[java]
android:required="false"
，什么意思呢？上面的内容我描述过的，如果你明确的告诉GooglePlay我的这个功能不在过滤范围，那么将被忽略，GooglePlay将禁用过滤蓝牙功能针对所有的设备。
在SDK文件夹下面提供了一个aapt工具，可以用来测试GooglePlay基于你的feature和permisstion描述来如果过滤你的程序。操作步骤如下：
1.需要一个未前面的apk文件包，如果你使用的Eclipse和ADT插件来开发程序，那么你应该知道怎么导出吧！好吧，再说一次吧。选中你的工程，右击，选择Android Tools > Export Unsigned ApplicationPackage.选择你要导出的路径和文件名等，然后点击finish就可以了。
2.定位到你的aapt工具所在路径下，如果你没有把它配置到环境变量中的话，如果你使用的SDK Tools版本是r8或者更高版本的，那么在<你的SDK路径>/platform-tools/下，你最好使用最新的aapt工具，如果你没有最新的，请到这里下载最新的，Android SDK Manager。
3.使用这个语法来运行aapt。
$ aapt dump badging <path_to_exported_.apk>
path_to_exported_.apk：你刚才导出apk的路径，写完整的路径哟。
这里有一个上述清单2的输出结果：
[java]
$ ./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 Type Feature Descriptor Description Comments
Audio android.hardware.audio.low_latency The application uses a low-latency audio pipeline on the device andis sensitive to delays or lag in sound input or output.
Bluetooth android.hardware.bluetooth The application uses Bluetooth radio features in the device.
Camera android.hardware.camera The application uses the device‘s camera. If the device supports multiple cameras, the application uses the camera that facing away from the screen.
android.hardware.camera.autofocus Subfeature. The application uses the device camera‘s autofocus capability. These subfeatures implicitly declare theandroid.hardware.camera parent feature, unless declared withandroid: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.
Location android.hardware.location The application uses one or more features on the device for determininglocation, such as GPS location, network location, or cell location.
android.hardware.location.network Subfeature. The application uses coarse location coordinates obtained froma network-based geolocation system supported on the device. These subfeatures implicitly declare theandroid.hardware.location parent feature, unless declared withandroid:required="false".
android.hardware.location.gps Subfeature. The application uses precise location coordinates obtainedfrom 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.
Sensors android.hardware.sensor.accelerometer The application uses motion readings from an accelerometer on thedevice.
android.hardware.sensor.barometer The application uses the device‘s barometer.
android.hardware.sensor.compass The application uses directional readings from a magnetometer (compass) onthe 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.
Screen android.hardware.screen.landscape The 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 devicesthat support portrait orientation (whether always or by user choice) can install your app. If yourapplication supports both orientations, then you don‘t need to declare either.
Both orientations are assumed not required, by default, so your app may be installedon devices that support one or both orientations. However, if any of your activities request thatthey run in a specific orientation, using the android:screenOrientation attribute, then this also declares that the application requires thatorientation. For example, if you declare android:screenOrientation with either "landscape", "reverseLandscape", or"sensorLandscape", then your application will be available only to devices that supportlandscape orientation. As a best practice, you should still declare your requirement for thisorientation using a <uses-feature> element. If you declare an orientation for youractivity using android:screenOrientation, but don‘t actually require it, you can disable therequirement by declaring the orientation with a <uses-feature> element and includeandroid:required="false".
For backwards compatibility, any device running a platform version that supports only APIlevel 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 telephonyradio with data communication services.
android.hardware.telephony.cdma Subfeature. The application uses CDMA telephony radio features on thedevice. These subfeatures implicitly declare theandroid.hardware.telephony parent feature, unless declared withandroid:required="false".
android.hardware.telephony.gsm Subfeature. The application uses GSM telephony radio features on thedevice.
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 be 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", "clickup", and drag.
When declared as required, this indicates that the application is compatible with a deviceonly if it offers an emulated touchscreen ("fake touch" interface), or better. A device that offersa fake touch interface provides a user input system that emulates a subset of touchscreencapabilities. For example, a mouse or remote control that drives an on-screen cursor provides a faketouch interface. If your application requires basic point and click interaction (in otherwords, 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 withdevices that offer more complex touch interfaces.
Note: Because applications require the android.hardware.touchscreen feature by default, if you want your application to be available todevices that provide a fake touch interface, you must also explicitly declare that a touch screen isnot required by declaring <uses-featureandroid:name="android.hardware.touchscreen" android:required="false"/>
android.hardware.faketouch.multitouch.distinct The application performs distinct tracking of two or more "fingers" on a fake touchinterface. This is a superset of the faketouch feature.
When declared as required, this indicates that the application is compatible with a deviceonly if it supports touch emulation for events that supports distinct tracking of two or morefingers, or better.
Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.distinct, input devices that support distinct multi-touchwith a fake touch interface will not support all two-finger gestures, because the input isbeing transformed to cursor movement on the screen. That is, single finger gestures on such a devicemove a cursor; two-finger swipes will result in single-finger touch events; other two-fingergestures will result in the corresponding two-finger touch event. An example device that supportsdistinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movementwhich also supports two or more fingers.
android.hardware.faketouch.multitouch.jazzhand The application performs distinct tracking of five or more "fingers" on a fake touchinterface. This is a superset of the faketouch feature.
When declared as required, this indicates that the application is compatible with a deviceonly if it supports touch emulation for events that supports distinct tracking of five or morefingers.
Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.jazzhand, input devices that support jazzhand multi-touchwith a fake touch interface will not support all five-finger gestures, because the input is beingtransformed to cursor movement on the screen. That is, single finger gestures on such a device movea cursor; multi-finger gestures will result in single-finger touch events; other multi-fingergestures will result in the corresponding multi-finger touch event. An example device that supportsdistinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movementwhich also supports five or more fingers.
android.hardware.touchscreen The application uses touchscreen capabilities for gestures that are more interactivethan 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 notavailable to devices that provide only an emulated touch interface ("fake touch"), by default. Ifyou want your application available to devices that provide a fake touch interface (or even devicesthat provide only a d-pad controller), you must explicitly declare that a touch screen is notrequired, by declaring android.hardware.touchscreen with android:required="false".You should do so even if your application uses—but does not require—a realtouch screen interface.
If your application does require a touch interface (in order to perform touchgestures 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 shouldstill declare this if your app uses it.
If you require more complex touch interaction, such as multi-finger gestures, youshould declare the advanced touch screen features below.
android.hardware.touchscreen.multitouch The application uses basic two-point multitouch capabilities on the devicescreen, such as for pinch gestures, but does not need to track touches independently. Thisis a superset of touchscreen feature. This implicitly declares the android.hardware.touchscreen parent feature, unlessdeclared with android:required="false".
android.hardware.touchscreen.multitouch.distinct Subfeature. The application uses advanced multipoint multitouchcapabilities on the device screen, such as for tracking two or more points fullyindependently. This is a superset of multitouch feature. This implicitly declares the android.hardware.touchscreen.multitouchparent feature, unless declared with android:required="false".
android.hardware.touchscreen.multitouch.jazzhand The application uses advanced multipoint multitouchcapabilities on the device screen, for tracking up to five points fullyindependently. 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 USBdevices).
android.hardware.usb.accessory The application uses USB accessory features (behaves as the USB device and connects to USBhosts).
Wifi android.hardware.wifi The application uses 802.11 networking (wifi) features on the device.
软件方面：
Feature Attribute Value Description Comments
Live Wallpaper android.software.live_wallpaper The application uses or provides Live Wallpapers.
SIP/VOIP android.software.sip The application uses SIP service on the device.
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".
上面说过了，如果程序只提供了permisstion，那么会相应的暗示到对应的featrue，下面列出来这种对应关系，其实都不用想，猜都能猜的出来了就：
Category This Permission... Implies This Feature Requirement
Bluetooth BLUETOOTH android.hardware.bluetooth
(See Special handling for Bluetooth feature for details.)
BLUETOOTH_ADMIN android.hardware.bluetooth
Camera CAMERA android.hardware.camera and
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 and
android.hardware.location
ACCESS_FINE_LOCATION android.hardware.location.gps and
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
无意之中看了几个小时的官方英文文档，关于<uses-feature>的介绍。有必要在这里记录一下，应该有很多人不知道<uses-feature>到底是做什么用的，因为我们平时根本就没有用到它，用的最多的就是<uses-permisstion>。
官方的文档现在需要翻墙才能访问到，所以国内有些许公司或个人做了一个镜像，挺好的，大家可以来这里看官网文档：http://www.android-doc.com/guide/topics/manifest/uses-feature-element.html
好了，不多说了，文档我就不照着翻译了，其实大多都是较浅的内容，无非就是告诉你这个是干啥的，怎么用，举举例子等。我直接将重点，切入主题。
先声明一点，自己可能英语阅读能力稍差，有可能理解错误的地方还望大家指出来，我只描述我所理解了的部分。
1.<uses-feature>一般只对你的APP发布在GooglePlay的时候其作用，它协助GooglePlay来过滤您的应用程序，比如你明确的在你的程序清单中描述了你的程序必须使用哪些硬件或者软件相关的功能，则如果某些设备在GooglePlay上搜索应用时或者在某个程序的详情页上就会过滤掉不支持你的设备的程序。
简单的举个例子，比如你的这个设备没有照相机这个硬件，而某个APP的功能清单中明确列出了俺这个程序需要使用到照相机，所以，你的设备将不被允许安装该应用，这个大家如果使用过GooglePlay应该都有体会，GooglePlay上的程序并不是所有的设备都能安装的。
2.一般情况下我们不会在我们的程序清单中罗列处所有的<uses-faetue>，官方说有很多原因，比如你的是编译版本是低版本的（1.5），或者开发者误以为不需要这个清单，或者开发者把功能描述符写错了个别字符，或者根本不存在的字符，这些都是有可能的，总之，会有很多情况，导致一个程序的清单中不存在或者存在错误的<uses-feature>清单。所以Google提供了一个应急策略吧，可以这么理解吧。
因为一般情况下，我们的应用会声明各种权限，这里有必须说明一点，要区别<uses-featrue>和<uses-permisstion>，你声明了一个<uses-featrue android="android.hardware.camera" />并不代表你就可以不写<android:name="android.permission.CAMERA"/>权限说明了，我在第1点其实已经说了，<uses-featrue>其实是供GooglePlay用的，而<uses-permisstion>是供你的Android系统使用的，你想使用某个硬件设备或者软件功能就必须申请这个权限。
好了，扯多了，接着前面的说了，我举例子说明，这样最好理解，比如我在程序清单描述了使用照相机的权限，但是没有描述相应的<uses-feature>，则GooglePlay自动的认为你描述了对应与照相机的相应的<uses-feature>，即<uses-featrue android="android.hardware.camera" />。
但是可能有特殊情况，虽然我使用了照相机功能，但是可能这只是我的程序的一个辅助功能，可有可无的那种，那么你肯定希望不希望被GooglePlay把你的程序列为<uses-featrue android="android.hardware.camera" />，为什么看第1点说明，所以这个时候我们有必要明确的说明<uses-featrue android="android.hardware.camera" android:requied="false"/>，相信你能看得懂哈。
针对蓝牙功能的特殊处理
以上说明的规则适用于全部的功能，但是蓝牙除了上述的规则之外，提供了些许不同的规则。
1.如果一个设备使用<uses-permission>描述了使用蓝牙的权限，但是没有使用<uses-feature>描述蓝牙功能，那么GooglePlay将会依据清单中的<uses-sdk>来决定过滤信息。
2.蓝牙功能的描述只在安卓的系统版本在2.0或者之后的更高级版本中即SDK>=5。还是看看下面的这个表格吧，说的详细点。
If minSdkVersion is ... or targetSdkVersion is Result
<=4 (or uses-sdk is not declared) <=4 A：Google Play will not filter the application from any devicesbased on their reported support for theandroid.hardware.bluetoothfeature.
<=4 >=5 B：Google Play filters the application from any devices that do not support theandroid.hardware.bluetooth feature (includingolder releases).
>=5 >=5
A：GooglePlay将不会依据清单中的android.hardware.bluetoothfeature来过滤任何设备。
B：GooglePlay将会过滤掉全部设备，如果清单中没有提供android.hardware.bluetoothfeature描述。
* 这个应该比较重要吧，如果你的程序应用到了蓝牙，需要注意下这个点。
举些例子来说明吧，这样最直观是不是，嘿嘿：
例子1：
比如清单中这么写：
[java]
<manifest ...>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-sdk android:minSdkVersion="3" />
...
</manifest>
那么结果是：GooglePlay不会过滤任何设备搜到或者安装您的应用程序。（只是针对蓝牙的限制的，如果其他的有不满足的，照样过滤）
例子2：
比如清单中这么写：
[java]
<manifest ...>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
...
</manifest>
那么结果是：GooglePlay会假定你的程序要求蓝牙功能，会执行相应的过滤哟，如果某设备不支持蓝牙，那么你的程序将不在可安装行列中，即不被支持。
看下清单3：
[java]
<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>
效果和清单2是一样的，这里，其实你只要照着上面的表格所描述的规则就知道到底过滤不过滤了。
再看最后一个清单：
[java]
<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>
这个清单和上面的类似，就增加了一个
[java]
android:required="false"
，什么意思呢？上面的内容我描述过的，如果你明确的告诉GooglePlay我的这个功能不在过滤范围，那么将被忽略，GooglePlay将禁用过滤蓝牙功能针对所有的设备。
在SDK文件夹下面提供了一个aapt工具，可以用来测试GooglePlay基于你的feature和permisstion描述来如果过滤你的程序。操作步骤如下：
1.需要一个未前面的apk文件包，如果你使用的Eclipse和ADT插件来开发程序，那么你应该知道怎么导出吧！好吧，再说一次吧。选中你的工程，右击，选择Android Tools > Export Unsigned ApplicationPackage.选择你要导出的路径和文件名等，然后点击finish就可以了。
2.定位到你的aapt工具所在路径下，如果你没有把它配置到环境变量中的话，如果你使用的SDK Tools版本是r8或者更高版本的，那么在<你的SDK路径>/platform-tools/下，你最好使用最新的aapt工具，如果你没有最新的，请到这里下载最新的，Android SDK Manager。
3.使用这个语法来运行aapt。
$ aapt dump badging <path_to_exported_.apk>
path_to_exported_.apk：你刚才导出apk的路径，写完整的路径哟。
这里有一个上述清单2的输出结果：
[java]
$ ./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 Type Feature Descriptor Description Comments
Audio android.hardware.audio.low_latency The application uses a low-latency audio pipeline on the device andis sensitive to delays or lag in sound input or output.
Bluetooth android.hardware.bluetooth The application uses Bluetooth radio features in the device.
Camera android.hardware.camera The application uses the device‘s camera. If the device supports multiple cameras, the application uses the camera that facing away from the screen.
android.hardware.camera.autofocus Subfeature. The application uses the device camera‘s autofocus capability. These subfeatures implicitly declare theandroid.hardware.camera parent feature, unless declared withandroid: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.
Location android.hardware.location The application uses one or more features on the device for determininglocation, such as GPS location, network location, or cell location.
android.hardware.location.network Subfeature. The application uses coarse location coordinates obtained froma network-based geolocation system supported on the device. These subfeatures implicitly declare theandroid.hardware.location parent feature, unless declared withandroid:required="false".
android.hardware.location.gps Subfeature. The application uses precise location coordinates obtainedfrom 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.
Sensors android.hardware.sensor.accelerometer The application uses motion readings from an accelerometer on thedevice.
android.hardware.sensor.barometer The application uses the device‘s barometer.
android.hardware.sensor.compass The application uses directional readings from a magnetometer (compass) onthe 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.
Screen android.hardware.screen.landscape The 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 devicesthat support portrait orientation (whether always or by user choice) can install your app. If yourapplication supports both orientations, then you don‘t need to declare either.
Both orientations are assumed not required, by default, so your app may be installedon devices that support one or both orientations. However, if any of your activities request thatthey run in a specific orientation, using the android:screenOrientation attribute, then this also declares that the application requires thatorientation. For example, if you declare android:screenOrientation with either "landscape", "reverseLandscape", or"sensorLandscape", then your application will be available only to devices that supportlandscape orientation. As a best practice, you should still declare your requirement for thisorientation using a <uses-feature> element. If you declare an orientation for youractivity using android:screenOrientation, but don‘t actually require it, you can disable therequirement by declaring the orientation with a <uses-feature> element and includeandroid:required="false".
For backwards compatibility, any device running a platform version that supports only APIlevel 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 telephonyradio with data communication services.
android.hardware.telephony.cdma Subfeature. The application uses CDMA telephony radio features on thedevice. These subfeatures implicitly declare theandroid.hardware.telephony parent feature, unless declared withandroid:required="false".
android.hardware.telephony.gsm Subfeature. The application uses GSM telephony radio features on thedevice.
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 be 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", "clickup", and drag.
When declared as required, this indicates that the application is compatible with a deviceonly if it offers an emulated touchscreen ("fake touch" interface), or better. A device that offersa fake touch interface provides a user input system that emulates a subset of touchscreencapabilities. For example, a mouse or remote control that drives an on-screen cursor provides a faketouch interface. If your application requires basic point and click interaction (in otherwords, 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 withdevices that offer more complex touch interfaces.
Note: Because applications require the android.hardware.touchscreen feature by default, if you want your application to be available todevices that provide a fake touch interface, you must also explicitly declare that a touch screen isnot required by declaring <uses-featureandroid:name="android.hardware.touchscreen" android:required="false"/>
android.hardware.faketouch.multitouch.distinct The application performs distinct tracking of two or more "fingers" on a fake touchinterface. This is a superset of the faketouch feature.
When declared as required, this indicates that the application is compatible with a deviceonly if it supports touch emulation for events that supports distinct tracking of two or morefingers, or better.
Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.distinct, input devices that support distinct multi-touchwith a fake touch interface will not support all two-finger gestures, because the input isbeing transformed to cursor movement on the screen. That is, single finger gestures on such a devicemove a cursor; two-finger swipes will result in single-finger touch events; other two-fingergestures will result in the corresponding two-finger touch event. An example device that supportsdistinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movementwhich also supports two or more fingers.
android.hardware.faketouch.multitouch.jazzhand The application performs distinct tracking of five or more "fingers" on a fake touchinterface. This is a superset of the faketouch feature.
When declared as required, this indicates that the application is compatible with a deviceonly if it supports touch emulation for events that supports distinct tracking of five or morefingers.
Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.jazzhand, input devices that support jazzhand multi-touchwith a fake touch interface will not support all five-finger gestures, because the input is beingtransformed to cursor movement on the screen. That is, single finger gestures on such a device movea cursor; multi-finger gestures will result in single-finger touch events; other multi-fingergestures will result in the corresponding multi-finger touch event. An example device that supportsdistinct multi-touch with a fake touch interface is one that provides a trackpad for cursor movementwhich also supports five or more fingers.
android.hardware.touchscreen The application uses touchscreen capabilities for gestures that are more interactivethan 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 notavailable to devices that provide only an emulated touch interface ("fake touch"), by default. Ifyou want your application available to devices that provide a fake touch interface (or even devicesthat provide only a d-pad controller), you must explicitly declare that a touch screen is notrequired, by declaring android.hardware.touchscreen with android:required="false".You should do so even if your application uses—but does not require—a realtouch screen interface.
If your application does require a touch interface (in order to perform touchgestures 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 shouldstill declare this if your app uses it.
If you require more complex touch interaction, such as multi-finger gestures, youshould declare the advanced touch screen features below.
android.hardware.touchscreen.multitouch The application uses basic two-point multitouch capabilities on the devicescreen, such as for pinch gestures, but does not need to track touches independently. Thisis a superset of touchscreen feature. This implicitly declares the android.hardware.touchscreen parent feature, unlessdeclared with android:required="false".
android.hardware.touchscreen.multitouch.distinct Subfeature. The application uses advanced multipoint multitouchcapabilities on the device screen, such as for tracking two or more points fullyindependently. This is a superset of multitouch feature. This implicitly declares the android.hardware.touchscreen.multitouchparent feature, unless declared with android:required="false".
android.hardware.touchscreen.multitouch.jazzhand The application uses advanced multipoint multitouchcapabilities on the device screen, for tracking up to five points fullyindependently. 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 USBdevices).
android.hardware.usb.accessory The application uses USB accessory features (behaves as the USB device and connects to USBhosts).
Wifi android.hardware.wifi The application uses 802.11 networking (wifi) features on the device.
软件方面：
Feature Attribute Value Description Comments
Live Wallpaper android.software.live_wallpaper The application uses or provides Live Wallpapers.
SIP/VOIP android.software.sip The application uses SIP service on the device.
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".
上面说过了，如果程序只提供了permisstion，那么会相应的暗示到对应的featrue，下面列出来这种对应关系，其实都不用想，猜都能猜的出来了就：
Category This Permission... Implies This Feature Requirement
Bluetooth BLUETOOTH android.hardware.bluetooth
(See Special handling for Bluetooth feature for details.)
BLUETOOTH_ADMIN android.hardware.bluetooth
Camera CAMERA android.hardware.camera and
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 and
android.hardware.location
ACCESS_FINE_LOCATION android.hardware.location.gps and
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
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
