- Introduced DevicePolicyManager to set messaging for switching out of and into user 0
- Introduced coressponeding API to get the message
Bug: 71787514
Test: Set start and end session message with TestDPC, change is reflected
Test: Restart the device, switch message is still enforced
Test: Clear the message with TestDPC, reverted back to default
Change-Id: I527eca6f151cee35459abad7ae9dcdeef486148f
Let the device owner make backups with a chosen backup
transport mandatory.
BUG: 64012357
Test: make RunFrameworksServicesRoboTests
Test: manually together with the corresponding GmsCore change.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test
com.android.cts.devicepolicy.DeviceOwnerTest#testGetAndSetMandatoryBackupTransport
Test: cts-tradefed run cts -m CtsBackupHostTestCase --test
android.cts.backup.BackupDeviceOwnerHostSideTest#testMandatoryBackupTransport
Change-Id: I9bfae5799beae3459659e697813b75a9b508ae55
Changes of the SP are caused by untrusted credential reset which can be
triggered by certain admin modes. When such an admin is active, the SP
needs to be cached. Untrusted reset will be removed in a future release
at which point this caching can also be removed.
Bug: 71527305
Test: runtest frameworks-services -p com.android.server.locksettings
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy
Change-Id: I54f3b299b79ce019ba679b5550d37fd090b679fb
When user data is cleared in DevicePolicyManager, we clear the lock
task packages list. We should also forward that information to the
ActivityManager, so they can do relevant clean up; in particular this
will stop any running lock tasks.
Bug: 68688028
Test: manual
Change-Id: I0f40e7e08efd5ad2ca20b50ffa1032ddb13d1adb
Add a user restriction to allow profile owners to enforce a stronger
isolation of managed profile by preventing users sharing data into
the profile. This is achieved by disabling a subset of built-in cross
profile intent filters added by ManagedProvisioning during profile
inflation.
Implementation wise, DevicePolicyManagerService listens for the restriction
change and notifies ManagedProvisioning to modify the built-in intent
filters. This is needed since ManagedProvisioning has ground truth of all
built-in intent filters and manages them. It also has the advantage that
ManagedProvisioning only needs to run when a policy change happens.
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testDisallowSharingIntoProfileFromPersonal
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testDisallowSharingIntoProfileFromProfile
Bug: 63911046
Change-Id: Ia6d12a5086627d1280325cd19d6e3a0752dae633
- Removed START_USER_IN_BACKGROUND in createAndMaangeUser
- Added startUserInBackground that can return whether user is started. It checks for whether more users can be started without stopping existing users.
- Added canStartMoreUsers in UserController and ActivityManagerService
- Updated javadoc of a few user management API in DevicePolicyManager
- In UserController.startUser, return false if maximum running user limit is reached when starting user in background
- Only stop guest or ephemeral user that is being switched out in stopGuestOrEphemeralUserIfBackground
Bug: 71694116
Test: Create 3 ephemeral users, can startUserInBackground for first two but failed for the third.
Test: Switch to first user, second user is not affected.
Test: Switch out first user, second and third user is not affected. Can startUserInBackground for third user at this point.
Change-Id: I46aa1d8788851b10b5b169ac656cb982791de479
Adds the possibility of presenting a custom message on
the keyboard if you're trying to dismiss the keyguard.
This is particularly useful when you're showing the
bouncer because custom authentication (SmarLock)
failed.
Test: launch FLAG_SHOW_WHEN_LOCKED activity and
call KeyguardManager#requestDismissKeyguard
Fixes: 63940122
Change-Id: I0d88c0e59521887efa56d74874062b2b14970e4e
- Disallow managed profile from disabling keyguard and statusBar as it
has no effect
- Removed the ability for affiliated profile owner to set device owner
lockscreen message, as the message is not per user but set globally,
where the original intention is to set a per user lockscreen message
- Updated javadoc accordingly
Bug: 64383519
Test: Invoking setKeyguardDisabled and setStatusBarDisabled with managed profile fails
Change-Id: Ib3fdf44f55a7c5913ea38647c582bc962329c842
Enable requesting inclusion of device identifiers in the attestation
record issued for keys generated by generateKeyPair.
This is done by passing an array of flags with values indicating which
identifiers should be included.
Since the attestation record will include sensitive identifiers, it can
only be requested by the DPC in Device Owner mode or by the Delegated
Cert Installer in Device Owner mode.
Design note:
DevicePolicyManager defines its own set of constants for the different
identifier types (ID_TYPE_*) and prior to calling
DevicePolicyManagerService it translates them to the values defined by
AttestationUtils (which is not a public class).
The reason is to allow re-use of code in AttestationUtils for preparing
the attestation arguments.
In theory, these constants could be moved from AttestationUtils to
DevicePolicyManager, however that would create a dependency on DPM from
Keystore, which logically does not make sense as Keystore is independent
of the DPM (and in a lower level of the system, conceptually).
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement; runtest frameworks-services -c com.android.server.devicepolicy.DevicePolicyManagerTest#testTranslationOfIdAttestationFlag
Change-Id: Ifb42e8e813fa812a08203b4a81d15b1f91152354
Allows admins to blacklist passwords so they cannot be enrolled by the
user or the admin.
Test: bit FrameworksServicesTests:com.android.server.devicepolicy.PasswordBlacklistTest
Test: bit FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testPasswordBlacklist
Test: cts-tradefed run cts -m CtsAdminTestCases -t android.admin.cts.DevicePolicyManagerTest
Bug: 63578054
Change-Id: I8949ac929c760b66dc719cb058a9f88dc9cad727
Add a new method in the DevicePolicyManager to associate certificates (and
set the user-visibility) with a given key alias.
Conceptually, the new method, setKeyPairCertificate is very similar to
installKeyPair, except it does not install a key, only certificates.
(The new setKeyPairCertificate, together with generateKeyPair is
functionally equivalent to installKeyPair, except the keys are generated
in hardware rather than supplied externally).
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG
Change-Id: Idbfe151f6e5311766decbc1a010bff78dc60249f
When DISALLOW_UNIFIED_PASSWORD is enforced by managed profile
owner, the user is disallowed to user single lock for both primary
user and the profile.
DMP.isUsingUnifiedPassword() can be called by DPC to check if
this restriction is obeyed.
Test: make cts-verifier
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
com.android.cts.devicepolicy.ManagedProfileTest#testIsUsingUnifiedPassword
Test: cts-tradefed run cts -m CtsAdminTestCases -t
android.admin.cts.DevicePolicyManagerTest#testIsUsingUnifiedPassword_failIfNotProfileOwner
Bug: 63909482
Change-Id: Ib758e32d4bf4012d805185bce874f481e17576ba
If the KeyGenParameterSpec passed into
DevicePolicyManager.generateKeyPair contains an attestation challenge,
request an attestation record for the newly-generated key with the
challenge provided.
This particular implementation was chosen, rather than letting the
attestation record be generated at the same time as key generation, to
avoid having the attestation chain stored in Keystore and associated
with the generated alias.
The rationale is that this is a key that is potentially accessible by
multiple applications and the attestation chain may end up being sent
as a TLS client certificate chain, for example.
As the attestation challenge should be unique per device, to avoid
the potential of sending / sharing unique device information, by
explicitly requesting an attestation record after key generation, the
attestation record is only returned to the generateKeyPair client and
not persistend in Keystore.
Bug: 63388672
Test: New CTS test to be run with: 'cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG'
Change-Id: I95a9aef179173b571b533301ac438c675e8fe702
- The getDisallowedSystemApps is based on OverlayPacakgesProvider which
is moved from ManagedProvisinoing
- getDisallowedSystemApps will be used by ManagedProvisioning
- createAndManageUser will now use getDisallowedSystemApps to disable
disallowed system apps when creating users
- LEAVE_ALL_SYSTEM_APPS_ENABLED can be passed to createAndManageUser to
enable all system apps
- ACTION_MANAGED_USER_CREATED will be broadcasted to ManagedProvisioning
after managed user is created to take a system app snapshot
Bug: 65842187
Test: OverlayPackagesProviderTest passes
Test: Disallowed system apps does not appear in device owenr, managed
profile, and managed users
Test: System app snapshot is created after provisinoing device owner,
managed profile and managed users
Change-Id: I86f870f7814b5700cf5539e889fb6998514d110f
Only admins that require PASSWORD_QUALITY_COMPLEX are now
taken into account for minimum lower/upper case letter counts
as specified in the docs.
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test
com.android.cts.devicepolicy.DeviceAdminHostSideTestApi23
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test
com.android.cts.devicepolicy.DeviceAdminHostSideTestApi24
Change-Id: I0bfba7a5843d0acfa753cf0eb474769107feef43
- Also unhide setKeepUninstalledPackages
- installExistingPackage accpets delegation API because all app
managemnet PIs did the same, including setKeepUninstalledPackages and
enableSytemApp
Bug: 70017947
Bug: 65842106
Test: Install apps already installed in u0 in shared user should succeed
Test: Install apps in setKeepUninstalledPackages cache in shared user
should succeed
Test: Install apps via delegated package should succeed
Test: Install apps via unaffiliated profile owner should fail
Test: Install apps not installed in any user or in APK cache shoudl fail
Change-Id: Iba563b2050abd0d1f46bfa06cfc0526b7b476b3b
Bug: 67580550
Test: The AP returns false in primary user.
Test: Create ephemeral user with createAndManageUser, ensure the API return true.
Change-Id: I1e670ca8a8c6171ddb94a1e4b1cb1a958f12919d
In the same bit of code, fix a system restore issue: in the
course of setup + restore, we reestablish permission grants and
notification state up front for the to-be-restored app, and
then bring in its data. However, a data wipe is part of the
prologue for that data delivery -- so we were inadvertently
unwinding the permission grants and notification state restore
that we'd just performed. Now, we distinguish the restore flow
from other clear-data operations so we don't unwind that operation.
Finally take the opportunity to elide a lot of copypasta code into
a single predicate-driven implementation.
Bug: 67508896
Bug: 69538432
Test: atest android.app.cts.AlarmManagerTest
Change-Id: I15c912c3c99645599ae9bd6fb7337fa86b4e5757
See build/soong/README.md for more information.
Test: m checkbuild
Exempt-From-Owner-Approval: trivial conversion
Change-Id: I417409281c928ea667d937090d2a0d9d72a449a2
This is the crux of the Verified Access feature implementation:
Adding the ability to generate KeyChain keys directly by the
secure hardware, rather than installing software-generated keys
into KeyChain.
Add generateKeyPair to the DevicePolicyManager, which delegates key
generation (via the DevicePolicyManagerService) to the KeyChainService.
Design highlights:
* The key generation is delegated via the DevicePolicyManagerService to
check that only authorized callers request key generation in KeyChain.
* KeyChainService performs the actual key generation so it owns the key
in Keystore outright.
* DevicePolicyManagerService then grants the calling app access to the
Keystore key, so it can actually be used.
* Loading the public/private key pair, as well as attestation
certificate chain, is done in the client code (DevicePolicyManager)
to save parceling / unparceling those objects across process
boundaries twice (for no good reason).
NOTE: The key attestation functionality (that includes Device ID) is
missing/untested. Will be added in a follow-up CL as this one is quite
big already.
HIGHLIGHT FOR REVIEWERS:
* API: New API in DevicePolicyManager.
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk)
Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
When a managed profile has separate lock (a.k.a work challenge)
and maximum screen off timeout set by admin, this timeout will
only cause the profile to get locked, not the whole device.
PowerManagerService now tracks some per-profile state for profiles
that have lock timeout set by admin and have separate lock:
1. timeout set by admin.
2. wake lock summary
3. last activity time
4. whether the profile is considered active
5. whether the profile got locked last time it went inactive.
Wake lock summaries and last activity times are updated at the
same time as global wake lock summary/user activity is updated.
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Bug: 63908311
Change-Id: Ief7be4e0bf12bdbedef94a129a13d07a9f98e75c
