Android M WRITE_SETTINGS权限的一个BUG

运行时权限

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权限。

MM商场申请WRITE_SETTINGS权限

到底有没有，我们来一看究竟。首先查看系统内已安装的三方应用：

adb shell pm list package -3

找到MM商场的包名，dump一下应用信息：

adb shell dumpsys package com.aspire.mm

如图：

targetSdk

requested permissions

runtime permissions

可以看到：

• 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官方的修复，验证了我们之前分析的是正确的。

来源地址:

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