Android Permission Management Principles (including 6.0)

Preface

Before MarshMallow, permissions were granted at the time of installation in the Android system. Although Google tried to introduce AppOpsManager into the source code in 4.3 to achieve the purpose of dynamic permission control, this function was hidden in the Release version due to its immaturity. After 6.0, in order to simplify the installation process and facilitate user control of permissions, Google officially introduced runtime-permission, allowing users to dynamically control permissions at runtime. For development, it means setting targetSdkVersion to 23, and dynamically applying for permissions at the corresponding time. When an App adapted to Android 6.0 runs on an Android 6.0+ phone, it will call the 6.0-related APIs. However, on lower-version phones, it is still processed according to the permissions at installation time.

AppOpsManager dynamic permission management: official preview of permission management

AppOpsManager is a dynamic permission management method introduced by Google in Android 4.3. However, Google thinks it is immature, so it always blocks this function in each release. This function is similar to the dynamic permission management in China. Here we use the implementation in CyanogenMod12 to explain it (the source code of the domestic ROM is not available, but from the performance point of view, the implementation should be similar). The essence of the dynamic management implemented by AppOpsManager is: put the authentication inside each service. For example, if the App wants to apply for location permission, the location service LocationManagerService will query the AppOpsService whether the App location permission is granted. If authorization is required, a system dialog box will pop up for the user to operate, and the result will be persisted in the file according to the user's operation. If the corresponding permission is set in the Setting, the corresponding permission operation persistence file /data/system/appops.xml will also be updated. The next time you apply for the service again, the service will authenticate the permission again.

For example - Location Manager Service: CM12 source code

When an app uses location services, it usually obtains location through requestLocationUpdates of LocationManager, which is actually requesting LocationManagerService for location through Binder.

