Android6.0之运行时权限

Android 6.0来了

　　Android 6.0 Marshmallow新增了运行时权限特性，还没有适配6.0系统的应用可能有点猝不及防了。这不用户反馈新买的最贵的华为手机打不开我们的应用。报的是权限异常，那就来看看android6.0新的权限特性到底是什么。

墙外的官方文档

　　自从developer.android.com无法访问后就很少看android官方文档了。但是网上的博文毕竟是别人消化过的，变味了。

　　其实完全可以阅读离线文档。我目前的开发环境是android studio + sdk代理，更新到sdk23版本，在sdk/doc目录下就是离线文档。再用火狐浏览器打开，脱机工作就大功告成了。

简介

　　通过主页Android6.0 Marshmallow展示的”Get started”链接跳到review页面，选择Behavior changes项，找到Runtime Permissions，简略翻译如下：

　　新的权限模型，允许用户在应用运行时直接管理应用权限。

　　如果你的应用targetSdkVersion是M Preview发布版或更高版本，请确保在运行时检查并获取权限。即使你的目标sdk不是M Preview发布版，也应该在新的权限模型下进行测试。

　　调用checkSelfPermission()方法确定权限是否已获取，调用requestPermissions去获取权限。

　　更多支持信息请参考Permissions页面。关于对应用的影响，请参考TestingGuide。

　　（译者注：这里有个坑，如果你在app/build.gradle和AndroidManifest.xml都配置了targetSdkVersion请确保二者统一，如果不统一，AndroidManifest.xml的配置会被app/build.gradle的配置覆盖。）

概述

　　点击上面的Permissions链接，跳到Preview-API Overview-Permissions，看一下详细内容：

　　新的权限系统兼容低版本sdk。

　　新的模型包含下面的特性：

在manifest声明权限：像早的平台一样；

权限组：权限被分到权限组里。比如CONTACTS权限组包含了读取和写入用户通讯录和个人信息的权限。

安装时特定权限：当用户安装或更新应用程序时，系统授予所有列在manifest里的级别为PROTECTION_NORMAL的权限。比如闹钟和因特网权限是PROTECTION_NORMAL级别权限，所以会在安装时被自动授予。

　　更多信息请参考Normal Permissions。

　　系统也会给一个应用程序授予签名权限，在System components and signature Permissions里有描述。在安装时不会提示签名权限。

用户运行时权限授予：当应用程序请求一个权限时，系统为用户展示一个对话框，然后调用应用程序的回调方法通知应用程序用户是否授予了该权限。

　　这个权限模型改变了你的应用程序使用需要权限的特性的方式。下面是你需要对此作出的调整。

总是检查权限：在应用程序进行需要权限的操作时，应该首先检查是否拥有这个权限。如果没有，需要请求授予权限。PROTECTION_NORMAL级别的权限除外。

优雅的处理权限缺失：如果应用程序没有被授予特定的权限，它必须明确的处理失败。比如，某个特性需要一项未被授予的权限，应用程序可以禁用它。如果非要使用这个权限，应用程序需要把相关的所有功能设为不可用，并且提示用户需要授予该权限。

权限是可撤销的：用户可以在任何时候撤销权限。如果用户关闭了一项应用权限，应用程序不会被通知到。你的应用程序需要在下次使用时再次确认是否拥有该权限。

权限组

　　相关的权限被分在权限组中，这样用户可以通过一次授权完成对组中所有权限的授权。用户只需要对应用程序授权一项权限，那么随后相同权限组中的权限会被自动授予。比如，假设应用程序的manifest中包含了SEND_SMS和RECEIVE_SMS两项权限，它们属于相同的权限组android.permission-group.SMS。当应用需要发送一条短信时，会请求SEND_SMS权限。系统展示给用户请求授权访问SMS的权限。如果用户同意了，系统会授予应用SEND_SMS权限。随后，当应用请求RECEIVE_SMS权限。系统会自动授予这个权限，因为用户已经批准了相同权限组中的权限。

系统组件以及签名权限

　　通常当用户安装应用时，系统只授权给应用manifest中PROTECTION_NORMAL级别的权限。

　　但是下面的几种情况系统会授予应用更多的权限：

系统组件自动被授予manifest中的所有权限。

如果应用的manifect中请求的权限是PROTECTION_SIGNATURE级别的权限，并且应用程序的签名证书与声明该权限的应用程序的签名证书一致，系统会在安装时授予应用程序这些权限。应用程序不能在运行时请求签名权限。

向前和向后兼容

　　如果应用程序目标sdk不是M版，应用程序继续在M版本设备上使用旧的权限模型。当用户安装应用程序时，系统会询问用户授权所有列在manifest里的权限。

