*本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布
运行时权限
Android 6.0，代号Marshmallow，自发布伊始，其主要的特征运行时权限就很受关注。因为这一特征不仅改善了用户对于应用的使用体验，还使得应用开发者在实践开发中需要做出改变。
Android中有很多权限，但并非所有的权限都是敏感权限，于是6.0系统就对权限进行了分类，一般为下述几类：
- 正常(Normal Protection)权限
- 危险(Dangerous)权限
- 特殊(Particular)权限
- 其他权限（一般很少用到）
危险权限实际上才是运行时权限主要处理的对象，这些权限可能引起隐私问题或者影响其他程序运行。Android 6.0发布这么久了，各大厂商也基本已经发布更新，很多应用也都已经适配到targetSdk23，相信大家对运行时权限都已经有所了解，这篇文章也讲得很清楚：聊一聊Android 6.0的运行时权限，这里就不多说了。
Android 6.0中，除了危险权限不再在安装后授予，还有两个特殊权限：SYSTEM_ALERT_WINDOW（设置悬浮窗，进行一些黑科技）和WRITE_SETTINGS（修改系统设置）。这里我们只关注WRITE_SETTINGS权限。
WRITE_SETTINGS
首先看下API文档是怎么说的
Note:
If the app targets API level 23 or higher, the app user must explicitly grant this permission to the app through a permission management screen.
The app requests the user's approval by sending an intent with action ACTION_MANAGE_WRITE_SETTINGS.
The app can check whether it has this authorization by calling Settings.System.canWrite().
也就是说，关于WRITE_SETTINGS权限的授权，做法是使用startActivityForResult，启动系统设置的授权界面来完成。我们来看看示例代码如何来请求WRITE_SETTINGS权限。
private static final int REQUEST_CODE_WRITE_SETTINGS = 1;
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方法检测授权结果
关于WRITE_SETTINGS权限，比较少应用会用到，一般也不建议应用申请，不然Android M也不会设立这道障碍，比危险权限的申请还要复杂。
但是，偏偏有应用要申请。不过还真是要感谢这个应用，不然我们也不会这么顺利就发现了这个BUG。
BUG现场
如下图。MM商场安装完成后启动，然后就跳到这个界面申请允许修改系统设置。这时候理论上是没有这个权限的，但是弹出来的界面却显示已经打开了允许修改系统设置这个开关；不做任何更改退出这个界面，MM商场会重复跳转到这个申请界面；这说明MM商场也检测到自己并没有被授予WRITE_SETTINGS权限。
到底有没有，我们来一看究竟。首先查看系统内已安装的三方应用：
adb shell pm list package -3
找到MM商场的包名，dump一下应用信息：
adb shell dumpsys package com.aspire.mm
如图：
可以看到：
- MM商店的targetSdk=23；
- requested permissions下面有WRITE_SETTINGS权限；
- 但是install permissions和runtime permissions下面并没有找到WRITE_SETTINGS权限。
说明MM商店应用还没有被授予此权限，那为什么申请此权限时弹出的界面显示，switch开关状态是开着的呢？很明显这是一个bug！
为了验证这个想法，我们来看看源码。
源码里面有真相
从WRITE_SETTINGS的API Reference里我们可以看到：
The app can check whether it has this authorization by calling Settings.System.canWrite().
应用是通过 Settings.System.canWrite().来判断自己是否已经被授予了该权限。我们找到源码，开启顺藤摸瓜模式：
这里会调用AppOpsManager.checkOpNoThrow获取当前的ops状态，继续跟踪下去：
最终，这里拿到的是OP_WRITE_SETTINGS的默认状态MODE_DEFAULT：
但此时应用的WRITE_SETTINGS权限也没有授予，canWrite当然返回的是false了。
这样就说明应用自身判断是否具有WRITE_SETTINGS权限的逻辑是没错的，那就是说很可能是Settings App里面可修改系统设置界面的switch开关状态是错误的，我们继续看源码。
抽丝剥茧，找到根源
之前我们已经知道，应用是通过使用Settings.ACTION_MANAGE_WRITE_SETTINGS来启动的设置界面，我们从这里入手，找到这个设置界面的代码。我们在源码全局搜索这个action：
最终指向的都是WriteSettingsDetails.java，找到switch开关初始化的地方：
这里我们注意到，调用了super的getPermissionInfo方法：
再看for循环里面的这段：
这时候传入的mPermissions到底是什么呢？看AppStateAppOpsBridge的构造函数：
前面我们知道，AppStateWriteSettingsBridge继承自AppStateAppOpsBridge：
我就纳闷了，这个类名写得清清楚楚，AppStateWriteSettingsBridge，跟CHANGE_NETWORK_STATE有半毛钱关系呀？这里很明显是个疑点。我们再看看getPermissionInfo里面的逻辑：
如果doseAnyPermissionMatch这个条件命中了，permissionState.staticPermissionGranted就设为true，然后就直接break跳出循环了！等等！如果这个应用同时申请了CHANGE_NETWORK_STATE和WRITE_SETTINGS权限，并且CHANGE_NETWORK_STATE的权限安装后就会授予，那这里的判断就出问题了，就会跳过WRITE_SETTINGS的判断，直接将permissionState.staticPermissionGranted设为true。
那么我们回到WriteSettingsDetails.java，回到switch开关初始化的地方，
boolean canWrite = mWriteSettingsState.isPermissible();
mSwitchPref.setChecked(canWrite);
跟踪到isPermissible方法：
真是巧啊，恰好MM商店同时申请了CHANGE_NETWORK_STATE和WRITE_SETTINGS权限（见图requested permissions），又恰好OP_WRITE_SETTINGS的默认状态是MODE_DEFAULT，机缘巧合之下，最终导致在WRITE_SETTINGS权限根本没有被授予的情况下，isPermissible却返回true，导致了这个BUG。
Android官方已修复
发现Android源码的BUG了，当然想要提patch给他们了（虽然Android 6.0已经发布这么久了，很可能已经修复），结果到Google Git一看，确实修复了，但是Android 7.0才经修复了这个问题。提交记录是这么说的：
Google官方的修复，验证了我们之前分析的是正确的。