/android/location/LocationManager.java

 private void requestLocationUpdates(LocationRequest request, LocationListener listener,
        Looper looper, PendingIntent intent) {
 ...
 try {
        mService.requestLocationUpdates(request, transport, intent, packageName);
 ...   

/com/android/server/LocationManagerService.java

 @Override
 public void requestLocationUpdates(LocationRequest request, ILocationListener listener,
        PendingIntent intent, String packageName) {
    if (request == null ) request = DEFAULT_LOCATION_REQUEST;
    checkPackageName(packageName);
 <! --Key function 1, query the Manifest file to see if permission has been declared -->  
 int allowedResolutionLevel = getCallerAllowedResolutionLevel();
    checkResolutionLevelIsSufficientForProviderUse(allowedResolutionLevel,
            request.getProvider());
 . . .
 <! --Get the pid and uid of the calling app-->  
    final int pid = Binder.getCallingPid();
    final int uid = Binder.getCallingUid();
    // providers may use public location API's, need to clear identity
    long identity = Binder.clearCallingIdentity();
 try {
 <! --Key function 2 checks whether permissions are dynamically granted or denied-->  
        checkLocationAccess(uid, packageName, allowedResolutionLevel); 
  
        synchronized (mLock) {
            Receiver receiver = checkListenerOrIntentLocked(listener, intent, pid, uid,
                    packageName, workSource, hideFromAppOps);
            if (receiver != null ) {
                    requestLocationUpdatesLocked(sanitizedRequest, receiver, pid,
                                                 uid, packageName);
 }
 }
 finally
        Binder.restoreCallingIdentity(identity);
 }
 }

getCallerAllowedResolutionLevel mainly calls getAllowedResolutionLevel to query whether the APP has been declared in the Manifest

 private int getCallerAllowedResolutionLevel() {
 return getAllowedResolutionLevel(Binder.getCallingPid(), Binder.getCallingUid());
 } 
 
 private int getAllowedResolutionLevel( int pid, int uid) {
     if (mContext.checkPermission(android.Manifest.permission.ACCESS_FINE_LOCATION,
             pid, uid) == PackageManager.PERMISSION_GRANTED) {
 return RESOLUTION_LEVEL_FINE;
     } else if (mContext.checkPermission(android.Manifest.permission.ACCESS_COARSE_LOCATION,
             pid, uid) == PackageManager.PERMISSION_GRANTED) {
 return RESOLUTION_LEVEL_COARSE;
 } else {
 return RESOLUTION_LEVEL_NONE;
 }
 }

checkLocationAccess is the entry point for dynamic authentication. In the checkLocationAccess function, mAppOps.checkOp is called for authentication. mAppOps is the AppOpsManager instance.

 boolean checkLocationAccess( int uid, String packageName, int allowedResolutionLevel) {
 int op = resolutionLevelToOp(allowedResolutionLevel);
 if (op >= 0) {
 int mode = mAppOps.checkOp(op, uid, packageName);
        if (mode != AppOpsManager.MODE_ALLOWED && mode != AppOpsManager.MODE_ASK ) {
 return   false ;
 }
 }
 return   true ;
 }

Then send an authentication request to the AppOpsService service through Binder

   public   int noteOp( int op, int uid, String packageName) {
 try {
 int mode = mService.noteOperation(op, uid, packageName);
        if (mode == MODE_ERRORED) {
            throw new SecurityException(buildSecurityExceptionMsg(op, uid, packageName));
 }
 return mode;
    } catch (RemoteException e) {
 }
 return MODE_IGNORED;
 }

AppOpsService is responsible for the identification and update of dynamic permissions. Next, look at the noteOperation code

 @Override
 public   int noteOperation( int code, int uid, String packageName) {
    final Result userDialogResult;
 verifyIncomingUid(uid);
 verifyIncomingOp(code);
 synchronized (this) {
        Ops ops = getOpsLocked(uid, packageName, true );
 ...
 <! --Key point 1-->  
        if (switchOp.mode == AppOpsManager.MODE_IGNORED ||
            switchOp.mode == AppOpsManager.MODE_ERRORED) { 
 
            op.rejectTime = System.currentTimeMillis();
            op.ignoredCount++;
 return switchOp.mode;
 <! --Key point 2-->  
        } else if(switchOp.mode == AppOpsManager.MODE_ALLOWED) { 
 
            op. time = System.currentTimeMillis();
            op.rejectTime = 0;
            op.allowedCount++;
 return AppOpsManager.MODE_ALLOWED;
 } else {
 op.noteOpCount++;
 <! --Key function 3-->  
            userDialogResult = askOperationLocked(code, uid, packageName,
 switchOp);
 }
 }
 return userDialogResult.get();
 }

In the above code, 1 and 2 directly return the authorization or rejection for the processed scenarios, and 3 is our common authorization entry dialog box, which is uniformly authorized in AppOpsServie. askOperationLocked will display a system dialog box. After the user chooses to authorize or reject, AppOpsServie will record the choice and notify the application service to provide or reject the service. askOperationLocked sends an authentication message through mHandler. Looking at the implementation, it actually creates a new PermissionDialog authorization dialog box and passes the reference of AppOpsService into it. After authorization, the authorization result will be notified through mService.notifyOperation.

 mHandler = new Handler() {
 public void handleMessage(Message msg) {
                switch (msg.what) {
 case SHOW_PERMISSION_DIALOG: {
                    HashMap<String, Object> data =
                        (HashMap<String, Object>) msg.obj;
                    synchronized (this) {
                        Op op = (Op) data.get( "op" );
                        Result res = (Result) data.get( "result" );
                        op.dialogResult.register(res);
                        if(op.dialogResult.mDialog == null ) {
 Integer code = ( Integer ) data.get( "code" );
 Integer uid = ( Integer ) data.get( "uid" );
                            String packageName =
                                (String) data.get( "packageName" );
                            Dialog d = new PermissionDialog(mContext,
                                AppOpsService.this, code, uid,
                                packageName);
                            op.dialogResult.mDialog = (PermissionDialog)d;
                            d.show();
 }
 }
 }break;
 }
 }
 };

Android distribution source code supports dynamic permission management (almost zero)

Between Android 4.3 and 5.1, although apps can obtain instances of AppOpsManager, the setMode interface that actually performs dynamic operation permissions is hidden, as shown below:

 /** @hide */
 public void setMode( int code, int uid, String packageName, int mode) {
 try {
        mService.setMode(code, uid, packageName, mode);
    } catch (RemoteException e) {
 }
 }

After traversing the source code, only the NotificationManagerService system application uses setMode, that is, in the release version, only notifications are dynamically managed through the system notification manager.

 public void setNotificationsEnabledForPackage(String pkg, int uid, boolean enabled) {
 checkCallerIsSystem(); 
 
    Slog.v(TAG, (enabled? "en" : "dis" ) + "abling notifications for " + pkg); 
 
    mAppOps.setMode(AppOpsManager.OP_POST_NOTIFICATION, uid, pkg,
            enabled ? AppOpsManager.MODE_ALLOWED : AppOpsManager.MODE_IGNORED); 
 
    // Now, cancel any outstanding notifications that are part of a just-disabled app
    if (ENABLE_BLOCKED_NOTIFICATIONS && !enabled) {
        cancelAllNotificationsInt(pkg, 0, 0, true , UserHandle.getUserId(uid));
 }
 }

Android 6.0 Permission Management Principle

The runtime-permission mechanism of Android 6.0 allows users to cancel authorization at any time. Therefore, every time you apply for a system service, you must dynamically query whether the corresponding permission has been obtained. If not, you need to apply dynamically. First, let's take a look at the query of permissions:

Android 6.0 Permission Query

The support-v4 compatibility package provides a tool class PermissionChecker that can be used to check permission acquisition.

PermissionChecker

 public   static   int checkPermission(@NonNull Context context, @NonNull String permission,
 int pid, int uid, String packageName) {
    if (context.checkPermission(permission, pid, uid) == PackageManager.PERMISSION_DENIED) {
 return PERMISSION_DENIED;
 } 
 
    String op = AppOpsManagerCompat.permissionToOp(permission);
 if (op == null ) {
 return PERMISSION_GRANTED;
 } 
 
    if (packageName == null ) {
        String[] packageNames = context.getPackageManager().getPackagesForUid(uid);
        if (packageNames == null || packageNames.length <= 0) {
 return PERMISSION_DENIED;
 }
        packageName = packageNames[0];
 } 
 
    if (AppOpsManagerCompat.noteProxyOp(context, op, packageName)
            != AppOpsManagerCompat.MODE_ALLOWED) {
 return PERMISSION_DENIED_APP_OP;
 } 
 
 return PERMISSION_GRANTED;
 }

Here we only care about context.checkPermission. From the above analysis of APPOpsManager from 4.3 to 5.1, we know that some operations of AppOpsManagerCompat itself have no practical significance for permission management. They are only used to make some marks. At most, they are useful for notification permissions. Next, let's look at checkPermission:

ContextImple.java

 /** @hide */
 @Override
 public   int checkPermission(String permission, int pid, int uid, IBinder callerToken) {
    if (permission == null ) {
        throw new IllegalArgumentException( "permission is null" );
 }
 try {
 return ActivityManagerNative.getDefault().checkPermissionWithToken(
                permission, pid, uid, callerToken);
    } catch (RemoteException e) {
 return PackageManager.PERMISSION_DENIED;
 }
 }

Then look down

ActivityManagerNative.java

 public   int checkPermission(String permission, int pid, int uid)
        throws RemoteException {
    Parcel data = Parcel.obtain();
    Parcel reply = Parcel.obtain();
    data.writeInterfaceToken(IActivityManager.descriptor);
    data.writeString(permission);
 data.writeInt(pid);
 data.writeInt(uid);
    mRemote.transact(CHECK_PERMISSION_TRANSACTION, data, reply, 0);
 reply.readException();
 int res = reply.readInt();
 data.recycle();
 reply.recycle();
 return res;
 }

ActivityManagerService

 public   int checkPermission(String permission, int pid, int uid) {
    if (permission == null ) {
 return PackageManager.PERMISSION_DENIED;
 }
 return checkComponentPermission(permission, pid, UserHandle.getAppId(uid), -1, true );
 }

Then call ActivityManager.checkComponentPermission, call AppGlobals.getPackageManager().checkUidPermission(permission, uid);

ActivityManager.java

 /** @hide */
 public   static   int checkComponentPermission(String permission, int uid,
 int owningUid, boolean exported) {
    // Root, system server get to do everything. 
     
 <! --root and System can obtain all permissions-->  
    if (uid == 0 || uid == Process.SYSTEM_UID) {
 return PackageManager.PERMISSION_GRANTED;
 }
 . . .
 <! --Normal permission query-->  
 try {
 return AppGlobals.getPackageManager()
                .checkUidPermission(permission, uid);
    } catch (RemoteException e) {
        // Should never happen, but if it does... deny!
        Slog.e(TAG, "PackageManager is dead?!?" , e);
 }
 return PackageManager.PERMISSION_DENIED;
 }

Finally, PackageManagerService.java is called to check whether there is permission. At this point, we only need to know that the query of permission is actually done through PKMS. We should have a basic understanding that the update, persistence, and recovery of permissions are all done through PKMS.

PKMS permission query for different versions

Android5.0 checkUidPermission

 public   int checkUidPermission(String permName, int uid) {
        final boolean enforcedDefault = isPermissionEnforcedDefault(permName);
        synchronized (mPackages) {
 <! --In the PackageManagerService.Setting.mUserIds array, find the permission list of uid (that is, package) according to uid-->  
            Object obj = mSettings.getUserIdLPr(UserHandle.getAppId(uid));
            if (obj != null ) {
                GrantedPermissions gp = (GrantedPermissions)obj;
                if (gp.grantedPermissions. contains (permName)) {
 return PackageManager.PERMISSION_GRANTED;
 }
 } else {
 <! --mSystemPermissions records the permission corresponding to the uid of some system-level applications->  
                HashSet<String> perms = mSystemPermissions.get(uid);
                if (perms != null && perms. contains (permName)) {
 return PackageManager.PERMISSION_GRANTED;
 }
 }
            if (!isPermissionEnforcedLocked(permName, enforcedDefault)) {
 return PackageManager.PERMISSION_GRANTED;
 }
 }
 return PackageManager.PERMISSION_DENIED;
 }

checkUidPermission for Android6.0+

 @Override
 public   int checkUidPermission(String permName, int uid) {
        final int userId = UserHandle.getUserId(uid); 
 
        if (!sUserManager.exists(userId)) {
 return PackageManager.PERMISSION_DENIED;
 } 
 
        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;
 }
                // Special case : ACCESS_FINE_LOCATION permission includes ACCESS_COARSE_LOCATION
                if (Manifest.permission.ACCESS_COARSE_LOCATION.equals(permName) && permissionsState
                        .hasPermission(Manifest.permission.ACCESS_FINE_LOCATION, userId)) {
 return PackageManager.PERMISSION_GRANTED;
 }
 } else {
                ArraySet<String> perms = mSystemPermissions.get(uid);
                if (perms != null ) {
                    if (perms. contains (permName)) {
 return PackageManager.PERMISSION_GRANTED;
 }
                    if (Manifest.permission.ACCESS_COARSE_LOCATION.equals(permName) && perms
                            . contains (Manifest.permission.ACCESS_FINE_LOCATION)) {
 return PackageManager.PERMISSION_GRANTED;
 }
 }
 }
 } 
 
 return PackageManager.PERMISSION_DENIED;
 }

