Android6.0之后，权限分为install时的权限跟运行时权限，如果我们的targetSdkVersion>=23，install权限同runtime权限是分开的，app也要针对6.0已经做适配，没什么大问题，无论运行在旧版本还是6.0之后的手机上都ok，这也是Google推荐的适配方案。但是如果targetSdkVersion < 23 ,在6.0之后的手机上就会遇到一些问题，因为在这种情况下默认权限是全部授予的，但是可能会被用户手动取消，而Context的checkSelfPermission权限检查接口也会失效，因为这个API接口6.0之后用的是runtime-permission的模型，而targetSdkVersion < 23 时候，app只有intalled的权限，其granted值一直是true，也可以看做是全部是授权了的，就算在设置里面取消授权也不会影响installed权限的granted，而Context的checkSelfPermission的接口却是用granted这个值作为授权与否的参考，所以如果用这个接口，那得到的一定是授权了，是不准确的，如下：targetSdkVersion < 23的时候，package信息中的权限包含app申请的全部权限,
<package name="com.snail.labaffinity" codePath="/data/app/com.snail.labaffinity-1" nativeLibraryPath="/data/app/com.snail.labaffinity-1/lib" publicFlags="944291398" privateFlags="0" ft="15f0f58e548" it="15f0f58e548" ut="15f0f58e548" version="1" userId="10084">
<perms>
<item name="android.permission.ACCESS_FINE_LOCATION" granted="true" flags="0" />
<item name="android.permission.INTERNET" granted="true" flags="0" />
<item name="android.permission.READ_EXTERNAL_STORAGE" granted="true" flags="0" />
<item name="android.permission.ACCESS_COARSE_LOCATION" granted="true" flags="0" />
<item name="android.permission.READ_PHONE_STATE" granted="true" flags="0" />
<item name="android.permission.CALL_PHONE" granted="true" flags="0" />
<item name="android.permission.CAMERA" granted="true" flags="0" />
<item name="android.permission.WRITE_EXTERNAL_STORAGE" granted="true" flags="0" />
<item name="android.permission.READ_CONTACTS" granted="true" flags="0" />
</perms>
<proper-signing-keyset identifier="18" />
</package>
这种情况下，该做法就会引发问题，先从源码看一下为什么targetSdkVersion < 23 Context 的 checkSelfPermission方法失效，之后再看下在targetSdkVersion < 23 的时候，如何判断6.0的手机是否被授权。
为什么targetSdkVersion < 23 Context 的 checkSelfPermission失效
跟踪一下源码发现Context 的 checkSelfPermission最终会调用ContextImp的checkPermission，最终调用
@Override
public int checkPermission(String permission, int pid, int uid) {
if (permission == null) {
throw new IllegalArgumentException("permission is null");
}
try {
return ActivityManagerNative.getDefault().checkPermission(
permission, pid, uid);
} catch (RemoteException e) {
return PackageManager.PERMISSION_DENIED;
}
}
最终请求ActivityManagerService的checkPermission，经过预处理跟中转最后会调用PackageManagerService的checkUidPermission
@Override
public int checkUidPermission(String permName, int uid) {
final int userId = UserHandle.getUserId(uid);
synchronized (mPackages) {
<!--查询权限-->
Object obj = mSettings.getUserIdLPr(UserHandle.getAppId(uid));
if (obj != null) {
final SettingBase ps = (SettingBase) obj;
final PermissionsState permissionsState = ps.getPermissionsState();
<!--检验授权-->
if (permissionsState.hasPermission(permName, userId)) {
return PackageManager.PERMISSION_GRANTED;
}
if (Manifest.permission.ACCESS_COARSE_LOCATION.equals(permName) && permissionsState
.hasPermission(Manifest.permission.ACCESS_FINE_LOCATION, userId)) {
return PackageManager.PERMISSION_GRANTED;
}
} ... }
return PackageManager.PERMISSION_DENIED;
}
PackageManagerService会从mSettings全局变量中获取权限，然后进一步验证权限是否被授予
public boolean hasPermission(String name, int userId) {
enforceValidUserId(userId);
if (mPermissions == null) {
return false;
}
PermissionData permissionData = mPermissions.get(name);
return permissionData != null && permissionData.isGranted(userId);
}
这里的检查点只有两点，第一个是是否有这个权限，第二是是否是Granted，对于targetSdkVersion<23的所有的权限都在packages.xml中，grante一直是true，无法被跟新，为什么无法被更新呢？看一下6.0之后的授权与取消授权的函数，首先看一个变量mAppSupportsRuntimePermissions
mAppSupportsRuntimePermissions = packageInfo.applicationInfo
.targetSdkVersion > Build.VERSION_CODES.LOLLIPOP_MR1;
mAppOps = context.getSystemService(AppOpsManager.class);
mAppSupportsRuntimePermissions定义在AppPermissionGroup中，6.0之后权限都是分组的，对于targetSdkVersion<23的APP来说，很明显是不支持动态权限管理的，那么授权跟取消授权函数就很不一样如下： 授权函数
public boolean grantRuntimePermissions(boolean fixedByTheUser, String[] filterPermissions) {
final int uid = mPackageInfo.applicationInfo.uid;
for (Permission permission : mPermissions.values()) {
if (filterPermissions != null
&& !ArrayUtils.contains(filterPermissions, permission.getName())) {
continue;
}
<!--关键点1 如果支持，也即是targetSdkVersion>23那走6.0动态权限管理那一套-->
if (mAppSupportsRuntimePermissions) {
// Do not touch permissions fixed by the system.
if (permission.isSystemFixed()) {
return false;
}
// Ensure the permission app op enabled before the permission grant.
if (permission.hasAppOp() && !permission.isAppOpAllowed()) {
permission.setAppOpAllowed(true);
mAppOps.setUidMode(permission.getAppOp(), uid, AppOpsManager.MODE_ALLOWED);
}
// Grant the permission if needed.
if (!permission.isGranted()) {
permission.setGranted(true);
<!--关键点2更新其runtime-permission.xml 中granted值-->
mPackageManager.grantRuntimePermission(mPackageInfo.packageName,
permission.getName(), mUserHandle);
}
...
} else {
if (!permission.isGranted()) {
continue;
}
int killUid = -1;
int mask = 0;
if (permission.hasAppOp()) {
if (!permission.isAppOpAllowed()) {
permission.setAppOpAllowed(true);
<!--关键点3 设置为AppOpsManager.MODE_ALLOWED-->
mAppOps.setUidMode(permission.getAppOp(), uid, AppOpsManager.MODE_ALLOWED);
killUid = uid;
}
}
<!--关键点4 更新其PermissionFlags-->
if (mask != 0) {
mPackageManager.updatePermissionFlags(permission.getName(),
mPackageInfo.packageName, mask, 0, mUserHandle);
}
}
}
return true;
}
可以看出6.0之后的手机，针对targetSdkVersion是否高于23做了不同处理，如果targetSdkVersion>=23支持动态权限管理，那就更新动态权限，并将其持久化到runtime-permission.xml中，并更新其granted值，如果targetSdkVersion<23 ,也即是不知道6.0的动态管理，那就只更新AppOps，这是4.3引入的老的动态权限管理模型，不过这里主要是将权限持久化到appops.xml中，不过对于其granted的值是没有做任何更新的，仅仅是更新了packages.xml中的flag，这个flag可以配合appops.xml标识是否被授权（对于targetSdkVersion<23的适用），以上就是为什么context checkSelfPermission会失效的原因，涉及代码很多，不一一列举，对于取消授权revokeRuntimePermissions函数，模型一样，不在赘述，那下面看第二个问题，如何检查targetSdkVersion<23 app 在6.0以上手机的权限呢？ Google给了一个兼容类PermissionChecker，这个类可以间接使用AppOpsService那一套逻辑，获取到权限是否被授予。
targetSdkVersion < 23 的时候，如何判断6.0的手机是否被授权
targetSdkVersion < 23的时候，6.0权限检查API失效了，不过通过上面的分析指导，在设置中权限的操作仍然会被存储内存及持久化到appops.xml文件中，这里就是走的AppOpsService那一套，AppOpsService可以看做6.0为了兼容老APP而保留的一个附加的权限管理模型，在6.0之后的系统中，可以看做runtime权限管理的补充，其实AppOpsService这套在4.3就推出了，不过不太灵活，基本没啥作用，之前只用到了通知管理。看一下Google提供的一个兼容类PermissionChecker如何做的:
public static int checkPermission(@NonNull Context context, @NonNull String permission,
int pid, int uid, String packageName) {
<!--对于targetSdkVersion < 23 一定是true-->
if (context.checkPermission(permission, pid, uid) == PackageManager.PERMISSION_DENIED) {
return PERMISSION_DENIED;
}
String op = AppOpsManagerCompat.permissionToOp(permission);
<!--看看这个权限是不是能够操作，动态授权与取消授权 如果不能，说明权限一直有-->
if (op == null) {
return PERMISSION_GRANTED;
}
<!--如果能够取消授权，就看现在是不是处于权限被允许的状态，如果不是，那就是用户主动关闭了权限-->
if (AppOpsManagerCompat.noteProxyOp(context, op, packageName)
!= AppOpsManagerCompat.MODE_ALLOWED) {
return PERMISSION_DENIED_APP_OP;
}
return PERMISSION_GRANTED;
}
对于6.0之后的手机AppOpsManagerCompat.noteProxyOp会调用AppOpsManager23的noteProxyOp，
private static class AppOpsManagerImpl {
public String permissionToOp(String permission) {
return null;
}
public int noteOp(Context context, String op, int uid, String packageName) {
return MODE_IGNORED;
}
public int noteProxyOp(Context context, String op, String proxiedPackageName) {
return MODE_IGNORED;
}
}
private static class AppOpsManager23 extends AppOpsManagerImpl {
@Override
public String permissionToOp(String permission) {
return AppOpsManagerCompat23.permissionToOp(permission);
}
@Override
public int noteOp(Context context, String op, int uid, String packageName) {
return AppOpsManagerCompat23.noteOp(context, op, uid, packageName);
}
@Override
public int noteProxyOp(Context context, String op, String proxiedPackageName) {
return AppOpsManagerCompat23.noteProxyOp(context, op, proxiedPackageName);
}
}
上面的是6.0之前对应的API，下面的是6.0及其之后对应的接口，AppOpsManagerCompat23.noteProxyOp会进一步调用AppOpsManager的noteProxyOp向AppOpsService发送请求
public static int noteProxyOp(Context context, String op, String proxiedPackageName) {
AppOpsManager appOpsManager = context.getSystemService(AppOpsManager.class);
return appOpsManager.noteProxyOp(op, proxiedPackageName);
}
最后看一下AppOpsService如何检查权限
private int noteOperationUnchecked(int code, int uid, String packageName,
int proxyUid, String proxyPackageName) {
synchronized (this) {
Ops ops = getOpsLocked(uid, packageName, true);
Op op = getOpLocked(ops, code, true);
if (isOpRestricted(uid, code, packageName)) {
return AppOpsManager.MODE_IGNORED;
}
op.duration = 0;
final int switchCode = AppOpsManager.opToSwitch(code);
UidState uidState = ops.uidState;
if (uidState.opModes != null) {
final int uidMode = uidState.opModes.get(switchCode);
op.rejectTime = System.currentTimeMillis();
return uidMode;
}
}
final Op switchOp = switchCode != code ? getOpLocked(ops, switchCode, true) : op;
if (switchOp.mode != AppOpsManager.MODE_ALLOWED) {
op.rejectTime = System.currentTimeMillis();
return switchOp.mode;
}
op.time = System.currentTimeMillis();
op.rejectTime = 0;
op.proxyUid = proxyUid;
op.proxyPackageName = proxyPackageName;
return AppOpsManager.MODE_ALLOWED;
}
}
UidState可以看做每个应用对应的权限模型，这里的数据是有一部分是从appops.xml恢复回来，也有部分是在更新权限时候加进去的，这部分变化最终都要持久化到appops.xml中去，不过持久化比较滞后，一般要等到手机更新权限后30分钟才会持久化到appops.xml中，这里的数据一般是在启动的时候被恢复重建，在启动ActivityManagerService服务的时候，会在其构造函数总启动AppOpsService服务:
public ActivityManagerService(Context systemContext) {
...
mAppOpsService = new AppOpsService(new File(systemDir, "appops.xml"), mHandler);
...}
在AppOpsService的构造函数中会将持久化到appops.xml中的权限信息恢复出来，并存到内存中去，
public AppOpsService(File storagePath, Handler handler) {
mFile = new AtomicFile(storagePath);
mHandler = handler;
// 新建的时候就会读取
readState();
}
readState就是将持久化的UidState数据给重新读取出来，如下mFile其实就是appops.xml的文件对象
void readState() {
synchronized (mFile) {
synchronized (this) {
FileInputStream stream;
try {
stream = mFile.openRead();
} catch (FileNotFoundException e) {
}
boolean success = false;
mUidStates.clear();
try {
XmlPullParser parser = Xml.newPullParser();
parser.setInput(stream, StandardCharsets.UTF_8.name());
int type;
int outerDepth = parser.getDepth();
while ((type = parser.next()) != XmlPullParser.END_DOCUMENT
&& (type != XmlPullParser.END_TAG || parser.getDepth() > outerDepth)) {
if (type == XmlPullParser.END_TAG || type == XmlPullParser.TEXT) {
continue;
}
String tagName = parser.getName();
if (tagName.equals("pkg")) {
readPackage(parser);
} else if (tagName.equals("uid")) {
readUidOps(parser);
} else {
XmlUtils.skipCurrentTag(parser);
}
}
success = true;
...}
读取之后，当用户操作权限的时候，也会随机的更新这里的标记，只看下targetSdkVersion<23的，
public boolean grantRuntimePermissions(boolean fixedByTheUser, String[] filterPermissions) {
final int uid = mPackageInfo.applicationInfo.uid;
for (Permission permission : mPermissions.values()) {
if (filterPermissions != null
&& !ArrayUtils.contains(filterPermissions, permission.getName())) {
continue;
}
<!--关键点1 如果支持，也即是targetSdkVersion>23那走6.0动态权限管理那一套-->
if (mAppSupportsRuntimePermissions) {
...
} else {
if (!permission.isGranted()) {
continue;
}
int killUid = -1;
int mask = 0;
if (permission.hasAppOp()) {
if (!permission.isAppOpAllowed()) {
permission.setAppOpAllowed(true);
<!--关键点3 设置为AppOpsManager.MODE_ALLOWED-->
mAppOps.setUidMode(permission.getAppOp(), uid, AppOpsManager.MODE_ALLOWED);
killUid = uid;
}
}
if (mask != 0) {
mPackageManager.updatePermissionFlags(permission.getName(),
mPackageInfo.packageName, mask, 0, mUserHandle);
}
}
}
return true;
}
拿授权的场景来说，其实关键就是 mAppOps.setUidMode(permission.getAppOp(), uid, AppOpsManager.MODE_ALLOWED)函数，这个函数会更新AppOpsService中对于权限的标记，并将权限是否授予的信息持久化到appops.xml及packages.xml，不同版本可能有差别，有可能需要appops.xml跟packages.xml配合才能确定是否授予权限，具体没深究，有兴趣可以自行分析。
@Override
public void setUidMode(int code, int uid, int mode) {
if (Binder.getCallingPid() != Process.myPid()) {
mContext.enforcePermission(android.Manifest.permission.UPDATE_APP_OPS_STATS,
Binder.getCallingPid(), Binder.getCallingUid(), null);
}
verifyIncomingOp(code);
code = AppOpsManager.opToSwitch(code);
synchronized (this) {
final int defaultMode = AppOpsManager.opToDefaultMode(code);
<!--更新操作权限-->
UidState uidState = getUidStateLocked(uid, false);
if (uidState == null) {
if (mode == defaultMode) {
return;
}
uidState = new UidState(uid);
uidState.opModes = new SparseIntArray();
uidState.opModes.put(code, mode);
mUidStates.put(uid, uidState);
scheduleWriteLocked();
} else if (uidState.opModes == null) {
if (mode != defaultMode) {
uidState.opModes = new SparseIntArray();
uidState.opModes.put(code, mode);
scheduleWriteLocked();
}
} else {
if (uidState.opModes.get(code) == mode) {
return;
}
if (mode == defaultMode) {
uidState.opModes.delete(code);
if (uidState.opModes.size() <= 0) {
uidState.opModes = null;
}
} else {
uidState.opModes.put(code, mode);
}
<!--持久化到appops.xml-->
scheduleWriteLocked();
}
}
...
}
这里有一点注意：scheduleWriteLocked并不是立即执行写操作，而是比更新内存滞后，一般滞后30分钟
static final long WRITE_DELAY = DEBUG ? 1000 : 30*60*1000;
30分钟才会去更新 ，不过内存中都是最新的 ，如果直接删除appops.xml，然后意外重启，比如adb reboot bootloader，那么你的所有AppOpsService权限标记将会被清空，经过验证，是符合预期的，也就说，targetSdkVersion<23的情况下，Android6.0以上的手机，它的权限操作是持久化在appops.xml中的，一般关机的时候，会持久化一次，如果还没来得及持久化，异常关机，就会丢失，这点同runtime-permission类似，异常关机也会丢失，不信可以试验一下 。
在targetSdkVersion>=23的时候，对于 SDK>=23的机器如何检测权限
targetSdkVersion>=23系统已经提供了比较合理的检测手段，PermisionChecker的checkPermission就可以，不过，这里需要注意的是，AppOpsService对于targetSdkVersion>=23的时候就不能用了，这里可能是Android的一个bug，当targetSdkVersion>=23而SDK_Version>=23的，对于AppOpsService，权限的授予跟撤销不是配对的，如下，先简单看下授权：
public boolean grantRuntimePermissions(boolean fixedByTheUser, String[] filterPermissions) {
final int uid = mPackageInfo.applicationInfo.uid;
for (Permission permission : mPermissions.values()) {
if (mAppSupportsRuntimePermissions) {
<!--关键点1 同时更新runtim-permission及Appops-->
if (permission.hasAppOp() && !permission.isAppOpAllowed()) {
permission.setAppOpAllowed(true);
mAppOps.setUidMode(permission.getAppOp(), uid, AppOpsManager.MODE_ALLOWED);
}
if (!permission.isGranted()) {
permission.setGranted(true);
mPackageManager.grantRuntimePermission(mPackageInfo.packageName,
permission.getName(), mUserHandle);
}
} else {
if (!permission.isGranted()) {
continue;
}
int killUid = -1;
int mask = 0;
<!--关键点2 更新Appops-->
if (permission.hasAppOp()) {
if (!permission.isAppOpAllowed()) {
permission.setAppOpAllowed(true);
// Enable the app op.
mAppOps.setUidMode(permission.getAppOp(), uid, AppOpsManager.MODE_ALLOWED);
killUid = uid;
}
...
}
}
return true;
}
可见，对于6.0的系统，无论targetSdkVersion是否>=23，在授权的时候，都会更新appops.xml，那取消授权呢？
public boolean revokeRuntimePermissions(boolean fixedByTheUser, String[] filterPermissions) {
final int uid = mPackageInfo.applicationInfo.uid;
for (Permission permission : mPermissions.values()) {
...
if (mAppSupportsRuntimePermissions) {
if (permission.isSystemFixed()) {
return false;
}
// Revoke the permission if needed.
if (permission.isGranted()) {
permission.setGranted(false);
mPackageManager.revokeRuntimePermission(mPackageInfo.packageName,
permission.getName(), mUserHandle);
}
<!--关键点1 这里没有使用mAppOps.setUidMode更新appops.xml文件->
} else {
// Legacy apps cannot have a non-granted permission but just in case.
if (!permission.isGranted()) {
continue;
}
int mask = 0;
int flags = 0;
int killUid = -1;
if (permission.hasAppOp()) {
if (permission.isAppOpAllowed()) {
<!--关键点2 这里使用mAppOps.setUidMode更新appops.xml文件->
mAppOps.setUidMode(permission.getAppOp(), uid, AppOpsManager.MODE_IGNORED);
killUid = uid;
}
...
}
}
return true;
}
看关键点1 ，如果targetSdkVersion>=23在取消授权的时候，是不会更新appops.xml的，只有在targetSdkVersion<23的时候，才会向关键点2，撤销授权。也就是说对于targetSdkVersion>=23的时候，不要用AppOpsManager了。
对于6.0以下的手机权限如何检测
对于Android6.0以下的手机，不需要关心targetVersion。先说个自己验证的结果：基本没法检测，同时也不需要检测，就算检测出来也没有多大意义，因为，触发时机是在真正的调用服务时候。对于4.3到6.0之前的国产ROM，虽然采用AppopsManagerService，但是并未按照Google的模型对所有权限进行适配，在这个模型下，也就适配了两个权限，
- 通知权限 public static final int OP_POST_NOTIFICATION = 11;
- 悬浮窗权限 public static final int OP_SYSTEM_ALERT_WINDOW = 24;
Google发行版的APPOpsService，基本是把整个鉴权逻辑给屏蔽了，通过CM的源码，课对这部分代码窥探一斑，如果整个权限都采用4.3权限管理模型，在拒绝一项权限的时候，这个操作会被持久化到appops.xml中去，但是具体看下去，其实并不是如此，这种机制只对以上两个权限生效：
<pkg n="com.xxx">
<uid n="10988">
<!--关键点1-->
<op n="11" m="1" t="1513145979969" r="1521550658067" />
<op n="12" t="1521550651593" />
<op n="29" t="1521550682769" />
<pkg n="com.wandoujia.phoenix2.usbproxy">
<uid n="10969">
<op n="4" t="1517279031173" />
<!--关键点2-->
<op n="11" m="1" t="1510889291834" r="1517279030708" />
<op n="14" t="1517293452801" />
<!--关键点3-->
<op n="24" m="1" />
<op n="40" t="1513599239364" d="600011" />
国产rom中，假如你拒绝授权位置权限，按照AppOpsService模型，该操作应该被持久化到appops.xml中去，但是，结果并非如此，也就是说，对于其他权限，国产ROM应该是自己糊弄了一套持久管理，持久化Android系统API无法访问的地方，仅仅为自身ROM可见。appops.xml真正被系统使用时从Android6.0开始，其实Android6.0是有两套权限管理的，这其实很混乱，不知道Google怎么想的，不过6.0似乎也有漏洞：权限的授予跟回收权限好像并不配对。
那么这就带来了一个问题，在Android4.3到Android6.0之间的版本，并没有同一个API来检测是否获取了某种权限，因为你动态更新的权限并未持久化到appops.xml中去。对于Android6.0之前的ROM，虽然不能检测，但完全可以直接用服务，不会崩溃，因为如果真需要鉴权，它的鉴权时机其实是在服务使用的时候。AppopsManager在6.0之前，只能用来检测通知，可能还有悬浮窗。
检查权限的解决方案（除去通知权限）
全部采用PermissionChecker的checkSelfPermission：（不要提高compileSdkVersion）
public boolean selfPermissionGranted(Context context, String permission) {
return PermissionChecker.checkSelfPermission(context, permission) == PermissionChecker.PERMISSION_GRANTED;
}
总结
Android6.0系统其实支持两种动态管理，runtime-permission及被阉割的AppOpsService，当targetSdkVersion>23的时候，采用rumtime-permission，当 targetSdkVersion<23的时候，两者兼有，其实targetSdkVersion<23的时候，仍然可以动态申请6.0的权限，前提是你要采用23之后的compileSdkVersion，只有这样才能用相应的API，不过还是推荐升级targetSdkVersion，这才是正道。对于Android6.0以下的手机，除了通知（可能还有悬浮窗），其他权限基本都没有系统的检测手段，无论Context的checkPermission还是AppopsManager的checkOp，基本都是对Android6.0之后才有效。
作者：看书的小蜗牛
原文链接:Android权限检查API checkSelfPermission问题
仅供参考，欢迎指正
