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
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
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
We used to store the actual permission state for pre-M apps in app
ops, which creates two different sources of permission state and is
hard to handle correctly. This change will allow us to store the
permission state for pre-M apps within permission as
FLAG_PERMISSION_REVOKED_COMPAT (and syncing app op state based on it),
and is part of the effort to support rollback of runtime permission
state managed by PermissionController.
Actually, we do set a REVOKE_ON_UPGRADE flag properly when user
grants/revokes a runtime permission for pre-M apps, so it can be used
for computing app op state. In the case where app ops are incorrectly
set to denied without setting this flag, the app won't get the
permission revoked upon upgrade to support runtime permissions, and is
stuck with the denied app op, so overriding the app op state in this
case is arguably fixing a bad state.
Since the proposed new flag will cover whatever REVOKE_ON_UPGRADE does
currently, and REVOKE_ON_UPGRADE did imply denying app op in its
javadoc, this change is simply adding our new flag by renaming
REVOKE_ON_UPGRADE.
Bug: 136503238
Test: manual
Change-Id: Ib910f4df543d2fd8de259a6675f043d870a6f4c1
today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
This change breaks isInstantApp up into a public and internal
implementation so that internal interfaces have a means of calling
without any permission checks that only apply to public callers.
Fixes: 141288362
Test: Work profile setup
Change-Id: I2cb8338c2a68bc9c4a61c075398d767980c504ed
If an app doesn't have a launcher activity enabled by default, a
synthesized activity isn't created for that app.
Test: make ds-docs -j32
Bug: 140968734
Change-Id: I2fe8666ee8cde479f404e43c622f03891d96c38f
This change turns off the kill switch for App Enumeration by default
and sets the PlatformCompat feature to @Disabled until we're ready to
turn it on by default for beta.
Bug: 136675067
Test: atest AppsFilterTest
Test: atest AppEnumerationTests
Change-Id: I7f3c1995318838cda5d7025de8ae366cde75930f
