android permission权限与安全机制解析（下）

　　刚建了一个QQ群，感兴趣的大家一起多多交流：544645972

　　在android permission权限与安全机制解析（上）篇博客中，我已经详细介绍了android相关系统permission和自定义permission，以及一些权限机制和安全机制。这篇博客主要将会介绍到android 6.0的相关权限更改，原理和相关的处理方式，解决方法等。

　　就以我以前的一个仿最新版微信相册为例子来分析。

android 6.0权限全面详细分析和解决方案

Marshmallow版本权限修改

　　android的权限系统一直是首要的安全概念，因为这些权限只在安装的时候被询问一次。一旦安装了，app可以在用户毫不知晓的情况下访问权限内的所有东西，而且一般用户安装的时候很少会去仔细看权限列表，更不会去深入了解这些权限可能带来的相关危害。所以在android 6.0 Marshmallow版本之后，系统不会在软件安装的时候就赋予该app所有其申请的权限，对于一些危险级别的权限，app需要在运行时一个一个询问用户授予权限。

　　

旧版本app兼容问题

　　那么问题来了，是不是所有以前发布的app都会出现问题呢？答案是不会，只有那些targetSdkVersion 设置为23和23以上的应用才会出现异常，在使用危险权限的时候系统必须要获得用户的同意才能使用，要不然应用就会崩溃，出现类似

java.lang.SecurityException: Permission Denial: reading com.android.providers.media.MediaProvider

的崩溃日志。所以targetSdkVersion如果没有设置为23版本或者以上，系统还是会使用旧规则：在安装的时候赋予该app所申请的所有权限。所以app当然可以和以前一样正常使用了，但是还有一点需要注意的是6.0的系统里面，用户可以手动将该app的权限关闭，如下图

　　


　　那么问题又来了，虽然会弹出提示，但是如果以前的老应用申请的权限被用户不管提示强行手动关闭了怎么办，应用会崩溃么？我们来试一试

　　


　　好吧，可以庆幸了一下了，不会抛出异常，不会崩溃，只不过调用那些被用户禁止权限的api接口返回值都为null或者0，所以我们只需要做一下判空操作就可以了，不判空当然还是会崩溃的喽。

普通权限和危险权限列表

　　现在对于新版本的权限变更应该有了基本的认识，那么，是不是所有权限都需要去进行特殊处理呢？当然不是，只有那些危险级别的权限才需要，如列表所示：

　　


　　android开发者官网也有相关描述：

　　http://developer.android.com/training/permissions/requesting.html

　　http://developer.android.com/guide/topics/security/permissions.html#normal-dangerous

　　所以仔细去看看自己的app，对照列表，如果有需要申请其中的一个权限，就需要进行特殊操作。还有一个比较人性的地方就是如果同一组的任何一个权限被授权了，其他权限也自动被授权。例如，一旦WRITE_EXTERNAL_STORAGE被授权了，app也有READ_EXTERNAL_STORAGE权限了。

支持Marshmallow新版本权限机制

　　终于要开始支持android 6.0版本了，最先一步当然就是修改build.gradle文件中的tragetSdkVersion和compileSdkVersion成23版本，同时使用compile ‘com.android.support:appcompat-v7:23.1.1’最新v7包。

android {
compileSdkVersion 23
...

defaultConfig {
...
targetSdkVersion 23
...
}
}
...
dependencies {
...
compile 'com.android.support:appcompat-v7:23.1.1'
...

　　修改完后，感兴趣的朋友可以直接打包在手机上测试一下，看看是不是会出现类似于上面我说的那些崩溃日志。

　　接着下一步当然就是要修改代码了，最原始代码，无任何处理：

private void startGetImageThread(){
....
Uri uri = MediaStore.Images.Media.EXTERNAL_CONTENT_URI;
ContentResolver contentResolver = getContentResolver();
//获取jpeg和png格式的文件，并且按照时间进行倒序
Cursor cursor = contentResolver.query(uri, null, MediaStore.Images.Media.MIME_TYPE + "=\"image/jpeg\" or " +
MediaStore.Images.Media.MIME_TYPE + "=\"image/png\"", null, MediaStore.Images.Media.DATE_MODIFIED+" desc");
....
}

　　这段代码需要访问外部存储（相册图片），属于危险级别的权限，直接使用会造成应用崩溃，所以在这段代码执行之前我们需要进行特殊处理：

int hasWriteContactsPermission = checkSelfPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE);
if (hasWriteContactsPermission != PackageManager.PERMISSION_GRANTED) {
requestPermissions(new String[] {Manifest.permission.WRITE_EXTERNAL_STORAGE},
CODE_FOR_WRITE_PERMISSION);
return;
}

