android关闭权限管理,Android6.0权限管理以及使用权限该注意的地方

Android 6.0 Marshmallow首次增加了执行时权限管理，这对用户来说，能够更好的了解、控 制 app 涉及到的权限。然而对开发人员来说却是一件比較蛋疼的事情。须要兼容适配，并保证程序功能的正常执行。

什么叫执行时权限管理呢？在Android 6.0以下的系统中，当我们在安装应用的时候，该应用就会提示我们这个应用所须要的权限，假设你要安装。那就必须允许赋予全部权限，可是假设不允许，那就仅仅能取消安装了，有点流氓。并且安装完后，你不能够收回这个权限。

而6.0就做到了执行时权限管理。即使安装的时候给了权限，也能够到系统设置里。去关闭该权限。

以下分几种情况来讲，由于执行时权限仅仅有在Android6.0及以上的手机版本号才有，所以这里仅仅考虑设备版本号大于6.0的手机。低版本号的手机在安装时就已经赋予了全部的权限。也不可能收回，就不考虑了，以下的情况仅仅分targetSdkVersion：

targetSDKVersion大于等于23的时候，那么权限是能够被回收(revoke)。这里还要分权限。google将权限分为两种，一种是normal permission，还有一种是dangerous permission。

normal permission是指与用户隐私无关的权限。能够理解为无关紧要的权限，比方说訪问网络的权限。对用户来说没什么关系。dangerous permission就是会涉及到用户隐私的权限。比如读取用户手机联系人、短信等等。假设是normal permission的话，那么在安装的时候就会给，并且不会开放接口让用户回收该权限。app会一直拥有该权限，所以不用考虑这样的类型的权限。假设是dangerous permission的话，在安装的时候并未授予权限。系统开放接口允许用户回收或者赋予权限。以下是某个应用的权限，第一张图是dangerous permission。能够回收和赋予的。

点击上面的全部权限，能够查看到该应用全部的权限。

那么对于dangerous permission的话，在使用前须要去检查该permission是否已经被授予

checkSelfPermission(Manifest.permission.READ_PHONE_STATE) == PackageManager.PERMISSION_GRANTED

假设该权限已经被授予，那么可继续执行你的代码，假设未授予，则须要向用户询问是否须要授予权限。弹出的框是系统界面，界面例如以下：

调用代码：

requestPermissions(new String[]{Manifest.permission.READ_PHONE_STATE}, 1);

系统询问是否授予权限的页面结束后会有回调

@Override

public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {

super.onRequestPermissionsResult(requestCode, permissions, grantResults);

if (requestCode == 1) {

if(grantResults[0] == PackageManager.PERMISSION_GRANTED){

//your implementations

}else{

ToastUtil.show(this, "权限不足。支付失败");

}

}

}

假设targetSdkVersion是小于23的。那么将觉得app没实用23新权限測试过，那么继续使用老规则：系统在安装的时候会默认给app赋予全部的权限，app能够照常执行。可是！可是！可是！

用户依旧能够回收权限，只是此回收非彼回收。先看下关闭权限时弹的页面：

看到了么。假设targetSDKVersion小于23的话，在关闭权限的时候。会弹一个警告框，告诉你这是旧版的android，关闭会有问题，假设你按拒绝。那么该权限将会关闭。并且界面上。权限的开关会显示关。可是这个权限却没有被回收(nexus 5x的手机亲測。当然其它的机子我也不敢打包票)。checkSelfPermission返回granted。我看了下。假设targetSDKVersion等于23的话。系统日志是：

假设targetSDKVersion是小于23的话，则日志是:

Permission related app op changed.

只是我猜想假设你要支持runtime permission的话，还是要把targetSDKVersion设为23。假设你的targetSDKVersion是小于23的话，那么还是要加上checkSelfPermission，以防万一。谁知道google会出什么坑。

还有就是权限的话，有分组的概念，看例如以下图：

假设一组中有一个被授予了，那么组内的也会默认被授予。

并且也支持同一时候申请多个权限，详细情况android developer官网。

如有问题和错误的地方请指出。

以下就是要讲一些权限管理注意的地方。

对于权限的话，Activity和Fragment都有自己的requestPermissions和onRequestPermissionsResult回调，可是Activity是有checkSelfPermission。可是fragment是没有的，所以fragment假设想要检查权限，还得调用宿主activity的checkSelfPermission。

对了，平时直接调用checkSelfPermission和requestPermissions会报什么api错误，尽管编译不会通过，可是看着就是烦啊。能够调用ActivityCompat.checkSelfPermission(在supportv4包中)。

先看下Activity的requestSelfPermission这种方法：

public final void requestPermissions(@NonNull String[] permissions, int requestCode) {

Intent intent = getPackageManager().buildRequestPermissionsIntent(permissions);

startActivityForResult(REQUEST_PERMISSIONS_WHO_PREFIX, intent, requestCode, null);

}

看下这里是直接打开还有一个Activity进行操作，还用了startActivityForResult，回调会通过onRequestPermissionResult，我想这个回调应该是在onActivityResult里面处理。然后调这个onRequestPermissionResult函数的。

那么问题来了，假设我在onResume函数中申请某一个权限，调用requestPermissions，那么现象是什么样的呢？

第一次进入页面，弹出申请权限的对话框，假设点击允许。则正常，对话框不会再显示。可是假设第一次点击拒绝，则点击拒绝后重新弹出对话框来申请权限，假设你一直点拒绝。则对话框一直弹出，这是为什么呢？由于第一次进入页面并执行onResume函数时申请权限，进入还有一个页面。弹出对话框，假设你点击拒绝。先是回调onRequestPermissionResult，然后再执行onResume函数，这时又会再一次去检查权限，由于发现无权限，则再一次请求，如是，进入一个循环之中，除非你点允许，否则是个无限循环。

所以申请权限不妨不要写在onResume中，或者加一个标志位推断。

接下来再讲讲Fragment请求权限。

public final void requestPermissions(@NonNull String[] permissions, int requestCode) {

if (mHost == null) {

throw new IllegalStateException("Fragment " + this + " not attached to Activity");

}

mHost.onRequestPermissionsFromFragment(this, permissions,requestCode);

}

这里看到事实上是调用mHost请求权限的方法。mHost就是这个fragment的宿主Activity，所以Fragment请求权限实际上也是通过宿主Activity，当权限结果回调时，activity推断是从Fragment中来的还是从自己Activity中来的，再进行分发结果。