It can be seen that after Android 6.0, the operation of permissions is PermissionsState

PermissionsState.java (android-6.0frameworksbaseservicescorejavacomandroidserverpm)

 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);
 }

It is clear from the above code that after 6.0, in addition to declaring permissions, they must also be authorized. Runtime permissions are different from install permissions. For install permissions, isGranted always returns True. There is no need to delve into how PermissionsState is stored in memory. Just remember it and we will talk about it later.

Android 6.0 dynamically applies for permissions

You can apply for permissions through ActivityCompat in the V4 package, which is compatible with different versions.

ActivityCompat.java

 public   static void requestPermissions(final @NonNull Activity activity,
            final @NonNull String[] permissions, final int requestCode) {
        if (Build.VERSION.SDK_INT >= 23) {
            ActivityCompatApi23.requestPermissions(activity, permissions, requestCode);
        } else if (activity instanceof OnRequestPermissionsResultCallback) { 
         
            Handler handler = new Handler(Looper.getMainLooper());
            handler.post(new Runnable() {
 @Override
 public void run() {
                    final int [] grantResults = new int [permissions.length]; 
 
                    PackageManager packageManager = activity.getPackageManager();
                    String packageName = activity.getPackageName(); 
 
                    final int permissionCount = permissions.length;
 for ( int i = 0; i < permissionCount; i++) {
                        grantResults[i] = packageManager.checkPermission(
                                permissions[i], packageName);
 } 
 
                    ((OnRequestPermissionsResultCallback) activity).onRequestPermissionsResult(
                            requestCode, permissions, grantResults);
 }
 });
 }
 }

