1. Modify DPM.isProvisioningAllowed to allow it to happen
2. Introduce hidden API createProfileForUserEvenWhenDisallowed for
ManagedProvisioning app to create profile under DO.
Apps with MANAGE_USERS permission can clear the
DISALLOW_ADD_USER restriction anyway, so they do not gain extra power.
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/pm/UserManagerTest.java
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.CustomDeviceOwnerTest#testIsProvisioningAllowed
Bug: 31895999
Change-Id: I10dc3043653130ae717a1d3d8256c9e73231bb21
We were disabling backup in consumer mode as well.
BUG=31754835
TEST=android.content.pm.cts.shortcuthost.ShortcutManagerBackupTest
Change-Id: I42e5cfa512fda1b471eb62c7eb8bc346383da2fa
Allows PO and DO configure strong auth timeout for fingerprint.
Bug: 31430135
Change-Id: Ie6451d49aa95527adc3720d9a2a0848f58940510
(cherry picked from commit 8f010dd25d18151cc47accc7d853b4f8f7fe8491)
- Non-test-only DO/PO still can't be installed when there are
accounts.
- Test-only DO/PO can be installed even when there are accounts,
as long as all the accounts have the
"android.account.DEVICE_OR_PROFILE_OWNER_ALLOWED" feature.
Some authenticators claim to have any features, so to detect it,
we also check android.account.DEVICE_OR_PROFILE_OWNER_DISALLOWED
and disallow installing if any of the accounts have it.
- Also add logs on certain important events in DPMS.
Bug 28928996
Change-Id: I62efce10e9cc22e994ea8cae91a4fafcce25dd77
Bypassing work challenge in freeform mode was trivial by just keeping
work apps open in freeform mode and then switching focus to them from
another app.
Because the only interception point is startActivity this never
triggered work challenge.
The solution is to trigger the check on focus change events and also to
allow passing the result back into the freeform stack instead of dumping
our user out into the homescreen.
Change-Id: I141ecf90b5f0e708a21d27141b6fec6074e5d475
Fix: 30693465
The Device Owner could remove this user restriction anyway.
Also do the same for PO in primary user.
BUG:27263403
Change-Id: I0f7b9a6237e40668b1eab2f55dc5c3f79e0d6eeb
If someone calls removeActiveAdminLocked more than once, it is possible
for the device policy data to end up with more than one copy of an admin
in the list mRemovingAdmins. Due to extra entries, once the admin
component is removed, it is not being allowed to be set as an admin again,
until the device reboots or mRemovingAdmins is cleared from the memory
due to some other reason. Fixing this by making sure we do not add
duplicate entries to mRemovingAdmins
Bug: 30369197
Change-Id: I1d53c41312171425bbd6e6e4153148276f1b098d
The minimum password length is only required for certain password
qualities so only check the minimum length in those cases.
Bug: 30109030
Change-Id: I330c88fc0b22179e126fc1241a9c58d5e0d73e8e
The minimum password length is only required for certain password
qualities so only check the minimum length in those cases.
Bug: 30109030
Change-Id: I330c88fc0b22179e126fc1241a9c58d5e0d73e8e