　　写完这段代码之后，就会出现如下系统dialog：

　　


　　紧接着就需要去处理DENY和ALLOW的回调了，重写onRequestPermissionsResult函数：

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
if (requestCode == CODE_FOR_WRITE_PERMISSION){
if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE)
&&grantResults[0] == PackageManager.PERMISSION_GRANTED){
//用户同意使用write
startGetImageThread();
}else{
//用户不同意，自行处理即可
finish();
}
}
}

　　好了，这样就算是简单初步适配完成了。

特殊权限

　　还有非常重要的两个特殊权限也要着重讲一下，这两个权限很敏感，google告诉我们绝大多数应用不需要申请这两个权限，在Android系统中，主要有两个：
SYSTEM_ALERT_WINDOW，设置悬浮窗；
WRITE_SETTINGS 修改系统设置
　　关于上面两个特殊权限的授权，做法是使用 startActivityForResult 启动授权界面来完成。

SYSTEM_ALERT_WINDOW

　　想要实现一个悬浮窗，之前的解决方法很简单，在 Manifest 文件中添加

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />

权限，接着设置 WindowManager.LayoutParams.type 为 WindowManager.LayoutParams.TYPE_SYSTEM_ERROR 就可以了。这种方法在 6.0 之前是可以的，但是在 M 版本之后，会如下的错误：

android.view.WindowManager$BadTokenException: Unable to add window android.view.ViewRootImpl$W@83908c9 -- permission denied for this window type

6.0之后，google 对权限的管理更加严格了，现在需要弹出悬浮框，不光要在 Manifest 中静态申请，而且需要进行如下的动态申请：

private static final int REQUEST_CODE = 1;

private void requestAlertWindowPermission() {
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION);
intent.setData(Uri.parse("package:" + getPackageName()));
startActivityForResult(intent, REQUEST_CODE);
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
if (requestCode == REQUEST_CODE) {
if (Settings.canDrawOverlays(this)) {
Log.i(LOGTAG, "onActivityResult granted");
}
}
}

上述代码需要注意的是
使用Action Settings.ACTION_MANAGE_OVERLAY_PERMISSION 启动隐式Intent
使用 “package:” + getPackageName() 携带App的包名信息
使用 Settings.canDrawOverlays 方法判断授权结果
　　在用户开启相关权限之后才能使用 WindowManager.LayoutParams.TYPE_SYSTEM_ERROR ,要不然是会直接崩溃的哦，其实事实并没有那么简单，比这个复杂多了，详情请看我的博客：Android 悬浮窗权限各机型各系统适配大全。

WRITE_SETTINGS

　　这个权限的用法主要是用来读取和更改系统设置，和上一个权限一样是需要先在 Manifest 中静态注册完之后再通过下面代码进行动态申请：

private static final int REQUEST_CODE_WRITE_SETTINGS = 2;

private void requestWriteSettings() {
Intent intent = new Intent(Settings.ACTION_MANAGE_WRITE_SETTINGS);
intent.setData(Uri.parse("package:" + getPackageName()));
startActivityForResult(intent, REQUEST_CODE_WRITE_SETTINGS);
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
if (requestCode == REQUEST_CODE_WRITE_SETTINGS) {
if (Settings.System.canWrite(this)) {
Log.i(LOGTAG, "onActivityResult write settings granted");
}
}
}

上述代码需要注意的是
使用Action Settings.ACTION_MANAGE_WRITE_SETTINGS 启动隐式Intent
使用 “package:” + getPackageName() 携带App的包名信息
使用 Settings.System.canWrite 方法检测授权结果

PACKAGE_USAGE_STATS

　　这个权限需要单独拿出来说一下，API23版本添加，用来提供给应用手机相关组件的使用统计，该权限也需要用户在Setting页面单独授权才可使用。例如，改权限可以用来收集最近打开的应用，具体的可以看看android WindowManager解析与骗取QQ密码案例分析。具体的使用方法是现在 manifest 中注册：

<uses-permission
android:name="android.permission.PACKAGE_USAGE_STATS"
tools:ignore="ProtectedPermissions" />