As you can see, if it is below 6.0, PKMS is used to query whether permissions are applied in the Manifest, and the query result is passed to the Activity or Fragment through the onRequestPermissionsResult callback. In fact, as long as it is declared in the Manifest, it will be Granted by default. Then read on: ActivityCompatApi23 will eventually call activity.requestPermissions to request permissions.

Activity

 public final void requestPermissions(@NonNull String[] permissions, int requestCode) {
    Intent intent = getPackageManager().buildRequestPermissionsIntent(permissions);
    startActivityForResult(REQUEST_PERMISSIONS_WHO_PREFIX, intent, requestCode, null );
 }

Intent is actually obtained through PackageManager (ApplicationPackageManager implementation class)

   public Intent buildRequestPermissionsIntent(@NonNull String[] permissions) {
    if (ArrayUtils.isEmpty(permissions)) {
       throw new NullPointerException( "permission cannot be null or empty" );
 }
    Intent intent = new Intent(ACTION_REQUEST_PERMISSIONS);
    intent.putExtra(EXTRA_REQUEST_PERMISSIONS_NAMES, permissions);
    intent.setPackage(getPermissionControllerPackageName());
 return intent;
 }

Here, we first implicitly obtain the information related to the authorization Activity component (GrantPermissionsActivity), which is actually a dialog-style authorization Activity, which is an Activity in the PackageInstaller system application. The getPermissionControllerPackageName here actually obtains the corresponding package name.

