Without it, apps (mainline modules) will need to use createPackageContext...,
which is a bit painful.
Bug: 142472686
Test: atest android.content.cts.ContextTest#testCreateContextAsUser
Change-Id: Id640e03862462724df1a4a3101f0b08faafba22f
The one messy internal caller is the settings provider, so a new @hide
API on PackageManager was introduced to decouple the provider from
LocalServices. That new entry point is only callable by uid 1000,
paralleling the previous system-caller-only availability.
Bug: 140833849
Test: system boots & runs normally
Change-Id: I93ae38b8f55db7864893a97795aea63014bf5e12
Define a new change id and use it for gating the change.
Test: atest -p cts/tests/signature, atest AndroidTestBaseUpdaterTest
Bug: 30188076
Change-Id: Ic8c85eae0c490a7eca117b74c4326dd50df2b352
We've heard that some developers want more detailed influence over
the sort order applied internally inside of a ContentProvider. For
example, when the locale is "zh", the caller may want to sort using
either "pinyin" or "zhuyin" style collations.
Thankfully ICU already supports this type of collation control when
creating a ULocale object, and it also supports other useful types
such as "de@collation=phonebook". Thus this CL adds a new
QUERY_ARG_SORT_LOCALE that can be used to pass an ICU locale string
into a ContentProvider.
Similar to the other existing query arguments, we know that only
certain providers may support this new option, so we document that
it should be included in EXTRA_HONORED_ARGS when applied.
Bug: 140248907
Test: atest cts/tests/tests/content/src/android/content/cts/ContentResolverTest.java
Change-Id: I3277725ecd21a58680f2b8a5cc62514184d9e179
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
bug:141028068
Exempt-From-Owner-Approval: merge
Change-Id: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
- New class AccessibilityShortcutInfo to describe accessibility
shortcut.
- New Intent category for the target of accessibility shortcut
Bug: 136293963
Test: atest AccessibilityShortcutInfoTest
Change-Id: Id47d397a03f3f710368550e551097214c7839943
ag/9372503 put the order of reading preCreated from a UserInfo parcel
in the wrong spot. We fix it here.
Test: none
Change-Id: I4502e901ff2aac977c584fa8c5a3d1263be33572
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
bug:141028068
Merged-In: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
Change-Id: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
Initial user creation is slow because the system must prepare per-user data (like storage and
permissions) whose cost is proportional to the number of pre-installed apps. On automovive's
reference implementation, it can take more than 10s, which is a bad user experience.
This change lets OEMs pre-create some users , so that high initial-creation cost is "paid" during
the initial boot. On automotive, it improves the creation of an additional user (or guest user)
in about 7s (from ~17s to 9s).
Bug: 111451156
Bug: 132111956
Bug: 140750212
Bug: 140868593
Test: manual verification
Test: atest FrameworksServicesTests:UserControllerTest#testStartTemplateUser_background
Change-Id: I81de1b5376dc9c42b63be8853d7204c88826401f
SYNCHRONOUS is a flag for setComponentEnabledSetting()
which will serialise the given user's package restrictions
state (including enabled + disabled packages) after the
specified component state has been updated.
Test: manual
Bug: 130044763
Change-Id: I615e5af6361718b5f3c355ca4424d1f8c4fb078f
Signed-off-by: Julius D'souza <jdsouza@google.com>
This reverts commit 243e7ea14b.
Reason for revert: b/141854898
Exempt-From-Owner-Approval: Revert for failure to boot
Change-Id: Id6812e5ecf7d88504706b2c4110d83f1034ab85c
Replaces PackageParser#Package and it's related structures with
ParsingPackage, ParsedPackage, and AndroidPackage.
This is a large scoped CL, the first step in an eventual goal
to refactor how data is handled in the package parsing and install
process. It introduces as few logic changes as necessary. Mostly
migrating to interfaces and renaming, moving parsing data calls into
3 separate interfaces that outline the intended flow for parsing.
ParsingPackage is built and used during what was PackageParser, now
replaced by ApkParseUtils and it's related classes. This is almost
exactly what was parsed from the XML/files on disk.
ParsedPackage is used when the object exits PackageParser and is
adjusted by PackageManagerService to what is considered the final
"parsed" state, adjusted from literal values, but consistent given
the same APK on disk. This should eventually be moved out of PMS
and possibly collapsed into the previous interface entirely.
AndroidPackage is the final state of the package after parsing and
adjustment has completed and no more mutations should be expected.
There are a few exceptions to this, included in AndroidPackageWrite,
which will eventually be refactored into PackageSetting or another
state class.
This marks PackageParser#Package and all the old infrastructure with
@Deprecated, as none of them are used internally. All usages were
converted, and the legacy Package is only built for un-converted tests
and @UnsupportedAppUsage methods.
There are numerous TODOs still outstanding, but addressing them
in this initial CL would introduce several logic changes. They've been
marked with the bug number and will be handled in follow ups.
This is being merged with caution thrown to the wind because
testing this on devices and in development will be the best way
to debug differences introduced by the migration. Getting it merged
as early as possible gives the most amount of time to fix regressions.
Waiting for tests of all the functionality could take literal years
before covering enough to merge this with all regressions verified.
Given a sample size of 4 heap dumps and the caveat it was taken very
early in the migration, there is a memory overhead of about 200 KB
versus the legacy implementation. This should be verified more
accurately and addressed in follow ups.
This CL also kills child/parent package support, since that's
broken already, and difficult to support with the new interface
structure.
Bug: 135203078
Test: booted an emulator, works generally as expected
Specific tests which failed / failed to build were fixed, but because
not all tests are currently passing before this change, not all were
verified.
Change-Id: I4ba050c228e6c60b8f63a9e3347b1f9a57ef794a
Allows retrieval of a string representation of overlayable resources
that can be compared during CTS testing to verify that the overlayable
resources on device match the expected overlayable API.
Bug: 135052616
Test: libandroidfw_tests
Test: atest OverlayHostTest
Change-Id: I613f28c202a0904a917577f932d072111c1aa7bd
We want to allow wellbeing apps to suspend in managed profiles.
This requires changing the internal data design of package-suspend
state to allow more than one suspending package, each with their
own parameters, namely - dialog info, app extras and launcher extras.
Also, removed the restriction of using setPackagesSuspendedAsUser when a
PO/DO exists
Test: atest com.android.server.pm.PackageUserStateTest
atest com.android.server.pm.PackageManagerSettingsTests
atest com.android.server.wm.ActivityStartInterceptorTest
atest GtsSuspendAppsTestCases
Bug: 138812320
Change-Id: If1263142fc9e6687e95af9b8d71ba8eff0c0fae9
Introduce a new API to request use of individual attestation
certificate for attesting keys generated by the
DevicePolicyManager.generateKeyPair method.
It builds on existing device ID attestation capabilities in two ways:
(1) Eligibility check: Assuming similar privacy requirements for the use
of individual attestation certificates, enforce the same conditions
for using them as the conditions for requesting device identifiers
in the attestation record.
(2) Keymaster interaction: Passing the right Keymaster tag to the
attestKey call, which is easily done in AttestationUtils.
Bug: 136494773
Test: CTS test to be added.
Change-Id: Idb5cee66d986a521c17e1955532d0bfae66c035d
Creates a new SystemConfig xml entry which allows a device to whitelist
system packages to be installed on users when they are created, based on
the type of user.
System packages will be installed on users when they are created, or
during OTAs, based on this whitelist. The whitelist can be
enabled/disabled via a Config resource.
For any user type, system packages can be whitelisted or blacklisted.
If it is both (for the same user type), the blacklist takes priority.
If it is neither, it won't be installed (since it isn't whitelisted).
If a system package isn't mentioned in the whitelist file at all, for
any user, then its behaviour depends on the Config resource value, which
can optionally implicitly whitelist all such apps on all users.
For now, the list is mostly empty and the default config is set to be
enabled but implicitly whitelist all system packages that are not
mentioned.
Test: atest FrameworksServicesTests:SystemConfigTest
Test: atest com.android.server.pm.UserManagerServicePackageWhitelistTest
Test: manually test user 0 by flashall -w and checking packages
Test: manually test OTA by setting setprop persist.pm.mock-upgrade 1
Bug: 134605778
Change-Id: Ia098c1f597f66a1c946cfcc9b7771c25e8ceabf7
Two intents that can be resolved to the same component were
evaluated as different intent filters, because one had the package
name set while the other one did not(null).
Skip performing package check if both two intents have components which
equals to its set package.
Bug: 64108432
Test: manual
Change-Id: I8163cbb6b56366ebbecaede7fa04ab3eab7cfe9f
This reverts commit 27c4e658b3.
Reason for revert: <potential performance regression. revert for now and looking for possible optimization from ART team>
Change-Id: I5bf728e4f6789d7e6398cf90f22fbf3a24d481c2
