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問題
僅供參考，歡迎指正