ApplicationPackageManager.java (android-6.0frameworksbasecorejavaandroidapp)

 @Override
 public String getPermissionControllerPackageName() {
 synchronized (mLock) {
        if (mPermissionsControllerPackageName == null ) {
 try {
                mPermissionsControllerPackageName = mPM.getPermissionControllerPackageName();
            } catch (RemoteException e) {
                throw new RuntimeException( "Package manager has died" , e);
 }
 }
 return mPermissionsControllerPackageName;
 }
 }

Finally, get the package name through PackageManagerService

PackageManagerService.java (android-6.0frameworksbaseservicescorejavacomandroidserverpm)

 @Override
 public String getPermissionControllerPackageName() {
    synchronized (mPackages) {
 return mRequiredInstallerPackage;
 }
 }

The variable mRequiredInstallerPackage is assigned a value in the PMS constructor: For native Android 6.0, the permission management app and the installer are the same

 mRequiredInstallerPackage = getRequiredInstallerLPr();

Here you will get the relevant information of the PackageInstaller application. PackageInstaller is responsible for installing and uninstalling applications, and also contains some logic for authorization management. startActivityForResult starts the GrantPermissionsActivity in PackageInstaller, which is mainly responsible for granting permissions.

 <activity android: name = ".permission.ui.GrantPermissionsActivity"  
            android:configChanges= "orientation|keyboardHidden|screenSize"  
            android:excludeFromRecents= "true"  
            android:theme= "@style/GrantPermissions" >
 <intent-filter>
            < action android: name = "android.content.pm.action.REQUEST_PERMISSIONS" />
            <category android: name = "android.intent.category.DEFAULT" />
 </intent-filter>
 </activity>

This is an Activity with a floating window style similar to a dialog box

 <style name = "GrantPermissions" parent= "Settings" >
    <item name = "android:windowIsFloating" > true </item>
    <item name = "android:windowElevation" >@dimen/action_dialog_z</item>
    <item name = "android:windowSwipeToDismiss" > false </item>
 </style>

After that, the permission process is dynamically updated:

How to dynamically update RuntimePermission

