This change is an attempt at delaying the install complete callback
to the installer on a DONT_KILL install until the package indicates
that it as completed updating its classpath with the new APKs.
Bug: 80269951
Bug: 109751013
Test: manual test of dynamic delivery/instant apps
Merged-In: I689ec523522da37987cff9b1a67eaae9e5633ffb
Change-Id: I689ec523522da37987cff9b1a67eaae9e5633ffb
(cherry picked from commit abfc054c90)
The signature field is deprecated, but must still be populated. The
thought was that for APEX files [which is a new concept and thus
could use the new way to handle signatures] we could remove this
capability, but, it turns out Play relies on it.
Change-Id: I7096567082d4f798be1d3e6007122750453665ae
Fixes: 130827182
Test: Manual.
Test: Create sample app that dumped the signatures of an APEX
Test: Note that the signatures before this change were 'null' and set to something after this change
Also removed ContentCaptureClient, which is not used anymore (it probably became obsolete with the
ContentCaptureOptions optimization).
Fixes: 130585342
Test: atest CtsAutoFillServiceTestCases:android.autofillservice.cts.augmented.AugmentedLoginNotImportantForAutofillActivityTest
Test: manual verification with Dialer app
Change-Id: I041922874fac749f1f5d49793f1ad3e26cc345d6
This change makes storage a soft restricted permission. When the
permission is whitelisted for an app then hodlding it allows the
app to access the full SD card as on a P device. If howerver, the
permisison is not whitelisted for an app then holding it allows
accessing the visual/aural collections in media store while the
app would run in its own isolated storage sandbox.
This change also connects the opt in/out application attribute
to how external storage is mounted remocing temporary code. The
attribute was renamed to convey that opting in legacy mode is
not somethung that is desirable or would be available in the long
run.
White at this also fix the default state of app ops for restricted
permissions to avoid allowing ops for non requested restricted
permissions to every UID as component access could skip permission
checks by cannot skip app op checks.
bug:130327036
atest CtsPermission2TestCases
atest CtsPermissionTestCases
atest CtsAppOpsTestCases
atest atest CtsAppSecurityHostTestCases:android.appsecurity.cts.ExternalStorageHostTest
atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Change-Id: Ibb23cbb6a5c66d9c3823cc13562a1b903b391ffd
In some cases, the supplier of ContentProviderOperation is okay
if certain operations fail, and they'd like ContentProviderResult
to tell them about the failures instead of aborting the remainder
of the transaction.
Start using this for ModernMediaScanner, where we probably raced
with someone when building an UPSERT-style operation. We'll
pick up any changes to those files during the next scan.
Bug: 128494336
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ida8230ff2bbb3bab56eb83928e49e7097bfbc9fd
This change addresses API council feedback by making the
PackageInstaller#Session reference to setMultiPackage() consistent with
the implementation and the method doc.
Fixes: 124326154
Test: atest AtomicInstallTest
Change-Id: I5ef1ebb715ea33a6070ac431c18a9c661b5df00a
This change ensures we cannot commit or abandon a child session that has
been added to a parent session. It also ensures that a child session
being added to a parent has not already been added to another parent and
that it has not yet been committed or destroyed.
Fixes: 129534286
Test: atest CtsAtomicInstallTestCases:AtomicInstallTest
Change-Id: Id1b3524acb5bf546f7239ae644fb3080c0d3128b
This reverts commit c6778e5435.
Reason for revert: This CL causes Bluetooth fail to start
Bluetooth Java services cannot turn on.
Change-Id: I4a9649d61de7781d3a00074da780c3a5a1dfbd56
Fixes: 130260055
Test: compile, BluetoothInstrumentationTests
Immediately closes ApkAssets to free up some memory during package
parsing/install process.
This is used instead of implementing AutoCloseable because of
complexities with AssetManager and tracking assets opened
outside of the ApkAssets.java class.
Explained more in b/72056911.
Test: manually booted emulator; closing ApkAssets is used at
boot in PackageParser#parseApkLiteInner
Test: adb install test.apk && sleep 5 && adb uninstall test.package
&& sleep 1 && (adb shell lsof | grep "test.package") prints no
system_server references
Bug: 130182148
Change-Id: Ia471d7065e65bd39b535309de6c6da7ec35bdf12
Consolidate all knowledge about overlays to the overlay manager (except
static RROs that target "android": these are handled from native code in
order to be loaded as part of Zygote boot).
This removes the ability to overlay AndroidManifest.xml. There are some
use-cases where overlaying a manifest makes sense [e.g. changing an
app's label or icon or what components should be enabled by default] but
the opposite is also true [e.g. permissions]. Support for manifests can
be introduced again gradually with these goals in mind:
- should not happen during parsing [which represents the immutable
truth as read from disk]
- should happen during scanning [which applies mutable settings to a
parsed package]
- be limited in what can be modified
Bug: 78808368
Test: builds, boots
Change-Id: I12c16fce65b1e68876f0c9acd7e2a61405e64435
(cherry picked from commit 588784dc25)
We already have a nice collection of CATEGORY_APP_* constants that
can be used to identify classes of apps. This change expands that
list to discover file management apps, such as DocumentsUI.
Bug: 130215653
Test: none
Change-Id: I9b5016676ca1526074ba876675f14bf814ea4c09
Add unit tests for OMS internal components. These are different from the
OMS public API tests [that reside in core/tests/overlaytest].
Also, fix typo in OverlayInfo#toString.
Bug: 119443459
Test: atest FrameworksServicesTests:com.android.server.om
Change-Id: Icbee70800de5157a1804e0c96101f31c0bad2619
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
