版权声明:转载必须注明本文转自严振杰的博客: http://blog.yanzhenjie.com
这是一篇迟来的博客,Android M已经发布一年多了(6.0的变化),在Android M中权限系统被重新设计,发生了颠覆性的变化,很多人把握不好这个变化,一是对这个权限策略和套路还没有摸透,二是没有一个很好的实践来支撑,在我的技术开发群里很多人问我关于权限的问题,往往我都没有直接回答,因为这个问题不是一两句说的清楚的,这几点是今天我写这篇博客的原因。这里有一切关于Android运行时权限你需要知道的,包括如何在代码中实现,如果你以前不知道这些东西,现在来看也为时不晚,我将在详解之后给你一个最佳的实践方案。
由于项目一直在更新,更多新内容请直接看AndPermission开源主页:
https://github.com/yanzhenjie/AndPermission
AndPermission能解决大部分国产机遇到的权限问题,请参考:国产手机权限适配方案
AndPermission特性
- 链式调用,一句话申请权限,为你省去复杂的逻辑判断。
- 支持注解回调结果、支持Listener回调结果。
- 拒绝一次某权限后,再次申请该权限时可使用
Rationale
向用户说明申请该权限的目的,在用户同意后再继续申请,避免用户勾选不再提示而导致不能再次申请该权限。 - 就算用户拒绝权限并勾选不再提示,可使用
SettingDialog
提示用户去设置中授权。 RationaleDialog
和SettingDialog
允许开发者自定义。AndPermission
自带默认对话框除可自定义外,也支持国际化。- 支持在任何地方申请权限,不仅限于
Activity
和Fragment
等。
如果你的英文够好,推荐你阅读官网的文章:
关于运行时权限
在旧的权限管理系统中,权限仅仅在App安装时询问用户一次,用户同意了这些权限App才能被安装(某些深度定制系统另说),App一旦安装后就可以偷偷的做一些不为人知的事情了。
在Android6.0开始,App可以直接安装,App在运行时一个一个询问用户授予权限,系统会弹出一个对话框让用户选择是否授权某个权限给App(这个Dialog不能由开发者定制),当App需要用户授予不恰当的权限的时候,用户可以拒绝,用户也可以在设置页面对每个App的权限进行管理。
特别注意:这个对话框不是开发者调用某个权限的功能时由系统自动弹出,而是需要开发者手动调用,如果你直接调用而没有去申请权限的话,将会导致App崩溃。
也许你已经开始慌了,这对于用户来说是好事,但是对于开发者来说我们不能直接调用方法了,我们不得不在每一个需要权限的地方检查并请求用户授权,所以就引出了以下两个问题。
哪些权限需要动态申请
新的权限策略讲权限分为两类,第一类是不涉及用户隐私的,只需要在Manifest中声明即可,比如网络、蓝牙、NFC等;第二类是涉及到用户隐私信息的,需要用户授权后才可使用,比如SD卡读写、联系人、短信读写等。
不需要运行时申请的权限
此类权限都是正常保护的权限,只需要在AndroidManifest.xml中简单声明这些权限即可,安装即授权,不需要每次使用时都检查权限,而且用户不能取消以上授权,除非用户卸载App。
- ACCESS_LOCATION_EXTRA_COMMANDS
- ACCESS_NETWORK_STATE
- ACCESS_NOTIFICATION_POLICY
- ACCESS_WIFI_STATE
- BLUETOOTH
- BLUETOOTH_ADMIN
- BROADCAST_STICKY
- CHANGE_NETWORK_STATE
- CHANGE_WIFI_MULTICAST_STATE
- CHANGE_WIFI_STATE
- DISABLE_KEYGUARD
- EXPAND_STATUS_BAR
- GET_PACKAGE_SIZE
- INSTALL_SHORTCUT
- INTERNET
- KILL_BACKGROUND_PROCESSES
- MODIFY_AUDIO_SETTINGS
- NFC
- READ_SYNC_SETTINGS
- READ_SYNC_STATS
- RECEIVE_BOOT_COMPLETED
- REORDER_TASKS
- REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
- REQUEST_INSTALL_PACKAGES
- SET_ALARM
- SET_TIME_ZONE
- SET_WALLPAPER
- SET_WALLPAPER_HINTS
- TRANSMIT_IR
- UNINSTALL_SHORTCUT
- USE_FINGERPRINT
- VIBRATE
- WAKE_LOCK
- WRITE_SYNC_SETTINGS
需要运行时申请的权限
所有危险的Android系统权限属于权限组,如果APP运行在Android 6.0 (API level 23)
或者更高级别的设备中,而且targetSdkVersion>=23
时,系统将会自动采用动态权限管理策略,如果你在涉及到特殊权限操作时没有申请权限权限而直接调用了相关代码,你的App可能就崩溃了,综上所述你需要注意:
- 此类权限也必须在Manifest中申明,否则申请时不提示用户,直接回调开发者权限被拒绝。
- 同一个权限组的任何一个权限被授权了,这个权限组的其他权限也自动被授权。例如一旦
WRITE_CONTACTS
被授权了,App也有READ_CONTACTS
和GET_ACCOUNTS
了。 - 申请某一个权限的时候系统弹出的Dialog是对整个权限组的说明,而不是单个权限。例如我申请
READ_EXTERNAL_STORAGE
,系统会提示"允许xxx访问设备上的照片、媒体内容和文件吗?"
。
如果App运行在Android 5.1 (API level 22)
或者更低级别的设备中,或者targetSdkVersion<=22
时(此时设备可以是Android 6.0 (API level 23)
或者更高),在所有系统中仍将采用旧的权限管理策略,系统会要求用户在安装的时候授予权限。其次,系统就告诉用户App需要什么权限组,而不是个别的某个权限。
- CALENDAR(日历)
- READ_CALENDAR
- WRITE_CALENDAR
- CAMERA(相机)
- CAMERA
- CONTACTS(联系人)
- READ_CONTACTS
- WRITE_CONTACTS
- GET_ACCOUNTS
- LOCATION(位置)
- ACCESS_FINE_LOCATION
- ACCESS_COARSE_LOCATION
- MICROPHONE(麦克风)
- RECORD_AUDIO
- PHONE(手机)
- READ_PHONE_STATE
- CALL_PHONE
- READ_CALL_LOG
- WRITE_CALL_LOG
- ADD_VOICEMAIL
- USE_SIP
- PROCESS_OUTGOING_CALLS
- SENSORS(传感器)
- BODY_SENSORS
- SMS(短信)
- SEND_SMS
- RECEIVE_SMS
- READ_SMS
- RECEIVE_WAP_PUSH
- RECEIVE_MMS
- STORAGE(存储卡)
- READ_EXTERNAL_STORAGE
- WRITE_EXTERNAL_STORAGE
使用adb命令可以查看这些需要授权的权限组:
adb shell pm list permissions -d -g
使用adb命令同样可以授权/撤销某个权限:
adb shell pm [grant|revoke] <permission-name>...
关于运行时权限的一些建议
只请求你需要的权限,减少请求的次数,或用隐式Intent来让其他的应用来处理。
- 如果你使用Intent,你不需要设计界面,由第三方的应用来完成所有操作。比如打电话、选择图片等。
- 如果你请求权限,你可以完全控制用户体验,自己定义UI。但是用户也可以拒绝权限,就意味着你的应用不能执行这个特殊操作。
防止一次请求太多的权限或请求次数太多,用户可能对你的应用感到厌烦,在应用启动的时候,最好先请求应用必须的一些权限,非必须权限在使用的时候才请求,建议整理并按照上述分类管理自己的权限:
- 普通权限(Normal PNermissions):只需要在Androidmanifest.xml中声明相应的权限,安装即许可。
- 需要运行时申请的权限(Dangerous Permissions):
- 必要权限:最好在应用启动的时候,进行请求许可的一些权限(主要是应用中主要功能需要的权限)。
- 附带权限:不是应用主要功能需要的权限(如:选择图片时,需要读取SD卡权限)。
解释你的应用为什么需要这些权限:在你调用
requestPermissions()
之前,你为什么需要这个权限。- 例如,一个摄影的App可能需要使用定位服务,因为它需要用位置标记照片。一般的用户可能会不理解,他们会困惑为什么他们的App想要知道他的位置。所以在这种情况下,所以你需要在
requestpermissions()
之前告诉用户你为什么需要这个权限。
- 例如,一个摄影的App可能需要使用定位服务,因为它需要用位置标记照片。一般的用户可能会不理解,他们会困惑为什么他们的App想要知道他的位置。所以在这种情况下,所以你需要在
使用兼容库
support-v4
中的方法
ContextCompat.checkSelfPermission()
ActivityCompat.requestPermissions()
ActivityCompat.shouldShowRequestPermissionRationale()
几个重要的方法与常量解释
PackageManager中的两个常量:
- PackageManager.PERMISSION_DENIED:该权限是被拒绝的。
- PackageManager.PERMISSION_GRANTED:该权限是被授权的。
Activity中或者Fragment都会有以下几个方法:
int checkSelfPermission(String)
void requestPermissions(int, String...)
boolean shouldShowRequestPermissionRationale(String)
void onRequestPermissionsResult()
上述四个方法中,前三个方法在support-v4
的ActivityCompat
中都有,建议使用兼容库中的方法。最后一个方法是用户授权或者拒绝某个权限组时系统会回调Activity或者Fragment中的方法。
checkSelfPermission() 检查权限
- 检查某一个权限的当前状态,你应该在请求某个权限时检查这个权限是否已经被用户授权,已经授权的权限重复申请可能会让用户产生厌烦。
- 该方法有一个参数是权限名称,有一个int的返回值,用这个值与上面提到的两个常量做比较可判断检查的权限当前的状态。
if (ContextCompat.checkSelfPermission(context, Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
// 没有权限,申请权限。
}else{
// 有权限了,去放肆吧。
}
requestPermissions() 申请权限
- 请求用户授权几个权限,调用后系统会显示一个请求用户授权的提示对话框,App不能配置和修改这个对话框,如果需要提示用户这个权限相关的信息或说明,需要在调用 requestPermissions() 之前处理,该方法有两个参数:
- int requestCode,会在回调
onRequestPermissionsResult()
时返回,用来判断是哪个授权申请的回调。 - String[] permissions,权限数组,你需要申请的的权限的数组。
- int requestCode,会在回调
- 由于该方法是异步的,所以无返回值,当用户处理完授权操作时,会回调Activity或者Fragment的
onRequestPermissionsResult()
方法。
对于Activity我们直接调用requestPermissions(int, String[])
即可,不过这个方法是在api leve 23以上,所以我们为了适配可以是使用兼容包提供的方法:
ActivityCompat.requestPermissions(activity, new String[]{Manifest.permission.READ_CONTACTS}, MMM);
对于support包的Fragment
就可以直接调用requestPermissions(int, String[])
,对于app包的Fragment
就需要做版本判断了,这样就显得比较麻烦。
onRequestPermissionsResult() 处理权限结果回调
- 该方法在Activity/Fragment中应该被重写,当用户处理完授权操作时,系统会自动回调该方法,该方法有三个参数:
- int requestCode,在调用
requestPermissions()
时的第一个参数。 - String[] permissions,权限数组,在调用
requestPermissions()
时的第二个参数。 - int[] grantResults,授权结果数组,对应permissions,具体值和上方提到的PackageManager中的两个常量做比较。
- int requestCode,在调用
@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
switch (requestCode) {
case MMM: {
if (grantResults.length > 0
&& grantResults[0] == PackageManager.PERMISSION_GRANTED) {
// 权限被用户同意,可以去放肆了。
} else {
// 权限被用户拒绝了,洗洗睡吧。
}
return;
}
}
}
shouldShowRequestPermissionRationale()
- 望文生义,是否应该显示请求权限的说明。
- 第一次请求权限时,用户拒绝了,调用
shouldShowRequestPermissionRationale()
后返回true,应该显示一些为什么需要这个权限的说明。 - 用户在第一次拒绝某个权限后,下次再次申请时,授权的dialog中将会出现“不再提醒”选项,一旦选中勾选了,那么下次申请将不会提示用户。
- 第二次请求权限时,用户拒绝了,并选择了“不再提醒”的选项,调用
shouldShowRequestPermissionRationale()
后返回false。 - 设备的策略禁止当前应用获取这个权限的授权:
shouldShowRequestPermissionRationale()
返回false 。 - 加这个提醒的好处在于,用户拒绝过一次权限后我们再次申请时可以提醒该权限的重要性,免得再次申请时用户勾选“不再提醒”并决绝,导致下次申请权限直接失败。
综上所述,整合代码后:
if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_CONTACTS) != PackageManager.PERMISSION_GRANTED) {
// 没有权限。
if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.READ_CONTACTS)) {
// 用户拒绝过这个权限了,应该提示用户,为什么需要这个权限。
} else {
// 申请授权。
ActivityCompat.requestPermissions(thisActivity, new String[]{Manifest.permission.READ_CONTACTS}, MMM);
}
}
...
@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
switch (requestCode) {
case MMM: {
if (grantResults.length > 0
&& grantResults[0] == PackageManager.PERMISSION_GRANTED) {
// 权限被用户同意,可以去放肆了。
} else {
// 权限被用户拒绝了,洗洗睡吧。
}
return;
}
}
}
总结
从上面来看,判断很多,逻辑也很多,这样就加重了我们开发的负担,加上很多人反馈说国产手机有各种各样的bug,这样兼容起来就更加麻烦了,那么下面我就为大家介绍一个开源内裤来解决这一系列问题。
AndPermission
这个开源库名叫AndPermission:https://github.com/yanzhenjie/AndPermission,经过我的实践是完全解决了上述问题,推荐大家使用。
- Gradle
compile 'com.yanzhenjie:permission:1.0.6'
- Maven
<dependency>
<groupId>com.yanzhenjie</groupId>
<artifactId>permission</artifactId>
<version>1.0.5</version>
<type>pom</type>
</dependency>
- Eclipse 请放弃治疗
使用介绍
我建议看官去Github下载Demo
并阅读本文会帮助你理解。
申请权限
// 在Activity:
AndPermission.with(activity)
.requestCode(100)
.permission(Manifest.permission.WRITE_CONTACTS)
.rationale(...)
.callback(...)
.start();
// 在Fragment:
AndPermission.with(fragment)
.requestCode(100)
.permission(
// 多个权限,以数组的形式传入。
Manifest.permission.WRITE_CONTACTS,
Manifest.permission.READ_SMS
)
.rationale(...)
.callback(...)
.start();
// 在其它任何地方:
AndPermission.with(context)
.requestCode(100)
.permission(
Manifest.permission.WRITE_CONTACTS,
Manifest.permission.READ_SMS
)
.rationale(...)
.callback(...)
.start();
接受回调结果
接受回调结果目前有两种方式:一、Listener
方式,二、注解方式。
方式一:Listener方式回调
在callback()
方法传入PermissionListener
即可,授权成功或者失败至少会回调其中一个方法。
AndPermission.with(context)
...
.requestCode(200)
.callback(listener)
.start();
private PermissionListener listener = new PermissionListener() {
@Override
public void onSucceed(int requestCode, List<String> grantedPermissions) {
// 权限申请成功回调。
// 这里的requestCode就是申请时设置的requestCode。
// 和onActivityResult()的requestCode一样,用来区分多个不同的请求。
if(requestCode == 200) {
// TODO ...
}
}
@Override
public void onFailed(int requestCode, List<String> deniedPermissions) {
// 权限申请失败回调。
if(requestCode == 200) {
// TODO ...
}
}
};
方式二:注解方式回调
在callback()
方法传入你的回调方法所在实例的对象即可。
AndPermission.with(context)
...
.requestCode(300)
.callback(this)
.start();
// 成功回调的方法,用注解即可,这里的300就是请求时的requestCode。
@PermissionYes(300)
private void getPermissionYes(List<String> grantedPermissions) {
// TODO 申请权限成功。
}
@PermissionNo(300)
private void getPermissionNo(List<String> deniedPermissions) {
// TODO 申请权限失败。
}
如果你会用了,你就可以大刀阔斧的干了,博客中讲到的各种复杂逻辑,AndPermission
自动完成。
Rationale能力
Android
运行时权限有一个特点,在拒绝过一次权限后,再此申请该权限,在申请框会多一个[不再提示]的复选框,当用户勾选了[不再提示]并拒绝了权限后,下次再申请该权限将直接回调申请失败。
因此Rationale
功能是在用户拒绝一次权限后,再次申请时检测到已经申请过一次该权限了,允许开发者弹窗说明申请权限的目的,获取用户的同意后再申请权限,避免用户勾选不再提示,导致不能再次申请权限。
方式一:使用AndPermssion默认MD风格对话框
AndPermission.with(this)
...
.requestCode(...)
.rationale((requestCode, rationale) ->
// 此对话框可以自定义,调用rationale.resume()就可以继续申请。
AndPermission.rationaleDialog(context, rationale).show()
)
.start()
方式二:自定义对话框
AndPermission.with(this)
...
.requestCode(...)
.rationale(rationaleListener)
.start()
/**
* Rationale支持,这里自定义对话框。
*/
private RationaleListener rationaleListener = (requestCode, rationale) -> {
AlertDialog.newBuilder(this)
.setTitle("友好提醒")
.setMessage("你已拒绝过定位权限,沒有定位定位权限无法为你推荐附近的妹子,你看着办!")
.setPositiveButton("好,给你", (dialog, which) -> {
rationale.resume();
})
.setNegativeButton("我拒绝", (dialog, which) -> {
rationale.cancel();
}).show();
};
提示用户在系统设置中授权
当用户拒绝权限并勾选了不再提示时,此时再次申请权限时将会直接回调申请失败,因此AndPermission
提供了一个供用户在系统Setting
中给我们授权的能力。
我们在授权失败的回调方法中添加如下代码,以下三种选择一种即可:
// 是否有不再提示并拒绝的权限。
if (AndPermission.hasAlwaysDeniedPermission(activity, deniedPermissions)) {
// 第一种:用AndPermission默认的提示语。
AndPermission.defaultSettingDialog(activity, 400).show();
// 第二种:用自定义的提示语。
AndPermission.defaultSettingDialog(activity, 400)
.setTitle("权限申请失败")
.setMessage("您拒绝了我们必要的一些权限,已经没法愉快的玩耍了,请在设置中授权!")
.setPositiveButton("好,去设置")
.show();
// 第三种:自定义dialog样式。
SettingService settingService = AndPermission.defineSettingDialog(activity, 400);
...
// 你的dialog点击了确定调用:
settingService.execute();
// 你的dialog点击了取消调用:
settingService.cancel();
}
如果你是在Activity/Fragment
中调用的上述代码,那么当用户在系统Setting
中操作完成后,会回调Activity/Fragment
中的这个方法:
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
switch (requestCode) {
case 400: { // 这个400就是你上面传入的数字。
// 你可以在这里检查你需要的权限是否被允许,并做相应的操作。
break;
}
}
}
混淆
- 如果使用
Listener
接受回调结果,不用任何配置。 - 使用注解的方式回调结果,在
proguard
中添加如下配置:
-keepclassmembers class ** {
@com.yanzhenjie.permission.PermissionYes <methods>;
}
-keepclassmembers class ** {
@com.yanzhenjie.permission.PermissionNo <methods>;
}
国产手机适配方案
AndPermission是严格按照Android
系统的运行时权限
设计的,并最大限度上兼容了国产手机,目前发现的国产手机bug及解决方案:
- 部分中国厂商生产手机(例如小米某型号)的
Rationale
功能,在第一次拒绝后,第二次申请时不会返回true
,并且会回调申请失败,也就是说在第一次决绝后默认勾选了不再提示
,所以建议一定使用SettingDialog
:提示用户在系统设置中授权。 - 部分中国厂商生产手机(例如小米、华为某型号)在申请权限时,用户点击确定授权后,还是回调我们申请失败,这个时候其实我们是拥有权限的,所以我们可以在失败的方法中使用
AppOpsManager
进行权限判断,AndPermission
已经封装好了:
if(AndPermission(context, permission1, permission2)) {
// 执行操作。
}
- 部分中国厂商生产手机(例如vivo、pppo某型号)在用户允许权限,并且回调了权限授权陈功的方法,但是实际执行代码时并没有这个权限,建议开发者在回调成功的方法中也利用
AppOpsManager
判断下:
if(AndPermission(context, permission1, permission2)) {
// 执行操作。
} else {
// 提醒用户手机问题,请用户去Setting中授权。这里可以使用AndPermission的SettingDialog。
}
- 部分开发者反馈,在某些手机的
Setting
中授权后实际,检查时还是没有权限,部分执行代码也是没有权限,这种手机真的兼容不到了,我也觉得没必要兼容了,建议直接放弃这种平台。
最后希望咱中国Android手机厂商早日修复这些问题,祝你们事业越来越成功,产品越做越好。
版权声明:转载必须注明本文转自严振杰的博客: http://blog.yanzhenjie.com