Through the above process, we enter the GrantPermissionsActivity. In this Activity, if the permission is not obtained at the beginning, a permission application dialog box will pop up. The permission information in PKMS will be updated according to the user's operation, and the updated structure will be persisted to runtime-permissions.xml.

GrantPermissionsActivity

GrantPermissionsActivity actually uses the GroupState object to communicate with PKMS and remotely update permissions. Of course, if the permissions have been granted, there is no need to pop up the permission application dialog box again.

 public class GrantPermissionsActivity extends OverlayTouchActivity
        implements GrantPermissionsViewHandler.ResultListener { 
         
    private LinkedHashMap<String, GroupState> mRequestGrantPermissionGroups = new LinkedHashMap<>();
 .... 
     
 @Override
 public void onPermissionGrantResult(String name , boolean granted, boolean doNotAskAgain) {
        GroupState groupState = mRequestGrantPermissionGroups.get( name );
        if (groupState.mGroup != null ) {
 if (granted) { 
             
 <! --Permission update time-->  
                groupState.mGroup.grantRuntimePermissions(doNotAskAgain);
                groupState.mState = GroupState.STATE_ALLOWED;
 } else {
                groupState.mGroup.revokeRuntimePermissions(doNotAskAgain);
                groupState.mState = GroupState.STATE_DENIED;
 }
            updateGrantResults(groupState.mGroup);
 }
        if (!showNextPermissionGroupGrantRequest()) {
            setResultAndFinish();
 }
 }

Specific update process:

 public boolean grantRuntimePermissions(boolean fixedByTheUser, String[] filterPermissions) {
    final int uid = mPackageInfo.applicationInfo.uid; 
 
    // We toggle permissions only   to apps that support runtime
    // permissions, otherwise we toggle the app op corresponding
    // to the permission if the permission is granted to the app.
 for (Permission permission : mPermissions. values ​​()) {
        if (filterPermissions != null  
                && !ArrayUtils. contains (filterPermissions, permission.getName())) {
 continue ;
 }
 ...
 <! --Some key points-->   
 
            // Grant the permission if needed.
            if (!permission.isGranted()) {
                permission.setGranted( true );
                mPackageManager.grantRuntimePermission(mPackageInfo.packageName,
                        permission.getName(), mUserHandle);
 }
            // Update the permission flags.
            if (!fixedByTheUser) {
                // Now the apps can ask for the permission as the user  
                // no longer has it fixed in a denied state.
                if (permission.isUserFixed() || permission.isUserSet()) {
                    permission.setUserFixed( false );
                    permission.setUserSet( true );
                    mPackageManager.updatePermissionFlags(permission.getName(),
                            mPackageInfo.packageName,
                            PackageManager.FLAG_PERMISSION_USER_FIXED
                                    | PackageManager.FLAG_PERMISSION_USER_SET,
                            0, mUserHandle);

You can see that PackageManager is finally called to update the runtime permissions of the App, and finally enters the PackageManagerService service.

PackageManagerService

 @Override
 public void grantRuntimePermission(String packageName, String name , final int userId) {
        if (!sUserManager.exists(userId)) {
            Log.e(TAG, "No such user:" + userId);
 return ;
 } 
         
 ...some checks 
         
        mContext.enforceCallingOrSelfPermission(
                android.Manifest.permission.GRANT_RUNTIME_PERMISSIONS,
 "grantRuntimePermission" ); 
 
        enforceCrossUserPermission(Binder.getCallingUid(), userId,
 true /* requireFullPermission */, true /* checkShell */,
 "grantRuntimePermission" );
                . . . . .
 ...
            uid = UserHandle.getUid(userId, pkg.applicationInfo.uid);
            sb = (SettingBase) pkg.mExtras;
            if (sb == null ) {
                throw new IllegalArgumentException( "Unknown package: " + packageName);
 } 
 
            final PermissionsState permissionsState = sb.getPermissionsState(); 
               
 ...
 ...authorization 
             
            final int result = permissionsState.grantRuntimePermission(bp, userId);
 switch (result) {
 case PermissionsState.PERMISSION_OPERATION_FAILURE: {
 return ;
 } 
 
 case PermissionsState.PERMISSION_OPERATION_SUCCESS_GIDS_CHANGED: {
                    final int appId = UserHandle.getAppId(pkg.applicationInfo.uid);
                    mHandler.post(new Runnable() {
                        @Override
 public void run() {
                            killUid(appId, userId, KILL_APP_REASON_GIDS_CHANGED);
 }
 });
 }
 break;
 } 
 
            mOnPermissionChangeListeners.onPermissionsChanged(uid); 
             
             
 <! --Persistence-->   
             
            // Not critical if that is lost - app has to request again.
            mSettings.writeRuntimePermissionsForUserLPr(userId, false );
 }  

<!--Check whether the permission has been declared in the Manifest-->

 private static void enforceDeclaredAsUsedAndRuntimeOrDevelopmentPermission(PackageParser.Package pkg,
 BasePermission bp) {
 int   index = pkg.requestedPermissions.indexOf(bp. name );
 if ( index == -1) {
        throw new SecurityException( "Package " + pkg.packageName
                + " has not requested permission " + bp. name );
 }
    if (!bp.isRuntime() && !bp.isDevelopment()) {
        throw new SecurityException( "Permission " + bp. name  
                + " is not a changeable permission type" );
 }
 }

First, update the permission granted in memory

PermissionsState.java

 private int grantPermission(BasePermission permission, int userId) {
    if (hasPermission(permission. name , userId)) {
 return PERMISSION_OPERATION_FAILURE;
 } 
 
    final boolean hasGids = !ArrayUtils.isEmpty(permission.computeGids(userId));
    final int [] oldGids = hasGids ? computeGids(userId) : NO_GIDS; 
 
    PermissionData permissionData = ensurePermissionData(permission); 
 
    if (!permissionData. grant (userId)) {
 return PERMISSION_OPERATION_FAILURE;
 } 
 
 if (hasGids) {
        final int [] newGids = computeGids(userId);
        if (oldGids.length != newGids.length) {
 return PERMISSION_OPERATION_SUCCESS_GIDS_CHANGED;
 }
 } 
 
 return PERMISSION_OPERATION_SUCCESS;
 }

<!--Dynamically add and update memory Permison -->

 private PermissionData ensurePermissionData(BasePermission permission) {
    if (mPermissions == null ) {
        mPermissions = new ArrayMap<>();
 }
    PermissionData permissionData = mPermissions.get( permission.name );
    if (permissionData == null ) {
        permissionData = new PermissionData(permission);
        mPermissions.put( permission.name , permissionData);
 }
 return permissionData;
 }

Next, to persist the updated permissions to the file, use mSettings.writeRuntimePermissionsForUserLPr

RuntimePermission persistence

Settings.java

 public void writeRuntimePermissionsForUserLPr( int userId, boolean sync) {
 if (sync) {
        mRuntimePermissionsPersistence.writePermissionsForUserSyncLPr(userId);
 } else {
        mRuntimePermissionsPersistence.writePermissionsForUserAsyncLPr(userId);
 }
 }

The method Settings.getPackageLPw is called by the scanPackageDirtyLI method when scanning for installed applications. In it, you can see that the mUserIds in the Settings class, the value stored in mPackages, and the mPackages.pkg. mExtras in the PackageManagerService are all the same thing, which is a PackageSetting.

 private File getUserRuntimePermissionsFile( int userId) {
    // TODO: Implement a cleaner solution when adding tests.
 // This instead   of Environment.getUserSystemDirectory(userId) to support testing.
    File userDir = new File(new File(mSystemDir, "users" ), Integer .toString(userId));
 return new File(userDir, RUNTIME_PERMISSIONS_FILE_NAME);
 }

The directory data/system/0/runtime-permissions.xml stores the permissions that need to be applied for at runtime. This is only available on Android 6.0 and above.

 <pkg name = "com.snail.labaffinity" >
   <item name = "android.permission.CALL_PHONE" granted= "true" flags= "0" />
   <item name = "android.permission.CAMERA" granted= "false" flags= "1" />
 </pkg>

RuntimePermission recovery (in fact, this also includes ordinary permissions)

These persistent data will be read by PMS when the phone starts up. PKMS scans Apk and updates package information, checking whether /data/system/packages.xml exists. This file is created by writeLP() when parsing apk. It records system permissions and name, codePath, flags, ts, version, uesrid and other information of each apk. This information is mainly obtained by parsing AndroidManifest.xml of apk. After parsing apk, the update information is written to this file and saved to flash. The next time the phone is started, the relevant information is directly read from it and added to the memory-related list. This file will be updated when apk is upgraded, installed or deleted. packages.xml only includes installpermission, and runtimepermissiono is stored in runtime-permissions.xml.

 public PackageManagerService(Context context, Installer installer,
        boolean factoryTest, boolean onlyCore) {
 ....
    mSettings = new Settings(mPackages); 
     
 //Summarize and update information related to Permission 
 
  updatePermissionsLPw( null , null , true , 
 
                           regrantPermissions,regrantPermissions); 
 
 //Write the information to package.xml, package.list and package-stopped.xml files
 mSettings.writeLPr(); 
    
 ....
    mFirstBoot = !mSettings.readLPw(sUserManager.getUsers( false )); 
 
 Settings(File dataDir, Object lock) { 
 
    mRuntimePermissionsPersistence = new RuntimePermissionPersistence(mLock); 
 
 <! --Load package information-->  

Read the corresponding setting information according to SettingsFile or BackupSettingsFile to generate a PackageSetting object, which contains the permission list field protected final PermissionsState mPermissionsState;. After that, dynamic permission operations are all for this object during operation.

 boolean readLPw(@NonNull List<UserInfo> users) {
    FileInputStream str = null ;
    if (mBackupSettingsFilename.exists()) {
 try {
            str = new FileInputStream(mBackupSettingsFilename);
            mReadMessages.append( "Reading from backup settings file\n" );
 ...
        while ((type = parser. next ()) != XmlPullParser.END_DOCUMENT
                && (type != XmlPullParser.END_TAG || parser.getDepth() > outerDepth)) { 
         
            String tagName = parser.getName();
            if (tagName.equals( "package" )) { 
             
 ! --Read package information, including install permission information (for Android6.0package.xml) -->   
     
 readPackageLPw(parser);
 ... 
          
 <! --Read runtime permission information-->   
       
 for (UserInfo user : users) {
        mRuntimePermissionsPersistence.readStateForUserSyncLPr( user .id);
 }
 } 
 
 
 private void readPackageLPw(XmlPullParser parser) throws XmlPullParserException, IOException {
 String name = null ;
 ...
    (tagName.equals(TAG_PERMISSIONS)) {
            readInstallPermissionsLPr(parser,
                        packageSetting.getPermissionsState());

Then you can check permission

 @Override
 public   int checkUidPermission(String permName, int uid) {
        final int userId = UserHandle.getUserId(uid); 
 
        if (!sUserManager.exists(userId)) {
 return PackageManager.PERMISSION_DENIED;
 } 
 
        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;
 }

Where are the original permissions stored? They are not all read from the Android Manifest list, but only read once at startup. Before Android 6.0, all permissions were placed in the data/system/packages.xml file. After Android 6.0, they are divided into runtime permissions and ordinary permissions. Ordinary permissions are still placed in data/system/packages.xml, and runtime permissions are placed in data/system/users/0/runtime-permissions.xml. Permissions are updated based on whether they are dynamically applied at runtime.

What happens if you apply for normal permissions on Android 6.0?

In Android 6.0, normal permissions still follow the runtime permission model, but granted="true" means that the permission is always granted. So you can directly get the callback of successful permission application. If you check packages.xml, you will find the following information:

 <perms>
    <item name = "android.permission.INTERNET" granted= "true" flags= "0" />
    <item name = "android.permission.ACCESS_WIFI_STATE" granted= "true" flags= "0" />
 </perms>

Where are the key nodes of Android?

The key point is not to query whether the permission is granted. The permission query before Android 6.0 will not trigger the permission application and authorization. Only when the system service is requested, the system service calls AppopsManager to query whether the permission is granted. If it is not granted, it may trigger the permission application logic. This point is within each system service and is managed uniformly by the AppOpsService service. However, for the official Release version, in fact, only the system notification APP has the ability to dynamically manage permissions, and others have no operation capabilities.