Android权限检查API checkSelfPermission失效问题

Android权限检查API checkSelfPermission失效问题Android6.0之后,权限分为install时的权限跟运行时权限,如果我们的targetSdkVersion=23,install权限同runtime权限是分开的,app也要针对6.0已经做适配,没什么大问题,无论运行在旧版本还是6.0之后的手机上都ok,这也是Googl…

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之前,只能用来检测通知,可能还有悬浮窗。

检查权限的解决方案(除去通知权限)

public boolean selfPermissionGranted(Context context, String permission) {

	boolean ret = true;
	if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
		if (targetSdkVersion >= Build.VERSION_CODES.M) {
			ret = context.checkSelfPermission(permission) == PackageManager.PERMISSION_GRANTED;
		} else {
	      ret = PermissionChecker.checkSelfPermission(context, permission) == PermissionChecker.PERMISSION_GRANTED;
		}
         	}else{
              return true;
          }
	return ret;
}	    

或者全部采用PermissionChecker的checkSelfPermission:

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问题 仅供参考,欢迎指正

今天的文章Android权限检查API checkSelfPermission失效问题分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/23621.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注