Android 6.0 运行时权限处理完全解析 及 三方库的使用

一、概述

Android6.0系统把权限分为两个级别：一个是Normal Permissions，即普通权限，这类权限不会潜藏有侵害用户隐私和安全的问题，比如，访问网络的权限，访问WIFI的权限等；另一类是Dangerous Permissions，即危险权限，这类权限会直接的威胁到用户的安全和隐私问题，比如说访问短信，相册等权限。但是到底哪些是普通权限和危险权限呢，这里给出分类，大家在使用时以便参考。1、Normal Permissions （普通权限）ACCESS_LOCATION_EXTRA_COMMANDSACCESS_NETWORK_STATEACCESS_NOTIFICATION_POLICYACCESS_WIFI_STATEBLUETOOTHBLUETOOTH_ADMINBROADCAST_STICKYCHANGE_NETWORK_STATECHANGE_WIFI_MULTICAST_STATECHANGE_WIFI_STATEDISABLE_KEYGUARDEXPAND_STATUS_BARGET_PACKAGE_SIZEINSTALL_SHORTCUTINTERNETKILL_BACKGROUND_PROCESSESMODIFY_AUDIO_SETTINGSNFCREAD_SYNC_SETTINGSREAD_SYNC_STATSRECEIVE_BOOT_COMPLETEDREORDER_TASKSREQUEST_IGNORE_BATTERY_OPTIMIZATIONSREQUEST_INSTALL_PACKAGESSET_ALARMSET_TIME_ZONESET_WALLPAPERSET_WALLPAPER_HINTSTRANSMIT_IRUNINSTALL_SHORTCUTUSE_FINGERPRINTVIBRATEWAKE_LOCKWRITE_SYNC_SETTINGS使用以上权限是不会威胁到用户安全的，所以这类权限是可以直接的在manifest里面直接的使用，而且在安装后也会直接的生效了。2、Dangerous Permissions （危险权限）SMS（短信）SEND_SMSRECEIVE_SMSREAD_SMSRECEIVE_WAP_PUSHRECEIVE_MMSSTORAGE（存储卡）READ_EXTERNAL_STORAGEWRITE_EXTERNAL_STORAGECONTACTS（联系人）READ_CONTACTSWRITE_CONTACTSGET_ACCOUNTSPHONE（手机）READ_PHONE_STATECALL_PHONEREAD_CALL_LOGWRITE_CALL_LOGADD_VOICEMAILUSE_SIPPROCESS_OUTGOING_CALLSCALENDAR（日历）READ_CALENDARWRITE_CALENDARCAMERA（相机）CAMERALOCATION（位置）ACCESS_FINE_LOCATIONACCESS_COARSE_LOCATIONSENSORS（传感器）BODY_SENSORSMICROPHONE（麦克风）RECORD_AUDIO危险权限和普通权限也有区别，普通权限是单条的权限，而危险权限是以组展示的，也就是说，当你接受一个危险权限时，不但但接受的是界面上展示的这一个权限，而是它所在这个组里面的其他所有访问权限也将会被自动获取权限，比如，一旦WRITE_CONTACTS被授权了，App也有READ_CONTACTS和GET_ACCOUNTS的权限了。值得注意的是，这类权限也是需要在manifest中注册的。

二、实例

