[移动开发][Android]从canDrawOverlays权限获取错误说起

从Settings.canDrawOverlays到Binder.getCallingPid

在调试程序的时候，发现一个奇怪的问题，在主线程调用Settings.canDrawOverlays判断是否有悬浮权限的结果和在另外一个service线程中调用Settings.canDrawOverlays的结果不一样，奇怪。

事出反常必有妖，我们去看看谁在作怪。

查看其定义

frameworks/base/core/java/android/provider/Settings.java

2225??? public static boolean canDrawOverlays(Context context) {

2226??????? return Settings.isCallingPackageAllowedToDrawOverlays(context, Process.myUid(),

2227??????????????? context.getOpPackageName(), false);

2228??? }

再调用

13247??? public static boolean isCallingPackageAllowedToDrawOverlays(Context context, int uid,

13248??????????? String callingPackage, boolean throwException) {

13249??????? return isCallingPackageAllowedToPerformAppOpsProtectedOperation(context, uid,

13250??????????????? callingPackage, throwException, AppOpsManager.OP_SYSTEM_ALERT_WINDOW,

13251??????????????? PM_SYSTEM_ALERT_WINDOW, false);

13252??? }

13277??? public static boolean isCallingPackageAllowedToPerformAppOpsProtectedOperation(Context context,

13278??????????? int uid, String callingPackage, boolean throwException, int appOpsOpCode, String[]

13279??????????? permissions, boolean makeNote) {

13280??????? if (callingPackage == null) {

13281??????????? return false;

13282??????? }

13283

13284??????? AppOpsManager appOpsMgr = (AppOpsManager)context.getSystemService(Context.APP_OPS_SERVICE);

13285??????? int mode = AppOpsManager.MODE_DEFAULT;

13286??????? if (makeNote) {

13287??????????? mode = appOpsMgr.noteOpNoThrow(appOpsOpCode, uid, callingPackage);

13288??????? } else {

13289??????????? mode = appOpsMgr.checkOpNoThrow(appOpsOpCode, uid, callingPackage);

13290??????? }

13291

13292??????? switch (mode) {

13293??????????? case AppOpsManager.MODE_ALLOWED:

13294??????????????? return true;

13295

13296??????????? case AppOpsManager.MODE_DEFAULT:

13297??????????????? // this is the default operating mode after an app's installation

13298??????????????? // In this case we will check all associated static permission to see

13299??????????????? // if it is granted during install time.

13300??????????????? for (String permission : permissions) {

13301??????????????????? if (context.checkCallingOrSelfPermission(permission) == PackageManager

13302??????????????????????????? .PERMISSION_GRANTED) {

13303??????????????????????? // if either of the permissions are granted, we will allow it

13304??????????????????????? return true;

13305??????????????????? }

13306??????????????? }

13307

13308??????????? default:

13309??????????????? // this is for all other cases trickled down here...

13310???? ???????????if (!throwException) {

13311?????? ?????????????return false;

13312??????????????? }

13313??????? }

添加log，发现是context.checkCallingOrSelfPermission(permission)

的结果在不同线程里不一样，

753??? public int checkCallingOrSelfPermission(String permission) {

754??????? return mBase.checkCallingOrSelfPermission(permission);

755??? }

1786??? public int checkCallingOrSelfPermission(String permission) {

1787??????? if (permission == null) {

1788??????????? throw new IllegalArgumentException("permission is null");

1789??????? }

1790

1791??????? return checkPermission(permission, Binder.getCallingPid(),

1792??????????????? Binder.getCallingUid());

1793??? }

这里可以看到，使用了Binder.getCallingPid()和Binder.getCallingUid()作为参数，在碰到的问题中，次线程是通过Binder调起的服务，所以其Binder.getCallingPid()和主线程不一样，是调用者进程的PID，就是这里的差异，导致了在同一个进程中，不同线程的调用结果不一样，

我们可以使用checkSelfPermission(“android.permission.SYSTEM_ALERT_WINDOW”)去判断权限，

或者使用Binder. clearCallingIdentity(); 把调用信息设置为当前进程后再调用Settings.canDrawOverlays方法。

回过头来看，不同线程的执行结果不一样，肯定是有线程差异在影响，我们应当对Binder的线程情况及Binder.getCallingPid有意识。对于Binder线程中权限的获取，我们都应当格外注意。

Settings.canDrawOverlays(context) 方法可以说是埋了个坑，一般不会有这个问题，如果有问题，就用上面的方法去处理。