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
(cherry picked from commit 45c183d201)
Merged-in: Ib3be016080d42fd76e7c131f4e44d815ce431e6e
Explains in more complete detail who should call lockNow(), when to call the method,
and what happens when there's no lock set on a device.
Test: make ds-docs -j32
Bug: 28831838
Change-Id: I5acc0cbfa63dffe8676e8b60476b584fd43b5bde
Since these are hidden it cannot be accessed by system service registery
Removing it for now and can be added later when these becomes SystemApi
Bug: 140768340
Test: Build & basic sanity
Change-Id: Ibb007f0a761bcbd006ebffbb552d0da82b586d03
This is needed for stacks to participate in transactions.
Most immediate use-case will be PiP during rotation
Bug: 119687367
Test: Added ActivityTaskManagerServiceTests#testStackTransaction
Change-Id: I50a5c3cea4f23f2be4e55ba38f8a5371fa9dfe79
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
The cancel listeners are created per PendingIntent instance and were
spamming the callback list stored inside PendingIntentRecord. In cases
where there is even a single live PendingIntent backed by this
PendingIntentRecord, all PendingIntent instances backed by this
PendingIntentRecord for which a callback was ever registered will leak.
Test: atest FrameworksMockingServicesTests:\
com.android.server.am.PendingIntentControllerTest
atest FrameworksMockingServicesTests:\
com.android.server.AlarmManagerServiceTest
Bug: 143091024
Change-Id: I65df12da0c437064e6e3719911926738c677c4eb
Merged-In: I65df12da0c437064e6e3719911926738c677c4eb
(cherry picked from commit 0d51a8bcc0)
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
This creates a java API for registering pullers. Will implement the
statsd side in a follow up CL.
Test: builds, boots
Change-Id: Ib6735984297ce3148839a6370a3c15b2a585baf5
Previously, this API did not support explicitly querying the parent profile.
This CL will now allow the WP DPC to call this method since all other password
related methods can already be called.
Screenshot of TestDPC: https://hsv.googleplex.com/4804408720228352 (WP DPC)
https://hsv.googleplex.com/5189846769336320
Bug: 138709470
Test: manual testing using Personal and WP TestDPC
atest com.android.cts.devicepolicy.ManagedProfileTest
atest com.android.cts.devicepolicy.PasswordComplexityTest
atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I0fb3a96c4469046c8712b5de582c501ea7eb3d8b