注册完之后，继续在代码中检测改权限是否被允许，如果没有，去Setting页面让用户手动开启：

private boolean checkUsagePermission() {
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.KITKAT) {
AppOpsManager appOps = (AppOpsManager) getSystemService(Context.APP_OPS_SERVICE);
int mode = 0;
mode = appOps.checkOpNoThrow("android:get_usage_stats", android.os.Process.myUid(), getPackageName());
boolean granted = mode == AppOpsManager.MODE_ALLOWED;
if (!granted) {
Intent intent = new Intent(Settings.ACTION_USAGE_ACCESS_SETTINGS);
startActivityForResult(intent, 1);
return false;
}
}
return true;
}
...
@TargetApi(Build.VERSION_CODES.M)
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
if (requestCode == 1) {
AppOpsManager appOps = (AppOpsManager) getSystemService(Context.APP_OPS_SERVICE);
int mode = 0;
mode = appOps.checkOpNoThrow("android:get_usage_stats", android.os.Process.myUid(), getPackageName());
boolean granted = mode == AppOpsManager.MODE_ALLOWED;
if (!granted) {
Toast.makeText(this, "请开启该权限", Toast.LENGTH_SHORT).show();
}
}
}

这样当改权限被用户手动开启之后就能够成功使用了。

处理不再提醒

　　如果用户拒绝某授权。下一次弹框，用户会有一个“不再提醒”的选项的来防止app以后继续请求授权。

　　


　　如果这个选项在拒绝授权前被用户勾选了。下次为这个权限请求requestPermissions时，对话框就不弹出来了，系统会直接回调onRequestPermissionsResult函数，回调结果为最后一次用户的选择。所以为了应对这种情况，系统提供了一个shouldShowRequestPermissionRationale()函数，这个函数的作用是帮助开发者找到需要向用户额外解释权限的情况，这个函数：
应用安装后第一次访问，直接返回false；
第一次请求权限时，用户拒绝了，下一次shouldShowRequestPermissionRationale()返回 true，这时候可以显示一些为什么需要这个权限的说明；
第二次请求权限时，用户拒绝了，并选择了“不再提醒”的选项时：shouldShowRequestPermissionRationale()返回 false；
设备的系统设置中禁止当前应用获取这个权限的授权，shouldShowRequestPermissionRationale()返回false；
　　注意：第二次请求权限时，才会有“不再提醒”的选项，如果用户一直拒绝，并没有选择“不再提醒”的选项，下次请求权限时，会继续有“不再提醒”的选项，并且shouldShowRequestPermissionRationale()也会一直返回true。

　　所以利用这个函数我们可以进行相应的优化，针对shouldShowRequestPermissionRationale函数返回false的处理有两种方法：如果应用是第一次请求该权限，则直接调用requestPermissions函数去请求权限；如果不是则代表用户勾选了’不再提醒’，弹出dialog，告诉用户为什么你需要该权限，让用户自己手动开启该权限。链接：http://stackoverflow.com/questions/32347532/android-m-permissions-confused-on-the-usage-of-shouldshowrequestpermissionrati
在onRequestPermissionsResult函数中进行检测，如果返回PERMISSION_DENIED，则去调用shouldShowRequestPermissionRationale函数，如果返回false代表用户已经禁止该权限（上面的3和4两种情况），弹出dialog告诉用户你需要该权限的理由，让用户手动打开。链接：http://stackoverflow.com/questions/30719047/android-m-check-runtime-permission-how-to-determine-if-the-user-checked-nev
　　处理方法已经有了，修改一下代码，我这里就以第二种方案来处理了：

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
if (requestCode == CODE_FOR_WRITE_PERMISSION){
if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE)
&&grantResults[0] == PackageManager.PERMISSION_GRANTED){
//用户同意使用write
startGetImageThread();
}else{
//用户不同意，向用户展示该权限作用
if (!ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.WRITE_EXTERNAL_STORAGE)) {
AlertDialog dialog = new AlertDialog.Builder(this)
.setMessage("该相册需要赋予访问存储的权限，不开启将无法正常工作！")
.setPositiveButton("确定", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
finish();
}
})
.setNegativeButton("取消", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
finish();
}
}).create();
dialog.show();
return;
}
finish();
}
}
}

　　当勾选不再提醒，并且拒绝之后，弹出dialog，提醒用户该权限的重要性：

　　


