Prior to this change, we were resolving the mime type of a given intent
while holding the package lock. With this change, we instead rely on the
preferred-activity declaration to define the mime type if it's
important, removing need for an activity manager service call and the
potential for deadlock.
Bug: 143105100
Test: Manual; sideload to /system/etc/preferred-apps/ and reset app preferences
Change-Id: Ie0b124216b49a1147bd5c2e82cf8c7cadb3f08ac
Add a job to prune any usage stats data that exists on disk belonging
to uninstalled packages. This job will be scheduled every time there
is a package removal, appending to the work of any previous pending
jobs. Jobs for each user will be executed when the device is idle.
Bug: 143889121
Test: atest UsageStatsDatabaseTest#testPackageDataIsRemoved
Change-Id: Iee00917a940930271ca40367ca24992cde018616
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
UsageStatsManagerInternal is also no longer an API surface for
registration of app idle state change listeners. AppStandbyInternal has
become a proper LocalService and interested clients can just use that
directly.
Bug: 140833849
Test: boot & run normally
Test: verify system package backup
Change-Id: Ie63f438f129cd8f41169778a3045d131ca7322fb
Because SettingsProvider needs to call through the IUserManager
interface there is now a method to provide restricted-access information
via that route. It has the same protection as the implicit local
service call surface that was previously used: only system-uid callers
can invoke it.
Bug: 140833849
Test: system boots & runs normally
Change-Id: I05823ca57240ab10feb382c45590541212e406c1
Wifi mainline module needs some permissions which are currently only
granted to signature components. Since mainline modules are not going to
be signed with OEM's signature, we need a new protection level to grant
some of these permissions to the wifi mainline APK.
Bug: 142234604
Test: Verified that wifi can get INTERACT_ACROSS_USERS_FULL permission
Change-Id: I26b0edff62497b5e08c2f2f504b0cd5f950682ad
for oems which take telephony mainline module, all telephony related
apks will be signed with non-platform certificate. that said apks won't
be able to grant platform signature permission. Solution is to add a new
telephony protection level.
Bug: 141479803
Test: cts & manual
Change-Id: Ib3be016080d42fd76e7c131f4e44d815ce431e6e
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