　　注意：在运行M版本的设备上，用户能通过设置关闭任何应用的权限（包括旧的应用）。如果用户关闭了旧应用的权限，系统会默认禁用相应的功能。当应用程序试图进行需要这些权限的操作时，这个操作不一定会引发异常。相反的，它可能返回空的数据集、错误信号或者产生未预料的行为。比如，如果你在没有权限的情况下查看日历，会返回空的数据集。

　　如果你的应用运行在不是M版本的设备上，系统会像对待其他应用一样对待它：系统会在安装时询问用户声明的授权权限。

权限和Intent

　　一般情况下你有两种方式来完成一项任务。你可以请求被授予权限来完成这件事，或者通过发送intent给其他的应用来完成。

　　比如，假设你的应用需要调用相机拍摄一张图片。你的应用可以获取android.permission.CAMERA权限，这样你就可以直接访问相机，并调用相机api来

控制相机拍照。这样你可以控制拍照的全部过程并自己定义相机UI。

　　如果你不需要这样的控制，你可以使用ACTION_IMAGE_CAPTURE这个intent来获取图片。当你启动这个intent，会有选择相机应用的提示框提示给用户，用户可以通过这个相机应用拍照，相机应用通过你的onActivityResult()方法返回结果。

　　同样的，如果你想打电话、访问用户通讯录等等，你都可以通过创建相应的intent或者直接获取权限的方式。两种方式各有优劣。

　　如果你用权限：

可以完全控制用户体验，但是会增加任务的复杂性。

第一次的时候回提示用户获取权限。如果用户禁止了权限，你的应用就不能进行这项操作了。

　如果你用intent：

不需要自己定制ui。缺点是不能控制用户体验。

如果没有指定默认的应用，每次都会弹出选择框。

运行时权限编码

　　启用新的权限模型

　　将应用的targetSDKVersion设置为”MNC”，compileSDKVersion设置为”android-MNC”，你就启用了M开发版。必须将minSdkVersion指定为”MNC”才能启用发布版。

　　指定只针对M版的权限

　　在manifest中使用新的

<users-permission-sdk-m>

标签来表明该权限只针对M版。这样声明后，如果应用在老的设备上安装，系统不会提醒用户授权该项权限。安装更新也是一样。

　　在M版本上

<users-permission-sdk-m>

跟

<users-permission>

是一样的。

　　权限弹窗

　　检查应用运行在哪个平台上

　　新的权限模型只能用在M版设备上。在调用这些权限方法时必须判断Build.VERSION.CODENAME是否是”MNC”。

　　检查当前是否有某项权限时使用

　　Context.checkSelfPermission(permission_name)方法。比如检查拍照权限： Context.checkSelfPermission(Manifest.permission.CAMERA).

　　权限和权限组如下：



解释为什么需要权限

　　在一些情况下你也许需要帮助用户理解为什么需要一项权限。比如，如果用户登录了一个摄影应用，用户不会对它需要相机权限感到惊讶。但是如果用户关闭了这项权限，然后再次登录这个摄影应用，这时可能表明需要帮助用户理解为什么需要这项权限。

　　为了找出哪里需要做出额外的权限解释，系统提供了

Activity.shouldShowRequestPermissionRationale(String)方法。如果用户在授权提示框里拒绝了授权请求，这个方法会返回true。表明这里需要为用户做出解释。

　　如果用户在关闭权限时选择了“不再提醒”，这个方法会返回false。如果设备策略禁止了应用的这项权限同样会返回false。

请求权限

　　如果应用没有它需要的权限可以通过Activity.requestPermissions(String[], int)方法获取。参数是要获取的权限及请求码。这个请求是异步的：它立即返回并展示对话框，用户操作对话框后系统调用回调方法返回结果及跟requestPermissions相同的返回码。