　　搞定！！！

使用兼容库

　　以上的代码在6.0版本上使用没有问题，但是在之前就有问题了，最简单粗暴的解决方法可能就是利用Build.VERSION.SDK_INT >= 23这个判断语句来判断了，方便的是SDK 23的v4包加入了专门类进行相关的处理：
ContextCompat.checkSelfPermission()
被授权函数返回PERMISSION_GRANTED，否则返回PERMISSION_DENIED ，在所有版本都是如此。ActivityCompat.requestPermissions()
这个方法在6.0之前版本调用，OnRequestPermissionsResultCallback 直接被调用，带着正确的 PERMISSION_GRANTED或者PERMISSION_DENIED。ActivityCompat.shouldShowRequestPermissionRationale()
在6.0之前版本调用，永远返回false。　　用v4包的这三方法，完美兼容所有版本！下面是代码：

//使用兼容库就无需判断系统版本
int hasWriteContactsPermission = ContextCompat.checkSelfPermission(getApplication(), Manifest.permission.WRITE_EXTERNAL_STORAGE);
if (hasWriteContactsPermission == PackageManager.PERMISSION_GRANTED) {
startGetImageThread();
}
//需要弹出dialog让用户手动赋予权限
else{
ActivityCompat.requestPermissions(PickOrTakeImageActivity.this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, CODE_FOR_WRITE_PERMISSION);
}

　　onRequestPermissionsResult函数不变。后两个方法，我们也可以在Fragment中使用，用v13兼容包：FragmentCompat.requestPermissions() and FragmentCompat.shouldShowRequestPermissionRationale()和activity效果一样。

一次请求多个权限

　　当然了有时候需要多个权限，可以用上面方法一次请求多个权限。当然最重要的是不要忘了为每个权限检查“不再提醒”的设置。

List<String> permissionsNeeded = new ArrayList<String>();
permissionsNeeded.add(Manifest.permission.ACCESS_FINE_LOCATION);
permissionsNeeded.add(Manifest.permission.READ_CONTACTS);
permissionsNeeded.add(Manifest.permission.WRITE_CONTACTS);
requestPermissions(permissionsNeeded.toArray(new String[permissionsList.size()]), CODE_FOR_MULTIPLE_PERMISSION);

　　最后在onRequestPermissionsResult函数中一个个处理返回结果即可。

第三方库简化代码

　　当然早就有第三方库来帮忙做这些事情了：

　　Github上的开源项目 PermissionHelper和hotchemi’s PermissionsDispatcher

APP处于运行状态下，被撤销权限

　　如果APP正在运行中，用户进入设置-应用程序页面去手动撤销该APP权限，会出现什么情况呢？哈哈，系统又会接着弹出权限请求对话框，挺好挺好：

　　


　　这样就没有问题了吧O(∩_∩)O~

　　上面的测试环境为genymotion6.0模拟器，有朋友跟我反映在6.0nexus 6p真机上会直接退出应用，所以这个应该还和测试环境有关。

结论建议

　　新运行时权限已经在棉花糖中被使用了。我们没有退路。我们现在唯一能做的就是保证app适配新权限模型。欣慰的是只有少数权限需要运行时权限模型。大多数常用的权限，例如，网络访问，属于Normal Permission 在安装时自动会授权，当然你要声明，以后无需检查。因此，只有少部分代码你需要修改。

两个建议：

　　1.严肃对待新权限模型。

　　2.如果你代码没支持新权限，不要设置targetSdkVersion 23 。尤其是当你在Studio新建工程时，不要忘了修改！

　　说一下代码修改。这是大事，如果代码结构被设计的不够好，你需要一些很蛋疼的重构。每个app都要被修正。如上所说，我们没的选择。列出所有你需要请求权限的全部情形，如果A被授权，B被拒绝，会发生什么，针对每一个情况认真处理。

引用文章

http://www.jianshu.com/p/e1ab1a179fbb

http://blog.csdn.net/yangqingqo/article/details/48371123

http://inthecheesefactory.com/blog/things-you-need-to-know-about-android-m-permission-developer-edition/en

http://developer.android.com/training/permissions/requesting.html

http://developer.android.com/guide/topics/security/permissions.html#normal-dangerous

http://developer.android.com/reference/android/support/v4/app/ActivityCompat.html

http://www.open-open.com/lib/view/open1453044042667.html