- Catch a wider variety of exceptions from the package parse
stage. Ignore and delete the cache entry if we catch *any*
exceptions from deserializing the parse result.
- Rename the system property pm.boot and not ro.boot, since the
former needs less effort to change back and forth.
- Finally, add a heuristic to wipe caches on non-numbered
userdebug builds when changes to the system partition are detected.
Also re-enable the cache by reverting commit
20274d15d8.
Test: Manual
Change-Id: I7b5b71ac60d8c438398c354be50b207e80550148
This CL allows a reason to be specified when installing a package. The
install reason is a sticky piece of metadata: When a package is e.g.
installed via enterprise policy and an update is then manually
installed or sideloaded, the install reason will remain "policy."
The install reason is tracked separately for each user.
With this CL, two install reasons exist: "policy" and "unknown." Other
install reasons will likely be supported in the future.
Bug: 32692748
Bug: 33415829
Test: Tested manually with "adb install" / "adb uninstall"
Change-Id: I0c9b9e1b8eb666bb6962564f6efd97e41703cd86
Also update docs according to parting comments on ag/1726256.
Bug: 30927484
Test: Build and update api.
Change-Id: Ie0dd3ae06f6a7a20001571beec10a4d5bca63970
When an app doesn't define a category, look for a fallback category
in a hard-coded list. This change only defines a fallback for a
single package, but device-specific overlays can be used to provide
more detailed fallback lists.
The precidence order is: app manifest > installer hint > fallback
Test: builds, boots, fallback categories work
Bug: 33815939
Change-Id: I1f5ca76fb7e5743a4500c0a1230a754266f34d9e
Upcoming platform features need to cluster apps together into broad
categories to help summarize information to users. (For example,
when presenting battery, network, and disk usage.)
We are tightly limiting the set of categories to keep them easily
presentable to users when summarizing information. This feature is
not designed to be a general-purpose taxonomy, nor should it be
allowed to become one.
Older apps may not have defined a category in their manifests, so
allow the installing app to define a category on their behalf.
Test: builds, boots
Bug: 33815939
Change-Id: I785b882ee7c18072ef47d56e0fc19ad72888e1b7
Update DocumentsProvider to override
ContentProvider#query(Uri, String[], Bundle, CancellationSignal);
Added an otherwise unneeded import to pass doc check
on DocumentsProvider.
Bug: 30927484
Change-Id: I295c21f53901d567455286f22439f21d22a8a25a
Test: Build and run. Test from DocsUi.
This reverts commit 106ff7a0a1.
Test: All the unit tests (ShortcutManagerTest1*) CtsShortcutHostTestCases and CtsShortcutManagerTestCases
Change-Id: Iadce2b3785cbf728daa60c4e2ff103e516d85896
This is to prevent apps which do not support density
(so essentially pre-Doughnut) from being resized and / or
windowed in free form mode.
These apps are rendered into a smaller sized buffer and
then scaled onto the screen. Using freeform window mode with
these apps uncovered many different problems.
Bug: 33843467
Test: Pre-N as well as Pre-Doughnut applications are presented
properly in free form mode. (Pre-Doughnut cannot be windowed /
resized, many M apps can).
Change-Id: I3c0eb3681486dc85ace15955432d79200743bce3
This API is designed to provide both UID-level stats and overall
summary data for a given storage device, as identified by UUID.
The use of UID-level granularity might appear a bit clunky, but it
matches other usage statistics (such as network and battery), and it
allows us to implement it using an extremely fast quota kernel
feature.
A future CL will wire up the implementation to installd.
Test: builds, boots
Bug: 32206268
Change-Id: I7b51877682d0370c2402c19346f57809f0e7ac53
Fixes: 33814858
Works around a crash for apps that inject custom
TypedArrays, which is completely unsupported, but
given the ease with which the crash can be worked
just going with higher compatibility on this one.
Test: App referenced in bug launches
Change-Id: Iac9a9b4fefd08815544211ffa49b02259920381f
This makes Package Manager require APK Signature Scheme v2 signatures
for ephemeral APKs. This part of the effort to deprecate the v1
signature scheme based on JAR signing.
Test: cts-tradefed run singleCommand cts --skip-device-info --skip-preconditions --skip-connectivity-check --abi arm64-v8a --module CtsAppSecurityHostTestCases -t android.appsecurity.cts.PkgInstallSignatureVerificationTest
Bug: 33700225
Change-Id: I3b408487c07085c0a7924d3eca495bdcb344b32d
Test: Manual test and all the unit tests:
adb shell am instrument -e class com.android.server.pm.ShortcutManagerTest1 -w com.android.frameworks.servicestests
... to test9
adb shell am instrument -e class com.android.server.appwidget.AppWidgetServiceImplTest -w com.android.frameworks.servicestests
Bug 32404406
Change-Id: Icd6d4cbd25d9cdf4508da725d95d6401cc3a46a7
Also adds unit tests that assert that the cached value is equivalent
to the parsed value.
bug: 30792387
Test: PackageParserTest
Change-Id: Ibf6dfd1225243b436e3d7473170c2ccc31cfbbd7
This change allows the system to perform iterative reset
of changes to settings in order to recover from bad a
state such as a reboot loop.
To enable this we add the notion of a default value. The
default can be set by any package but if the package that
set it is a part of the system, i.e. trusted, then other
packages that are not a part of the system, i.e. untrusted,
cannot change the default. The settings setter APIs that
do not take a default effectively clear the default. Putting
a setting from a system component always makes it the
default and if the package in not trusted then value is
not made the default. The rationale is that the system is
tested and its values are safe but third-party components
are not trusted and their values are not safe.
The reset modes from the least intrusive are: untrusted
defaults - reset only settings set by untrusted components
to their defaults or clear them otherwise; untrusted clear
- clear settings set by untrusted components (or snap to
default if provided by the system); trusted defaults - reset
all settings to defaults set by the system or clear them
otherwise.
Also a package can reset to defaults changes it made to
the global and secure settings. It is also possible to
associate a setting with an optional token which can then
be used to reset settings set by this package and
associated with the token allowing parallel experiments
over disjoint settings subsets.
The default values are also useful for experiment (or
more precisely iterative tuning of devices' behavior in
production) as the stable configuration can be set to
the "graduated" safe defaults and set the values to the
experimental ones to measure impact.
Test: tests pass
Change-Id: I838955ea3bb28337f416ee244dff2fb1199b6943
Feature is already built under the hood, but it needs it's own public
StrictMode API so it can be independently enabled.
Test: builds, boots
Bug: 32447617
Change-Id: I3c0c6d62dd36aaf25f30e0ef8e0e7b40cf32c6d2
On userdebug/eng devices, the shell can run as non-shell UIDs, so
define a flag to identify broadcasts coming from the shell, and
don't yell if they're non-protected.
Test: builds, boots, root shell can send broadcasts
Bug: 32369665
Change-Id: I5f55930ee434cb8318c86aaf05eba3c59a326694
This change allows the system to perform iterative reset
of changes to settings in order to recover from bad a
state such as a reboot loop.
To enable this we add the notion of a default value. The
default can be set by any package but if the package that
set it is a part of the system, i.e. trusted, then other
packages that are not a part of the system, i.e. untrusted,
cannot change the default. The settings setter APIs that
do not take a default effectively clear the default. Putting
a setting from a system component always makes it the
default and if the package in not trusted then value is
not made the default. The rationale is that the system is
tested and its values are safe but third-party components
are not trusted and their values are not safe.
The reset modes from the least intrusive are: untrusted
defaults - reset only settings set by untrusted components
to their defaults or clear them otherwise; untrusted clear
- clear settings set by untrusted components (or snap to
default if provided by the system); trusted defaults - reset
all settings to defaults set by the system or clear them
otherwise.
Also a package can reset to defaults changes it made to
the global and secure settings. It is also possible to
associate a setting with an optional token which can then
be used to reset settings set by this package and
associated with the token allowing parallel experiments
over disjoint settings subsets.
The default values are also useful for experiment (or
more precisely iterative tuning of devices' behavior in
production) as the stable configuration can be set to
the "graduated" safe defaults and set the values to the
experimental ones to measure impact.
Test: tests pass
Change-Id: I8c23b145d4f8ee0de2f29dedaa4641ac59343d6a