if(checkSelfPermission(Manifest.permission.READ_CONTACTS)
!=PackageManager.PERMISSION_GRANTED){

// Should we show an explanation?
if(shouldShowRequestPermissionRationale(
Manifest.permission.READ_CONTACTS)){
// Explain to the user why we need to read the contacts
}

requestPermissions(newString[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);

// MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
// app-defined int constant

return;
}

　　处理权限响应

　　用户选择后的系统回调方法是Activity.onRequestPermissonResult(int, String[], int[])。你的应用需要覆写这个方法。比如：如果你请求READ_CONTACTS权限，你可以这样处理：

publicvoid onRequestPermissionsResult(int requestCode,
String permissions[],int[] grantResults){
switch(requestCode){
case MY_PERMISSIONS_REQUEST_READ_CONTACTS:{
if(grantResults[0]==PackageManager.PERMISSION_GRANTED){

// permission was granted, yay! do the
// calendar task you need to do.

}else{

// permission denied, boo! Disable the
// functionality that depends on this permission.
}
return;
}

// other 'switch' lines to check for other
// permissions this app might request
}
}

　　如果用户拒绝了权限请求，你可以采取适当的操作。比如：你可以弹出对话框解释为什么不能进行原来的操作。

　　当系统请求用户授权权限时，用户可以选择不再提醒。这种情况下，当应用调用requestPermissions()请求权限时，系统会立即拒绝该请求，并调用onRequestPermiResult()方法。所以，应用不能假设每次权限请求都会跟用户交互。

测试运行时权限

　　当你的应用目标sdk是M版本时，你必须处理好权限。你不能假设应用运行时拥有了某项权限。当应用运行时，很可能没有任何权限，用户可以在任何时候撤销或恢复权限。

　　你必须保证你的应用在任何权限状况下都表现良好。

新的adb命令和选项

　　M版本提供了几个新的命令来测试应用处理权限的场景。你可以用adb install 的-g选项来授权manifest里的所有权限。

$ adb install -g <path_to_apk>

　　你可以用新的pm命令来授权或撤销权限。可以将它用于自动化测试。

　　使用grant命令授权权限：

$ adb pm grant <package_name> <permission_name>

　　比如，授权com.example.myapp录音权限：

$ adb pm grant com.example.myapp android.permission.RECORD_AUDIO

　　使用revoke命令撤销权限：

$ adb pm revoke <package_name> <permission_name>

最佳实践及使用说明

　　新的权限模型提供了更顺畅的用户体验，也让用户能够更放心的安装应用并了解应用正在做的事情。下面是推荐的使用方式。

　　只请求你需要的权限

　　每次请求权限，你都在强迫用户做选择。如果用户拒绝了请求会削弱你的应用的功能。

　　你应该尽量少的做请求。

　　比如：通常你能够使用intent而不是权限来完成某项任务。

　　不要强迫用户

　　如果你一次请求了过多的权限，你可能在强迫用户并导致用户退出你的应用。相反的，你应该在需要的时候去请求权限。有些情况下，应用确实需要多个权限，这时，你应该在应用启动时尽早去请求权限。如果你的应用提供了教程，那么在教程的最后对必要的权限进行说明是很有必要的。

　　Normal Permissions

　　很多权限被定义为PROTECTION_NORMAL，这表明他们对用户隐私和安全造成的风险很小。比如，用户会很想知道一个应用是否会读取通讯录信息。相反，振动设备不会有太大的风险，所以它被指定为normal。

　　如果你在manifest里声明了normal级别的权限，你不需要调用

Activity.checkShelfPermission()或者Activity.requestPermissions方法。

　　目前PROTECTION_NORMAL级别的权限如下：

android.permission.ACCESS_LOCATION_EXTRA_COMMANDS

android.permission.ACCESS_NETWORK_STATE

android.permission.ACCESS_WIFI_STATE

android.permission.ACCESS_WIMAX_STATE

android.permission.BLUETOOTH

android.permission.BLUETOOTH_ADMIN

android.permission.BROADCAST_STICKY

android.permission.CHANGE_NETWORK_STATE

android.permission.CHANGE_WIFI_MULTICAST_STATE

android.permission.CHANGE_WIFI_STATE

android.permission.DISABLE_KEYGUARD

android.permission.EXPAND_STATUS_BAR

android.permission.FLASHLIGHT

android.permission.GET_ACCOUNTS

android.permission.GET_PACKAGE_SIZE

android.permission.INTERNET

android.permission.KILL_BACKGROUND_PROCESSES

android.permission.MODIFY_AUDIO_SETTINGS

android.permission.NFC

android.permission.PERSISTENT_ACTIVITY

android.permission.READ_SYNC_SETTINGS

android.permission.READ_SYNC_STATS

android.permission.READ_USER_DICTIONARY

android.permission.RECEIVE_BOOT_COMPLETED

android.permission.REORDER_TASKS

android.permission.SET_TIME_ZONE

android.permission.SET_WALLPAPER

android.permission.SET_WALLPAPER_HINTS

android.permission.SUBSCRIBED_FEEDS_READ

android.permission.TRANSMIT_IR

android.permission.VIBRATE

android.permission.WAKE_LOCK

android.permission.WRITE_SETTINGS

android.permission.WRITE_SYNC_SETTINGS

android.permission.WRITE_USER_DICTIONARY

com.android.alarm.permission.SET_ALARM

com.android.launcher.permission.INSTALL_SHORTCUT

－－－－－－－－全文完－－－－－－－－