实战部分分为几种情况，因为根据我们的目标SDK版本和Android真机版本的不同会有不同的情景，针对普通权限大家都熟悉，就不介绍了，下面一一介绍危险权限的使用情景：在介绍使用情景之前，先看下我的开发和真机的Android版本。我们这里以读取短信息为例讲解整个权限的使用：1、没有访问权限的情况下：首先我们先来设计下布局，如下：看下代码，很简单，就直接读取短息：然后，点击界面上的“读取收件箱中的短信”，相信大家都会知道发生什么情况，果然不出意外的程序直接崩溃了，打下日志：日志中很清晰的告诉我们，这个异常是因为没有权限而造成的，那么我们就直接给它加上读取短信的权限来看看吧。2、在manifest中添加了权限：在manifest中加了对读取短信的权限，你应该很高兴的等待着总共有多少条短信出现在我们的界面上，但是，事实很让人崩溃：再次出现了没有权限的异常，这是为什么呢？这里我们先不解决这个问题，先来想象一种实际的情况，假如你现有的APP里面有很多使用到了危险权限，有时候你并完全清楚到底在哪里使用了，但是你的目标版本又是像我的版本一样指向了6.0，而有可能用户的手机是6.0以上的版本，那么这时候你的APP就有可能会出现这种，那么在你还没查清楚有哪些地方使用了危险权限是，该怎么解决呢？那么你可以这么解决：修改你build.gradle 中的 targetSdkVersion 目标版本号：然后手机版本还是6.0以上，来看看结果：可以了，哈哈，你很高兴，确实是可以了。那么聪明的你或许意识到什么了，是的，以版本23，也就是android6.0位分割线，我们可以得出一个小结论：当targetSdkVersion >= 23，且真机版本 >= 23时，即使在manifest中添加了相应的危险权限，在没有做相应的处理时（至于怎么处理后面会讲），还时会出现限权的异常，这时manifest中的危险权限并没有起作用，但是还必须声明。当targetSdkVersion < 23，且真机版本 >= 23时，我们并没有做任何的相关处理，就得到了想要的访问权限，这说明在manifest中申请的危险权限起作用了。我们在来看另外一种情况，就是，假如我的手机比较旧，还没更新6.0的系统，这种情况下又该是什么情况呢？这次我们用个4.4.4版本的模拟机目标targetSdkVersion 为21 来看看结果：也是可以的，0条信息是因为我的模拟机上没短信，这个数字多少和我们没有关系。假如targetSdkVersion 为23呢，来看看结果：很清晰的看出，我们又得到了正确的结果。由此我们也得到了一个小结论：当我们的真机系统版本 < 23时，不管我们的targetSdkVersion 值是否大于23，都不会影响我们在manifest里面申请的权限，也就是说这时候真机的系统版本在起着主导作用。由上面的几条结论，我们应该很清晰的知道了访问权限在真机中的使用状况，但是我们的手机在升级，版本也会越来越高，因此我们现在的应用不可能一直只支持低版本的使用也不考虑兼顾高版本。所以现在APP权限升级是必然的趋势。那么现在回来解决上面遗留的问题，当真机和目标版本都大于6.0时出现的权限异常我们该怎么解决呢？主要分为三个步骤：1：检查是否拥有权限2：假如没有权限，则申请权限3：处理权限回调下面我们分别来看看这几个步骤。1：检查是否拥有权限检查是否已拥有了权限，可以使用ContextCompat.checkSelfPermission(Context context, String permission);checkSelfPermission方法中有两个参数，分别是上下文，以及所申请的权限。如果有权限，请让它直接去读取短信信息。如果没有权限则去申请。2：申请权限申请权限则是使用：public static void requestPermissions(final Activity activity,final String[] permissions, final int requestCode) {}requestPermissions方法中需要三个参数，当前的activity，所申请的权限，可以是多个，最后就是请求码，既然有请求码说明它会有一个回调，也就是我们下面要讲的处理回调。3：处理权限回调处理权限回调，需要在Activity中重写onRequestPermissionsResult方法：然后在方法内判断用户是授权了该权限组还是拒绝授权，如果授权则就去获取短信信息，否则，在这里我只是显示了一个toast提示框。这里再次说明下，权限组内只要有一个被授权，其他的权限也就有了权限，这也是为什么直接使用grantResults[0] == PackageManager.PERMISSION_GRANTED的原因。ok,下面来具体的界面显示：我们可以看到，当我们第一次点击读取短信时，它会先检查该应用是否有权限，如果没有，就去申请，这里在界面上对应的就是显示一个授权的对话框，第一次我们选择了拒绝授权，然后在回调里面就会对应先打印了我们的一个toast消失提醒我们拒绝了授权，但是当我们再次需要读取短信时，它还会去申请授权，这时我们允许授权，然后我们就看到了，在显示短信条数的TextView显示了短信的条数。（这里0条是因为的用的模拟器没有短信，这不是重点。）值得提醒的事，当我们第一次选择拒绝授权时，当再次点击读取短信时，这时在授权对话框中会多一个“不再提醒”的提示，当我们在拒绝了授权，并选择不再提醒时，那么会出现什么情况呢？请看演示：当多次拒绝并选择不提提醒，那么下次再去读取就不会在去申请授权，而是直接在回调中说明用户已拒绝授权。那么这时候假如用户出于某种需要必须得给应用授权该怎么做呢，其实很简单，在回调中，提醒用户去“设置”里面手动给应用授权，或是发个广播打开设置界面等等都可，这里和我显示的提醒“权限已被拒绝”基本一样，只需在稍微优化即可，这里不在演示。其实到这里已经差不多讲完，但是，有一个方法我们可以留一下，那就是shouldShowRequestPermissionRationale，这个方法默认返回false，但当用户在上一次已经拒绝过这个权限申请时，再次需要申请该权限时，就会返回ture，它的寓意是你已经拒绝了一次，结果又弹出个授权框，你需要给我一个解释，为什么要授权，也就是说对多次授权这个权限做出解释，以便用户知道为什么必须授权了才能够完成他操作。下面，来看看它的使用：我这里就简单的弹出个对话框，说明下为什么要用这个权限，然后再次去调用这个申请的权限的方法了，大家可以同回调的方法一起封装下，可以更好的应用。看下界面操作：

三、三方库的使用

虽然权限处理并不复杂，但是需要编写很多重复的代码，所以目前也有很多库对用法进行了封装，大家可以在github首页搜索:

android permission

，对比了几个库的使用方式，发现https://github.com/lovedise/PermissionGen这个库据我所见相比较而言使用算是比较简单的，那么就以这个库的源码为基础来讲解使用方法如下：

1、在activity 或 fragment中重写onRequestPermissionsResult()方法:

@Overridepublic void onRequestPermissionsResult(int requestCode, String[] permissions,      int[] grantResults) {PermissionGen.onRequestPermissionsResult(this, requestCode, permissions, grantResults);}

2、处理结果：

成功获取权限后：

@PermissionSuccess(requestCode = 100)
public void doSomething(){
Toast.makeText(this, "Contact permission is granted", Toast.LENGTH_SHORT).show();
}

获取权限失败后：

@PermissionFail(requestCode = 100)
public void doFailSomething(){
Toast.makeText(this, "Contact permission is not granted", t.LENGTH_SHORT).show();
}

最后，在需要请求权限的地方加上一句话即可：PermissionGen.with(MainActivity.this).addRequestCode(100).permissions(Manifest.permission.READ_CONTACTS,Manifest.permission.RECEIVE_SMS,Manifest.permission.WRITE_CONTACTS).request();或者PermissionGen.needPermission(ContactFragment.this, 100, new String[] {Manifest.permission.READ_CONTACTS, Manifest.permission.RECEIVE_SMS,Manifest.permission.WRITE_CONTACTS});