USB API could be used before USB HAL version is updated.
Update USB HAL version early and log it.
Bug: 180711938
Test: USB HAL version updated normally
Signed-off-by: Jimmy Hu <hhhuuu@google.com>
Change-Id: If63c848e9643e9144662f031c981fad16d0a0fd6
Small refactor of DevicePolicyManagerService.setNetworkLoggingActiveInternal
to make it call NotificationManager without holding its lock.
Bug: 192435507
Test: enable network logging, check notification is shown.
Change-Id: Iab009978c472f843000c1b193de571863fc185bb
Effectively revert I59354066dafb02fe1d464fd1ddabf3969a4d0f1b to
allow password quality policy set on the profile DPM instance to
be enforced on device lockscreen provided the device has no
separate work challenge.
Bug: 182561862
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest ManagedProfilePasswordTest
Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: Create work profile, set profile password quality policy,
update device password via Settings and verify policy is applied.
Change-Id: I160997822f57c1da9327fe1a5482f445df8e1094
Fix an issue in existing implementation where the API will
throw exception when called on a device without DO or PO: a
slight tweak of semantics such that when the API is called by
a regular app, return the device-wide policy regardless which
user the caller is from.
Bug: 190024751
Test: manual with modifed TestDPC on unmanaged device.
Change-Id: I227d01ec275bc0a074a3789bab194c76fc72b5b8
This reverts commit 25f228087f.
Reason for revert: was temporary logging to investigate 185004808 and caused 191563556
Bug: 191563556
Change-Id: I0939a8e95f096c03fa157354630a9cba1edb59a9
DevicePolicyManagerInternal is not set when the device doesn't have
the device_admin feature, but some methods are still needed in that
scenario (like notifyUnsafeOperationStateChanged() on automotive).
Fixes: 190395562
Test: manual verification
Test: atest FrameworksServicesTests:DevicePolicyManagerTest FrameworksServicesTests:DevicePolicyManagerServiceMigrationTest
Change-Id: I48271b828ff01c4e4f3e0365410a7a745f1b0a1d
That method can be called by apps that have the MASTER_CLEAR
permission, even if the device doesn't support device_admin
Test: manual verification using automotive's KitchenSink app
Fixes: 190861794
Change-Id: I97ddb18580593e7b23f8fb55b3346049a2261144
For provisioned device
- Remove the check for the current user is the same as the primary user
- Check for whether the caller is device owner and the current user is
affiliated with the device
Bug: 185426804
Test: manual test with AAOS build with device owner setup and request
bugreport from TestDPC
Change-Id: I78066979fd54b480433ef9ba5144ca666c601591
Changed DPMS#isPackageAllowedToAccessCalendarForUser to always require
INTERACT_ACROSS_USERS/_FULL permission if called for a different uid
than the calling uid.
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Bug: 187043716
Change-Id: I230bbffbdf97c251c8a40add097b3b4254d39452
When DPM.setAlwaysOnVpn is called with package=null, it resets
any VPN configured by the user. With this change it won't happen
anymore: it will only reset VPN configuration if it was previously
configured by the admin.
If an admin actually wants to remove any user configured VPN, they
can enforce DISALLOW_CONFIG_VPN restriction which will remove any
user VPNs and will prevent the user from configuring a new one.
+ Also make sure that when the DPC removes an always-on VPN
configuration, the package loses ability to start VPN until the
user authorizes it again.
Bug: 139823667
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: Ia703015b4e8d7eaf156358d7eb000d6f58d32238
This is to allow 3p apps to query the state of the policy so they
can show appropriate UX to the user in case the app's interaction
with the plugged-in USB devices is disrupted by the admin policy.
Bug: 190024751
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Change-Id: I829ff84256e0288b88c11add53da312ee2bc2558
* In Android 11, setRequireAutoTime was deprecated.
The user restriction DISALLOW_CONFIG_DATE_TIME
should be used instead to enforce time policies.
* When removing the DO, requireAutoTime needs to
be set to false
* When transferring policies from the DO to the
COPE PO, the user restriction should be used instead
of requireAutoTime. This is because requireAutoTime
can never be turned false for the COPE PO
Manual testing steps - Scenario 1
* Flash device with Android Q build and set up
device in DO mode
* Apply some policies using TestDPC, including requireAutoTime
* Flash device with Android R build and do not wipe
* Replicate issue by checking date time cannot be removed
* Flash device with Android S build and do not wipe
* Verify date time restriction can be removed
Manual testing steps - Scenario 2
* Flash device with Android Q build and set up
device in DO mode
* Apply some policies using TestDPC, including requireAutoTime
* Flash device with Android S build and do not wipe
* Verify DO restriction has been set on parent admin
* Verify date time restriction can be removed
Bug: 165026695
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Manual testing
Change-Id: I76344fe2df7475b6411362b4aff806a5cbf053a7
Last year we added a security fix ag/12968597 to address
b/153995973. Now, some DPM methods require the interact
across users permission, unlike in R. This CL aims to
prevent potential security exceptions in these methods
by clearing their calling identity.
Bug: 182279073
Test: atest DevicePolicyManagerTest
Change-Id: Ie861a7880160563f9613db72e3283edac294a7a1
Remove left-over polices (such as mCanGrantSensorsPermissions)
from the cache so it's not interfering with subsequent test runs
Bug: 187862351
Bug: 184079462
Bug: 183162232
Bug: 183162329
Test: 1. atest MixedDeviceOwnerTest#testGrantOfSensorsRelatedPermissions
2. atest MixedProfileOwnerTest#testGrantOfSensorsRelatedPermissions
Change-Id: I8551fca161c7df39228587a024f468a496dcdb58
PDD: https://eldar.corp.google.com/assessments/875507949
RESET_PASSWORD
We log this when the admin forces a new password for the
device or the managed profile.
There is no log data (only the event).
RESET_PASSWORD_WITH_TOKEN
We log this when the admin forces a new password for the
device or the managed profile. The admin can change the
password even before the device is unlocked, as long as the
password reset token was previously provisioned.
There is no log data (only the event).
Bug: 186740337
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testResetPasswordWithToken
Change-Id: I07b66904e423bc6e1f4bdd4ae44aad0cae6d537b
Send ACTION_NETWORK_LOGS_AVAILABLE and ACTION_SECURITY_LOGS_AVAILABLE
as foreground broadcasts to reduce test time. Updated javadoc on
callbacks in DeviceAdminReceiver and DelegatedAdminReceiver.
Remove obsolete special handling of the two broadcasts above in
sendDeviceOwnerCommand(), now that they are only sent through
sendDeviceOwnerOrProfileOwnerCommand().
Bug: 183066771
Test: atest MixedManagedProfileOwnerTest#testNetworkLogging
Change-Id: I0758c0eb98be43b24cd08105a2449c349cfd4e6d
Changes
On an org-owned device with a managed
profile, the security logs available broadcast
should be sent to the work profile user
Manual testing steps
* Set up org-owned device
with a managed profile
* Enable security logging in
the work profile
* Force logs using adb
adb shell dpm force-security-logs
* Verify DeviceAdminReceiver
receives broadcast
Bug: 170293810
Test: manual testing
atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingWithSingleUser
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingEnabledLogged
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingWithTwoUsers
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingDelegate
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testSecurityLogging
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testSecurityLoggingDelegate
Change-Id: Ia955d6ef6b983fb1ff05dff9e68f8cb8e9b6e9f9
The current implementation does not work when the multi-user feature is
enabled because it clears the "globally" protected packages set by the
device owner whenever a new user is created.
Bug: 178500150
Test: atest FrameworksServicesTests:com.android.server.devicepolicy.OwnersTest
Test: atest FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Test: Ran the CTS tests that were added
Change-Id: Id04cb9b5b2357b0a0b5090442a39d97405287dbe
It should only be ignored when it's called to disable location.
Test: atest com.android.cts.devicepolicy.DeviceOwnerTest#testSetLocationEnabled
Fixes: 186263875
Change-Id: I71a4d91196f15b6e13bc0e87290bc0a9418ef87d
Policies that should be now cleaned up properly:
* setRequiredStrongAuthTimeout
* setScreenCaptureDisabled
* setPersonalAppsSuspended
* setFactoryResetProtectionPolicy
* setSecurityLoggingEnabled
* setConfiguredNetworksLockdownState
* setSystemUpdatePolicy
The cleanup is performed upon receiving ACTION_USER_REMOVED
after policy data is removed.
Bug: 162815601
Test: atest DevicePolicyManagerTest#testWipeDataManagedProfileOnOrganizationOwnedDevice
Test: atest OrgOwnedProfileOwnerTest#testCanRelinquishControlOverDevice
Change-Id: I23434c6e103a558304b6b83b86f9ea2cca5ed36c
