This change adds a mechanism for restricting permissions (only runtime
for now), so that an app cannot hold the permission if it is not white
listed. The whitelisting can happen at install or at any later point.
There are three whitelists: system: OS managed with default grants
and role holders being on it; upgrade: only OS puts on this list
apps when upgrading from a pre to post restriction permission database
version and OS and installer on record can remove; installer: only
the installer on record can add and remove (and the system of course).
Added a permission policy service that sits on top of permissions
and app ops and is responsible to sync between permissions and app
ops when there is an interdependecy in any direction.
Added versioning to the runtime permissions database to allow operations
that need to be done once on upgrade such as adding all permissions held
by apps pre upgrade to the upgrade whitelist if the new permisison version
inctroduces a new restricted permission. The upgrade logic is in the
permission controller and we will eventually put the default grants there.
NOTE: This change is reacting to a VP feedback for how we would handle
SMS/CallLog restriction as we pivoted from role based approach to roles
for things the user would understand plus whitelist for everything else.
This would also help us roll out softly the storage permisison as there
is too much churm coming from developer feedback.
Exempt-From-Owner-Approval: trivial change due to APi adjustment
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Test: atest CtsPermissionTestCases
Test: atest CtsPermission2TestCases
Test: atest RoleManagerTestCases
bug:124769181
Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
There are a few assumptions in the rollback manager that fail in the
multi-user case that need to be fixed:
* getAllSessions only returns sessions for the specific user.
* Session callbacks are only called on sessions associated with the
registered user.
* getPackageInfo only returns info for the specific user.
Fix these issues so that rollbacks will work properly, in particular
when the initial install session is owned by a non-system user.
Bug: 129809507
Bug: 129397974
Test: On single user device: atest RollbackTest StagedRollbackTest
Test: On primary user of multi-user device: atest RollbackTest StagedRollbackTest
Test: On multi user device manually:
adb install RollbackTestAppAv1.apk
adb install --user 10 --enable-rollback RollbackTestAppAv2.apk
-- verify the install succeeded --
adb shell pm rollback-app com.android.tests.rollback.testapp.A
-- verify the rollback succeeded --
Test: On multi user device manually:
adb install RollbackTestAppAv1.apk
adb install --staged --user 10 --enable-rollback RollbackTestAppAv2.apk
adb reboot
-- verify the install succeeded --
adb shell pm rollback-app com.android.tests.rollback.testapp.A
adb reboot
-- verify the rollback succeeded --
(cherry picked from commit d81ff97866)
Merged-In: I1a7cf101b3bc3575421629c4bf0ff63418eb8731
Change-Id: I1a7cf101b3bc3575421629c4bf0ff63418eb8731
This CL adds a SessionInfo.getUpdateMillis() call to the API in order
for callers to figure out which session was applied last.
Change-Id: I3eed6c80f4777ee248671d17d9428eed2fe73aa8
Fix: 129546185
Test: atest CtsStagedInstallHostTestCases; atest apex_e2e_tests
OverlayInfo#getTargetPackageName will never return null. Correct
@Nullable annotation to say @NonNull instead.
Fixes: 129853770
Test: builds, boots
Change-Id: I70a9634e4f7da99be5d9044a7884b9ad01a22fd8
Otherwise the underlying provide may mutate the ContentValues
before we log them, meaning we no longer have useful debugging data.
Bug: 129487770
Test: none
Change-Id: Iba3e90bdf0e51681bbe6b7f1cfd992230aee559c
The overlay manager service handles package upgrades and downgrades the
same way: all it cares about is a difference in versions, not if the new
version has a higher or lower value. In both cases, the same family of
methods are called: onPackageUpgrading and onPackageUpgraded.
Rename onPackageUpgrading and onPackageUpgraded to onPackageReplacing
and onPackageReplaced to better highlight that both upgrades and
downgrades are supported.
Test: atest OverlayDeviceTests OverlayHostTests
Change-Id: I04c5c550f504114c22bb30d35c9f2809194d2543
For service and provider bindings from TOP and
FOREGROUND_SERVICE apps, don't elevate bound apps
to above BOUND_FOREGROUND_SERVICE.
For service bindings, it is possible to explicitly
request the binding to match the foreground app
such that the bound app can get similar privileges
of foreground permissions.
For instance, when a foreground service has a location
type, providers it binds to don't automatically get the
location privilege. On the other hand, sometimes apps
showing UI want to treat their dependencies also as if
they are showing UI.
This change does not affect the oom_adj calculation,
only the proc state calculation for bound processes.
New BIND_INCLUDE_CAPABILITIES flag can be used to restore old
behavior for bound services.
Introduces a new state PROCESS_STATE_BOUND_TOP
Bug: 128337543
Test: atest CtsAppTestCases:ActivityManagerProcessStateTest
Change-Id: I13733e7f43a78903299254bc110cd8f7a8db4c40
- Also remove typed media permissions
- Leave typed media app-ops
Bug: 129716569
Test: Used apps, looked at permissions in the UI
Change-Id: If7714fb1a6955584157e1a60ab72b09e35287827
Addresses API council feedback to appropriately annotate
SessionInfo.getChildSessionIds.
Test: None
Bug: 126699287
Change-Id: Iaebc4f2db07b359cef0aff863e517c221259b47c
"meta-data" in AndroidManifest was not getting parsed by the existing logic.
Bug: 129091257
Test: atest android.content.pm.PackageParserTest
Change-Id: I3d1c38ba3b2a0ccef6a0d7d0ee5ab857b62a7b82
Along with tests to verify that they're all delegated as expected.
Bug: 129564663
Test: atest cts/tests/tests/content/src/android/content/cts/ContentResolverTest.java
Test: atest cts/tests/tests/content/src/android/content/cts/ContentResolverWrapTest.java
Change-Id: I07dcabb78174ed2bb63061394bf737df71f49bb0
A major goal of the Q release is to promote user transparency around
permission usage, and to also give user controls over those
permissions. To further this goal, all apps requesting the
internal WRITE_MEDIA_STORAGE permission must also request (and be
granted) the "Storage" runtime permission in order to gain the
associated access.
If the user revokes the "Storage" runtime permission, then the app
must lose all access granted to it via WRITE_MEDIA_STORAGE.
Bug: 129144016
Test: atest android.permission.cts.ProviderPermissionTest#testWriteMediaStorage
Change-Id: I7e747de0107cf9364a0ff2401686906340d31995
* changes:
Revert ContextImpl LoadedApk packageInfo caching workaround
Fix AssetManager2 isUpToDate check
Diff resource dirs when checking LoadedApk packageInfo cache in ActivityThread
Diff overlays between PackageManagerService and OverlayManagerService
Propagate base code path and split dir changes to Resources objects
This logic was lost in the AssetManager1 -> 2 migration.
The old AM1 checked the last modification time of the file
and compared it to a previously stored value. This re-adds the
logic to ApkAssets and fixes the checks in the JNI/Java layer.
Unfortunately I couldn't find a failing/practical case where
this check mattered. It only came up when diagnosing an issue
which ended up being unrelated.
Test: manually ran with other overlay changes
Change-Id: I758e4af1d32a9c03b2204a8a3a26e82b7e83feda
When uninstalling an update to a system app, PMS re-creates the
PackageSetting object, and OMS doesn't get notified of the change.
This makes OMS diff the known valid overlays with the resourceDirs
in the target's ApplicationInfo and forces a reload when they
disagree.
Bug: 124363683
Test: manual ran Wellbeing reproduction steps in bug
Change-Id: Ib080d8593d12596ae8f8a729cc9740462c4b9b69
We're iterating on the design to let apps request via a manifest
flag if they'd like to opt-in or opt-out of storage sandboxing. The
default is to assume that P apps don't allow sandboxing, and that
Q apps do allow sandboxing.
Bug: 129487770
Test: manual
Change-Id: I8fddb35eed412c78622be4ccae57c7b7d2aa1286
PackageInstallerSession:
* Add multipackage consistency check to sealAndValidateLocked. The check
asserts all child sessions match parent session in respect to:
* Staged parameter
* Rollback enabled parameter
* Remove the staged conistency check from addChildSessionId
* Remove sealAndValidateLocked from constructor because it was used only
when sessions where loaded (from XML file) and there's no guarantee that
child sessions will be loaded before parent. Instead, mark the session
as ShouldBeSealed.
PackageInstallerService:
* To make sure relevant sessions are sealed and validated after they are
loaded from an XML file, iterate through the loaded seasions and seal and
validate those marked as ShouldBeSealed. Sessions that do not pass the
validation are destroyed.
Test: atest StagedRollbackTest
Test: atest CtsAtomicInstallTestCases
Test: atest PackageInstallerSessionTest
Fixes: 127765168
Fixes: 124215984
Change-Id: I8f152332cadb0f6c9063264f27668821fad1cec7
We've converged on explicit scanVolume() and scanFile() methods
which tests should be calling. These are more robust than the
previous broadcast-based events, which could hang for a long time.
Bug: 127323913
Test: atest --test-mapping packages/apps/MediaProvider
Change-Id: I4f7918c70a67bcafab69ae2a71ee8e4bdaff01eb
