ResourcesPerfWorkloads replays record resources calls for 1P and 3P
apps. The recordings use private resource ids. Since private
resources ids can change between builds, the replay must have the
ability to use a stable version of framework resources with the
correct resource ids.
Bug: 136085555
Test: atest ResourcesPerfWorkloads
Change-Id: I46297e355ed6347ce8063e7f1c26708f28faacc8
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
This is partial merge of aosp/Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09. Telephony greylist cleanup has been done separately. Note that annotations outside of frameworks/base/ have been merged from AOSP.
Bug: 137350495
Test: m
Exempt-From-Owner-Approval: merge
Change-Id: I015c466e8b69cc0fed5e9d394ba865aad11d8ba6
Context.registerReceiverForAllUsers are already marked as @SystemApi.
The same method in ContextWrapper overriding it doesn't need to be
annotated as such. In fact, that API is even not recorded in
system-current.txt.
Bug: 144424011
Test: atest CtsSystemApiAnnotationTestCases
Change-Id: I60890104bf20a2c674edd91ec6b487cca1b4e37b
AuthService in its current form is a thin wrapper around
BiometricService. It initializes BiometricService in onStart();
registers fingerprint, face, and iris authenticators; and forwards all
of the incoming calls to the corresponding methonds in BiometricService.
The next step will be to move non-biometric related functionality from
BiometricService to AuthService, and turn BiometricService into a module
with a stable API.
Bug: 141025588
Test: atest AuthServiceTest
Test: atest BiometricServiceTest
Test: BiometricPrompt works in BiometricPromptDemo
Change-Id: Ia861b7c2d80bfca386c3e0b44ec35b4aca3b0ffc
* changes:
Expand ContentProviderOperation support of extras.
Extend insert/update/delete to provide extras.
Query arguments for grouping, other SQL clauses.
Now that we allow extras in more ContentProvider calls, we should
also allow CPO to define and pass those extras into a provider. We
recently added flexible utility methods like withExtraBackReference(),
so this change starts passing those values to insert, update, delete,
and query.
Bug: 131643582
Test: atest CtsContentTestCases
Change-Id: I4a445c061bbd84f45bdb80d336a2d0928b7fbe9c
A few releases ago we added ContentResolver.QUERY_ARG_* constants
to query() as a new best-practice that will help wean us off raw
SQL arguments. (For example, a provider could add their own
custom arguments like QUERY_ARG_INCLUDE_PENDING to cause the query
to reveal pending items that would otherwise be hidden.) This
change expands update() and delete() to accept those arguments.
This change also expand insert() to accept extras too, as part of
preparing to support an upcoming MediaProvider feature that will let
apps place new media "adjacent" to an existing media item. (Sending
that adjacent item through extras is cleaner than trying to send it
through escaped query parameters.)
Bug: 131643582
Test: atest CtsContentTestCases
Change-Id: I436296155b9b5f371b4cbe661feaf42070285fcc
Over time we've expanded ContentResolver to accept a Bundle of
arguments to influence how a query is performed, and this change
expands that set to allow setting of raw GROUP BY, HAVING, and
LIMIT clauses. Note that providers are not required to implement
each of these arguments; they simply need to inform callers which
of them were honored via EXTRA_HONORED_ARGS.
This change also adds support to MediaProvider for handling
these arguments.
Bug: 143966486
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ia839b5a1917d7833f03e022cfef65652c0d7a01d
Introduces the notion of 'user types' to UserManager.
Previously, users only had properties, set by UserInfo flags. We now
solidify some of these as formal user types. Each user must be of
precisely one user type. The configuration of each type is defined
in a UserTypeDetails object.
Prior 'types' - namely Guest, Restricted, ManagedProfiles, Demo, and
'normal' - that were set via UserInfo flags are now controlled via
UserType. Previous UserInfo flag methods for categorizing these are
still supported as long as no user of of more than one type.
If a user was (e.g.) previously both Guest and Demo, it is now
invalid and will be prevented from upgrading. This should not be a
problem in AOSP, where these 'types' were assumed mutually exclusive.
UserTypeDetails is sufficiently general to support future non-managed
profiles. To this end, the logic for specifying badges and their
colors/labels is contained by UserTypeDetails, and therefore
UserManager is responsible for delivering the corresponding badge
information.
Bug: 142151520
Test: added new test class UserManagerServiceUserTypeTest
Test: added additional tests in UserManagerServiceUserInfoTest
Test: added additional tests in UserManagerTest
Test: added additional tests in UserManagerServiceCreateProfileTest
Test: created UserTests to run the various pm.User*Test's
Test: atest \
com.android.server.pm.UserTests \
UserLifecycleTests \
ManagedUserContentResolverTest \
CtsDevicePolicyManagerTestCases \
CtsMultiUserHostTestCases \
com.android.server.devicepolicy.DevicePolicyManagerTest \
com.android.server.am.UserControllerTest \
CreateManagedProfileTaskTest
Test: atest com.android.server.pm.UserManagerServiceCreateProfileTest
using adb shell getprop persist.sys.max_profiles # for 5 and -1
Change-Id: Id1183a76055e9a7610965cf40b256d1392afe6f8
This API is used by wifi mainline module, so converting it to a formal
API.
Bug: 141943978
Test: Compiles
Change-Id: I563b6b37002975639fde036014cd0955fc8edef9
MediaProvider makes heavy use of Uri change notifications, which
currently need to be delivered one at a time through the Binder
interface. To optimize this, allow callers to provide a collection
of multiple Uris to notify with a single Binder call.
Bug: 134170767
Test: atest cts/tests/tests/content/src/android/content/cts/ContentResolverTest.java
Change-Id: Ifef778e88bb772b5580f70929c6f2e9c166d1c0e
Now that RROs are loaded as shared libraries,
LoadedApk#makeApplication is attempting to find the onResourcesLoaded
method of the overlays. This is a performance hit and causes more
memory than necessary to be allocated during application start up.
Bug: 143314947
Test: com.android.performance.tests.HermeticMemoryTest
Change-Id: I3b8cd22dae83e0164d6678c80279f9fffceb34e6
Status and Statistics info within SyncStorageEngine was being stored
using Parcels, which is not recommended. Updating both of them to use
protos now. Additionally, because of protos, storage space on disk
consumed by these files are reduced by more than 50%.
Also added unit tests for SyncStorageEngine.
Bug: 38177679
Test: atest com.android.server.content.SyncStorageEngineTest
Test: build and flash - no errors in logs
Change-Id: I187cb6c271333f366f5c7f651f75b4161fee90d4
This change adds a bare-bones system service, implementation will follow
later.
Bug: 143559646
Test: atest cts/tests/BlobStore/src/com/android/cts/blob/BlobStoreManagerTest.java
Change-Id: Idf21dfcd11dd32a42b62c6ad965d6f5ad7eed1b4
