导语
android碎片化相信是每一个android开发者的痛。机型适配也是难以绕过去的坎。这其中Android动态权限检测适配，相信对于很多开发者来说，都是被按在地上摩擦摩擦。本文就针对Android权限动态检测提出一种解决方案。
一、Android权限介绍
谈起Android权限机制，很多人都会想到Google在Android 6.0 提出运行时权限管理机制（Android Runtime Permission）。针对运行时权限管理机制在这里我们不做过多描述。相信对于大多数开发者而言，真正的痛点在于建立在6.0之前的权限机制的权限检测。之所以被认为是痛点，我们会在之后给大家介绍。不同于Android Runtime Permission，6.0之前的权限机制，所申请只需要在AndroidManifest.xml列举出来，这无疑给恶意软件提供了可趁之机。
二、动态权限检测
针对权限检测，我们根据权限机制的不同，划分为以下两类：
(1) targetSdkVersion >= 23
当设备处于6.0或6.0以上时采用的运行时权限机制，权限检测变得很简单，只需要调用ContextCompat::checkSelfPermission(),潇潇洒洒一行代码即可检测对应的权限是否被赋予，简直不要太简单。
(2) tagetSdkVersion <23
当设备是6.0以下系统时，使用的老的权限机制。不像大家想象的，应用所需要的权限只需要在清单文件里面列出就可以一劳永逸。如果真有这么简单，那恐怕连一点装逼的空间都没有啦。事实上，android设备提供应用权限开关，达到用户控制整个应用的权限的赋予。对于应用本身而言，应用的很多功能是建立在拥有某一或者某些权限的基础上。一旦用户收回某一功能的具体权限，对于该功能来说无疑是一种灾难。开发者建立了良好的容灾机制那么只是会使某一功能异常，影响用户体验，然而对于那些没有
建立起好的容灾处理的代码而言，严重的可能导致应用闪退。到了线上飘红的地步，领导请喝茶恐怕是跑不了。
针对建立在老的权限机制基础上的动态权限检测的方案，很多人第一时间就会想到我们是否可以像6.0以上设备一样使用ContextCompat::checkSelfPermission()。对此我们特地做了测试，然而在我们测试过程发现只有清单文件里面申明了该权限，那么不管用户是否关闭或者开启这一权限对应的开关，该方法都会返回true。这无疑宣告了该方案的根本无法满足我们的需求。为了弄明白该方法为何会出现这一情况，我们从源码入手，去验证对应的逻辑。
在图中可以看到ActivityCompat::requestPermissions()方法体里面会对当前api版本中做判断，当api<23时，会调用PackageManager.checkPermission(),为了进一步了解我们接着去看PackageManager.checkPermission()方法体内有什么逻辑。
从图上框出的文字中可以了解到判断权限是否赋予是去判断对应的package是否含有该权限，换句更容易理解的话来说就是如果该权限在清单文件中声明了，即代表该权限被赋予。由此综合前面的代码片段来看当api<23时，使用
ContextCompat::checkSelfPermission()是无法满足我们的需求。那么除了使用
ContextCompat::checkSelfPermission()还有什么办法可以满足我们的代码需求。这里我们就不得不提起我们要介绍给大家的解决方案——AppOpsManager。
三、权限检测解决方案——AppOpsManager
AppOpsManager究竟是什么呢？Google在Android开发者手册对AppPosManager的描述为
API for interacting with "application operation" tracking.
这玩意说白了就是应用程序操作管理。AppOpsManager是在api 19引入，即Android 4.3。
通过查看Android开发者手册，以及查看AppOpsManager的源码我们会发现checkOp()的多态方法，其中checkOp(String op,int uid,String packageName)主要在api>23可以使用，而checkOp(int op,int uid,String packageName)则没有这一限制。既然有了思路，那么就来介绍一下AppOpsManager针对权限控制应该主要那些东西。查看AppOpsManager的文档，你会看到这样一段文字：
This API is not generally intended for third party application developers; most features are only available to system applications.
这么一段文字扯了啥呢，其实主要表达的是AppOpsManager在设计之初并不是面向开发者。这一点其实在这个类的很多地方就体现出来了，同时也是我们需要注意的。在这个类中，有很多权限对应的常量被隐藏起来，如下图所示：
与此同时，checkOp(int op,int uid,String packageName)，这个方法本身也是hide，也就说我们无法通过AppOpsManager这个类正常调用该方法，以及访问该属性。走到这一步，然后再告诉大家，这个方法也走不通的话，我估计拍砖的肯定不少。那么处理这一问题，对于我们来说，这个时候当然少不了反射。你敢隐藏，只要你存在，我都要把你挖出来。以下为相关的代码片段：
private boolean isPermissionGranted(String permissionCode) {
try {
Object object = getSystemService(Context.APP_OPS_SERVICE);
if (object == null) {
return false;
}
Class localClass = object.getClass();
Class[] arrayOfClass = new Class[3];
arrayOfClass[0] = Integer.TYPE;
arrayOfClass[1] = Integer.TYPE;
arrayOfClass[2] = String.class;
Method method = localClass.getMethod("checkOp", arrayOfClass);
if (method == null) {
return false;
}
Object[] arrayOfObject = new Object[3];
arrayOfObject[0] = Integer.valueOf(permissionCode);
arrayOfObject[1] = Integer.valueOf(Binder.getCallingUid());
arrayOfObject[2] = getPackageName();
int m = ((Integer) method.invoke(object, arrayOfObject)).intValue();
return m == AppOpsManager.MODE_ALLOWED;
} catch (Exception e) {
e.printStackTrace();
}
return false;
}
结语
权限动态检测有多种解决方案，AppOpsManager只是其中一种维护成本相对较少的方案。其中在做权限动态检测时，看到了大家提供了很多针对某一权限的脑洞极大的方案，不得不感慨这得被虐了死去活来才能得出的经验教训。同时有部分反应AppOpsManager这一解决方案在某些机型上依旧不能适配的问题，只能表示,
最后，AppOpsManager这个类还有潜在的彩蛋，通过这个工具可以打造一些装逼利器，大家有兴趣可以去挖掘。
