- 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
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
Bug: 67843538
Test: Manual test with CloudDpc that logout button can be controlled by DevicePolicyManager API and only enabled in shared userse
Test: Logout button can actually exit the user and ActivityManager log shows that user is stopped
Test: CTS is tracked in b/67843605
Change-Id: I9f27050654958ce55f574dd05ff80609255ffeb4
- DevicePolicyManager.setKeyguardDisabled
- DevicePolicyManager.setStatusBarDisabled
- DevicePolicyManager.setDeviceOwnerLockScreenInfo
- PackageInstaller install and uninstall apps
Bug: 64383519
Test: Can set keyguard disabled, status bar disabled and lock screen message in
affliated PO
Test: Can install and uninstall apps in affiliated PO
Test: CTS tracked in b/68925683
Change-Id: I71be25098436ba0b42050478c049850c2b21f6f4
Add a config to override the DPMS implementation class to
be instantiated from the Lifecycle.
Add a hasFeature method to the Injector class.
BUG: 63753860
Test: manual with TestDPC
Change-Id: I71ef518c49b2233744defdfb7c31019cb228d678
After Change-Id: Ibaba2ddd4f94fced1a2a7bfcfb91189302ec7f3a was merged,
KeyChain, by default, made keys installed in it not user-selectable,
which means users could not choose those keys in the Certificate
Selection prompt.
This is the correct behaviour (secure by default), but means the
DevicePolicyManager has to explicitly set keys as user-selectable
to be compatible with the previous behaviour.
This CL does the following:
* Adding an installKeyPair variant to the DevicePolicyManager to
allow specifying user-selectability of the key.
* Make old installKeyPair variants delegate to the new variant,
with the default of setting installed keys user-selectable.
* Modify the DevicePolicyManager service definition and service to
take the extra user-selectability parameter and set the value
in KeyChain.
Note that the reason the CTS test started failing is not related to
this change but a CTS Verifier test should catch the problem this
CL is solving.
Part of the fix for b/69337278
Bug: 69337278
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement
Change-Id: Ifc240ed4a20a9d00bc6140dfb45bd1140e1f8260
Network security watchlist service is a service to monitor all potential
harmful network traffic. By setting a network watchlist, any connections
that visit any site from watchlist will be logged.
Logs will be aggregated everyday and encoded using differential
privacy before exporting it from framework.
This feature is disabled now, run "setprop ro.network_watchlist_enabled true" to enable it.
All network events are handled in an async bg thread, it should not
cause any delay in netd. Also, it uses the hooks in enterprise network logging,
so we can run netd_benchmark to measure the impact to netd.
Here are the things not included in this CL:
- ConfigUpdater to get and set watchlist
- Differential privacy encoding logic and reporting
- CTS
- Memory and performance optimization for internal watchlist data structure
Test: manual - turn on the feature, hard code a watchlist xml, process
that visited that domain is being logged in sqlite.
Test: run netd_benchmark - seems no obvious performance change.
Test: bit FrameworksCoreTests:android.net.NetworkWatchlistManagerTests
Test: runtest frameworks-net
Test: runtest frameworks-services -p com.android.server.net.watchlist
Bug: 63908748
Change-Id: I09595178bac0070a867bc5e0501a7bf2c840e398
Add new DPM APIs to control which SystemUI features are enabled during
LockTask mode:
* setLockTaskFeatures()
* getLockTaskFeatures()
* int flags representing various configurable SystemUI features
Bug: 65813398
Test: bit FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Test: bit FrameworksServicesTests:com.android.server.am.LockTaskControllerTest
Test: cts-tradefed run cts-dev --module DevicePolicyManager -t com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Change-Id: I0ee3cf6dbe2234ec29d1384195dadc0f290aa73b
Fix: 67497358
Test: wait for cts test in the following cl. For unitest:
runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Add setTime and setTimeZone API in devicepolicymanager.
Add unitest for each API.
Following design doc: https://docs.google.com/document/d/1NV93mr2CT157S_haru1QbKo9HLeP9iPM9eMiGfVmfCM/edit
Change-Id: I188c27b0b99137b6f01e42ae1ad49356ce0a81b2
Create a settings class only for use with permissions. It's
subservient [and should only be accessed directly by] package
settings or the permission manager. The rest of the permission
related data needs to be moved to permission settings. At
which point we can start pulling the permission methods out of
the package manager service and into the permission manager.
We still have a somewhat tight relationship between package
manager and the permission manager. It's unclear how far we need
to separate them and if relying entirely on an internal
interface is sufficient.
Bug: 63539144
Test: Manual. Builds and runs
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.PermissionsHostTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsPermissionTestCases
Test: cts-tradefed run commandAndExit cts-dev -m CtsPermission2TestCases
Test: bit FrameworksServicesTests:com.android.server.pm.PackageManagerSettingsTests
Change-Id: I616184fa2135a11687e4ce615884f861466fdebe
Handle the special case when work profile is freshly created on a FDE device
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases
-t com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testPasswordSufficientInitially
Bug: 63887564
Change-Id: Ie8e430d4ff63be74fb2d4fc3ad3a8735f1de48b0
1. Fix system server crash when resetPasswordWithToken is called before use
unlock, due to DPMS enforces user is unlocked when calculating password
sufficiency.
2. Propogate new password metric from LockSettingsService to DPMS after a
password reset with token, and fix a bug where stale quality was used.
Bug: 64923343
Bug: 64928518
Bug: 65286643
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testResetPasswordWithTokenBeforeUnlock
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: runtest frameworks-services -p com.android.server.locksettings
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceAdminHostSideTestApi24#testRunDeviceOwnerPasswordTest
Test: runtest frameworks-core -c android.app.admin.PasswordMetricsTest
Test: runtest frameworks-services -c com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: Ibb3736547b3b36da4a8a67af711e08a38427aa56
