Properly fix allowlisting restricted permissions for secondary users
on app upgrade. More context is available in the original fix ag/15166603 which is being reverted due to b/193206356. The root cause of the regression is that unlike one may assume, we do keep a per-user permission state even if an app is never installed in that user, however ag/15166603 broken that assumption because it's only initializing the permission state for the installed users. We actually never respected whether a package is installed for a user when checking or mutating a permission state, and networking has kernel code that relies on the user 0 permission state, so we have to keep the original behavior at least in S. So to properly fix the original b/191381905, we should: 1. Still limit the restorePermissionState() call in setAllowlistedRestrictedPermissionsInternal() to the user that it's operating upon, so that it's not accidentally calling restorePermissionState() before the allowlist is set. 2. Make the onPackageInstalled()/onPackageUninstalled() callbacks called only once so that we do one updatePermissions() for all users to initialize the permission state for all of them. Actually the install/uninstall request can only happen for either one user or USER_ALL, so we can keep the current callback signature and just allow USER_ALL in addition to normal users. BYPASS_INCLUSIVE_LANGUAGE_REASON=Touching space around old API names. Bug: 191381905 Bug: 193206356 Test: atest SplitPermissionTest --user-type secondary_user Test: atest CtsPermission2TestCases Test: atest CtsPermission2TestCases --user-type secondary_user Test: atest CtsPermission3TestCases Test: atest CtsPermission3TestCases --user-type secondary_user Test: atest MixedManagedProfileOwnerTest#testAlwaysOnVpn Change-Id: I6f314a65247c35f86ea4b8e8bf9f458c1332e29c
Loading
Please register or sign in to comment