Currently backup service is re-activated unconditionally when clearing
a device owner but not profile owner. With this CL it should be
re-activate in both cases.
NB: there are two bits of state related to backup service:
1. activated or deactivated: This is out of user control, but can be
changed by the admin via DPM.setBackupServiceEnabled (this name is
a bit misleading here).
2. enabled or disabled: this is controlled by the user via Settings
and only available when backup service is activated (see 1.)
Bug: 143274029
Bug: 147997438
Test: atest CtsAdminTestCases && adb shell bmgr enabled
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Merged-In: I6f11642abe544c7df265ed7e2ad466d47796e7f9
Change-Id: I6f11642abe544c7df265ed7e2ad466d47796e7f9
(cherry picked from commit 775b26d884)
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
bug:141028068
Merged-In: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
Change-Id: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
Introduced in ag/2664156, dismissing a keyguard when it's being disabled has
also caused it to be shown whenever it's being enabled (or re-enabled, or
calling DPM.setKeyguardDisabled when keyguard is enabled).
This change should stop keyguard randomly popping up.
Bug: 133730775
Test: manual
Change-Id: I49f28714b2d149f13168e7564947aaf09c593117
Bug:133782444
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.PasswordComplexityTest#testGetPasswordComplexity (on a device without the feature)
Change-Id: I5f55a867a1a5a86387f9ad9877e593adac6f6f90
Add a mapping for kDownloadMetadataSignatureMismatch (26) from
error_code.h. This involves creating a new system API constant, but it's
just a simple definition so we don't have to hard-code '26'. These
constants are already set in error_code.h. A TODO has been added to
create this constant in the next release.
Test: manual
Bug: 132827080
Bug: 133396459
Change-Id: I4d59702879f2ed654dd467a1ae2dc8e400a0938d
At the moment KeyguardDisableHandler calls into DevicePolicyManager
to retrive the aggregated password quality for the current user
while holding the WindowManager lock. This is a lock inversion
and causes deadlock. To fix this, introduce a per-user password quality
cache in DevicePolicyCache and switch KeyguardDisableHandler
to use that instead.
Test: manual
Fix: 129087668
Change-Id: I8c02ca442dde76ed350f22ac04a52adc82d21d00
The code allows to also whitelist only a select set of permissions, but
this is not yet exposed in the API.
Also: Fix up shell commands for restricted permissions
Fixes: 132368462
Test: - Enabled app via device admin in secondary profile
-> verified that permissions were whitelisted
- Installed existing and new app using --restrictpermissions and
not
-> verified that permissions were whitelisted or not
atest AppRestrictionsHelperTest
RestrictedPermissionsTest
Change-Id: I9cd76c555b40663f2e25ad86e8a54991baae346c
Merged-In: I9787e63d8beb8f6b1ba2d15532d4c0f69dbdf863
Two SecurityEvents should be considered identical as long as
their event content equals, disregarding the id field.
Test: manual
Change-Id: I811f9a104ed3a0d9e02991aeb9e3653c5c02efc3
Fix: 132367517
The following device admin related events now generate interruptive notifications:
1. Admin-triggered remote bug report collections (requires user action)
2. Remote work profile wipe - post wipe notification
3. The enabling of Network logging
4. Admin remotely installs/removes an APK
5. Work profile needs unlocking after boot
Test: manual
Change-Id: If5a51123c05b15e544a31ac7ec6b42ec831a1ccc
Fix: 130623009
Fix: 120770584
Fix: 118810015
Bug: 124066840
Test: manual (overlay resource with component name and confirm only that
component can be set as profile owner after setup is complete)
Change-Id: If67ca69f03fda35ee8a2d5a43e96a9f1e64d8886
It has good enough performance for dogfooders, so let's just keep it.
Change-Id: Iea4a82e66f83f5199107fc95f4ef67390590590b
Fix: 74553426
Test: build / boot
For DA, it is important that apps can't update their policies from what
the user agreed to. This doesn't apply to DO and PO.
Fixes: 123415062
Test: Manually tested with custom TestDPC build.
Change-Id: I6d4dd98bdc6bee8fee03451530d98d67ce005b30
Note: we can't add a CTS test for this behaviour since the UpdateEngine
is an implementation detail.
Fixes: 124106342
Test: Manually tested
Change-Id: Ib8e6895211b5d39a4d037d383c115011084ea257
If an exception was thrown by one of the methods, we were not logging
the event, which caused the CTS test to fail.
In particular, this happened on non-AB devices, such as the emulator.
Bug: 127268862
Change-Id: I8f853d5e0a8e810a570562071fb73266fee3b696
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.DeviceOwnerTest#testInstallUpdateLogged
Obtain the correct admin and dialog information when a restriction prevents the
user from installing apps from unknown sources.
Bug: 118881180
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I8112aaca64f85d421ee1029edc5c47909e31f12f
Add alternative APIs to allow untrusted password changes explicitly, so the caller
can choose to use them if needed.
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/locksettings/
Bug: 120039091
Change-Id: I4ca03c9185081d300d7e325965b1e20515e33d51
Previously password quality would be promoted to whatever admin
has requested or depending on whether it was PIN or password.
Bug: 120536847
Test: manual, steps from b/123924734
Test: atest DeviceAdminHostSideTestApi24#testRunDeviceOwnerPasswordTest
Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest com.android.cts.devicepolicy.PasswordComplexityTest
Test: atest PasswordMetricsTest
Change-Id: I51ca2d327f4c6db8f74c0b0ec35e4a3a346a9b5c
To follow up on the previous review, rename the success constant from
"success" to "no error" since the enum it's associated with now refers
to error codes.
Bug: 124301971
Test: atest com.android.cts.devicepolicy.DeviceOwnerTest#testPrivateDnsPolicy
Change-Id: I6b82dd44cbf2c18fb8c1673a272f22f0e8b39dbb
This is to match the method name "getPasswordComplexity" as requested by API review feedback
Bug: 128030136
Test: N/A
Change-Id: I999657f88ed425333adbe97b9ecc33da3769ba90
Previously, the agent will have to query the TrustManager to see if a
recently added escrow token has been activated. If the agent asked too
soon about the token state, then the result could be inactive. That
will be hard to distinguish from when the token is actually inactive
because activation failed.
This change pipes the call from LockSettings to the TrustAgentService
through the TrustManager when the token is activated. So, the trust
agent doesn't have to query, it just gets notified.
Bug: 124312230
Test: Observe the onTokenStateReceived() callback received on the trust
agent.
Change-Id: I0ac674219fd7925ba36f50bb695c9998c18226f7
Add more a specific description of what methods do when the
secure lock screen feature is not supported by the device.
Bug: 123270501
Test: make
Change-Id: Ib6c16f421cf3dc60b0f0cb0c6335c6dc35ac7ece
This is much slower than the old way as we need to call into a different
process. On the other hand this handles the following cases correctly:
- foreground / background permissions
- pre-M apps
- split permissions
Test: CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testPermissionGrant,testPermissionPolicy,testPermissionMixedPolicies,testPermissionAppUpdate,testPermissionGrantPreMApp
Change-Id: I5cd139ad29e5b77b77b02e12c75eb774984a7759
Bug: 124128308
Relating to frameworks/base
Bug: 120484642
Test: manual - test setting and unlocking passwords/pins/patterns.
automated - about 20 failing due to an issue in the test code.
Change-Id: I57aa530ca2db1a026c56b66f5b4c91172f2667f6
