Loading
Refactor and rename onPackageStateRemoved() to onPackageUninstalled().
Under what conditions to notify the permission subsystem that a package is considered uninstalled can be tricky/confusing, because there are so many different code paths and flavors for deleting a package, deleting a package can mean different things, and it's critical to get it right for permissions due to security concerns. If a package is being deleted as a upgrade step, we should not consider it an uninstallation (but a later package installation with replaced == true), and handle the <uses-permission> change later in that callback. This is also true for uninstalling an updated system package and reinstalling the factory version later, but that's a different code path. For system packages, we normally can't just completely remove their permission state upon uninstallation, because they can be marked as installed later, and permission pregrants needs to stick for them. So in this case we just clear the user modifiable permission state instead of dropping the whole state. However, we cannot assume that we should never drop the permission state for a system package, because there are package uninstallations during the package reconciliation phase of system boot that we do need to remove the permission state for invalid (e.g. missing) system packages. DELETE_KEEP_DATA as a flag for deleting a package actually means two different things when marking package as uninstalled v.s. removing package for all users. When marking a package as uninstalled, this flag only affects whether the data directory is deleted (as what is described in its javadoc), and all other states (including permission state) is always deleted because it's an uninstallation for that user. However when removing a package for all users, specifying this flag actually means keeping all package states and only remove the APK, which is also used when an external SD card is ejected (or a package is upgraded, or uninstalling an updated system package which has a lower version than its factory version due to OTA). In other words, uninstalling a package for all users with DELETE_KEEP_DATA actually keeps the package installed and all its states (including PackageSetting) intact, so it shouldn't be considred uninstalled for permission; whereas uninstalling for a subset of users with DELETE_KEEP_DATA marks the package uninstalled and removes most package state for those users except for the data directory, so it should be considered uninstalled for permission. Another subtle aspect of DELETE_KEEP_DATA is that it is always set when deleting an updated system app whose version is lower than its factory version due to OTA, but never set when the factory version is older, i.e. a downgrade, which is more often the case. In this case we are deleting most of the package states, however we do need to keep the permission state mostly intact, as to user it's only a replacement so user preference should be carried over, and the downgraded app cannot be missing pregranted permissions anyway. So the current implementation is that we need to clear the no longer requested permission states if the app has a shared user ID, or leave it as-is if it doesn't as permissions not requested won't be reported as granted. According to the discussion above, we are no longer calling the onPackageUninstalled() callback when a updated system package is being uninstalled for later installation of its factory version, because it should be considered as a package replacement instead of an uninstallation that should remove/reset its permission state. This is covered by the call to updatePermissions() inside installPackageFromSystemLIF() called by deleteSystemPackageLIF(), which is also moved a bit later to allow correct installed state to be set first. The method updatePermissions() should be later refactored into onPackageInstalled(). The call to updatePermissions() in the old onPackageStateRemoved() is actually necessary because it removes permission definitions according. On the contrary, removeAllPermissions() called in onPackageRemoved() only removes the PermissionInfo object in Permission, instead of the Permission itself, because it may be called upon SD card ejection. Bug: 158736025 Test: presubmit Change-Id: I06321ba21ee9e13a9bfbb1c990bbd50a68503b88