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
Currently admin enabled broadcast is sent as a background broadcast
upon ACTION_USER_STARTED. This can lead to delays on managed secondary
users. During that period the admin has no chance to apply any
policies, effectively leaving the user unmanaged. Sending it as a
foreground broadcast should speed up that process.
Using a foreground broadcast on ACTION_USER_STARTED can cause a race
condition where the user is not unlocked yet and therefore the
broadcast is omitted (unless the receiver is direct boot aware).
Sending the broadcast upon ACTION_USER_UNLOCKED fixes that issue.
Bug: 64382185
Test: manual
Change-Id: I3a89ba2e64cd6013723699cc1211b0144db254a6
Currently if the keyguard is shown, setKeyguardDisabled does not
dismiss it but disables it for the future. This change also dismisses
the keyguard in this situation.
Test: manual
Bug: 64383815
Change-Id: Idb89f363510a18c741d335d96d11c5492c0eaee3
Currently DPM.createAndManageUser does not start the user in the
background, leading to a potential race between user having access to
the secondary user and admin having time to push policies. To mitigate
this we're adding a flag that allows secondary users to be started in
background as part of the API. The admin can then apply policies before
switching to that user.
Bug: 64382185
Test: cts-tradefed run singleCommand cts -m DevicePolicyManager --test
com.android.cts.devicepolicy.DeviceOwnerTest#testCreateAndManageUser_StartUserInBackground
--abi arm64-v8a
Change-Id: Id6f6ab7584a249680c8554c21977cbb69a220332
This new API lets DOs clear application data on a per package basis. It
can be used to reset misbehaving packages as well as for a light-weight
session model where employees log in to a device and have their data
cleared when they log out.
Test: cts-tradefed run singleCommand cts -m DevicePolicyManager --test
com.android.cts.devicepolicy.DeviceOwnerTest#testClearApplicationData
--abi arm64-v8a
Bug: 63910199
Change-Id: I6a03ae90fffe6159172ea7e46f9b8b69efeabcfe
- Allow Global settings to be set in demo mode
- Allow Secure settings to be set by demo users
- Allow fully enabling apps for demo users
- Send enable broadcast as foreground broadcast
Bug: 62712426
Test: runtest -c \
com.android.server.devicepolicy.DevicePolicyManagerTest \
frameworks-services
Change-Id: Icd5d1eda12aa6b97bd4770713710a982bb0fc8e5
Ephemeral users where initially created for split system users. Make
them available on all systems. This CL is initially for evaluation
purpose to see how advanced they are in the current system.
Test: manual
Bug: 64381943
Change-Id: Ia9caa8e07037a64055f2033113806b8c559a75af
Do not wait until deivce_provisioned is set. This logic is currently used
for Wear devices and since nothing except security logging now depends on
this property, we can safely set it to "true" if there is a DO on the device.
Bug: 35342467
Test: manual, setting a DO before SUW triggers setting of the property.
property to be set.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest
Change-Id: I2c179194fb8f0f4bef96bb21dbf2522ba99afcec
Stop NetworkLoggingHandler holding a lock
when calling back into DevicePolicyManagerService.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testNetworkLoggingWithSingleUser
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testNetworkLoggingWithTwoUsers
Bug: 62966480
Change-Id: I41c3edca8922008a9d838d71ddcc50883699bc74
Add a new flag in the DevicePolicyManager so that we can Use
EuiccManager#eraseSubscriptions(PendingIntent) to erase all the carrier data
from eUICC chip if the user choose to "ERASE" from the Android device manager.
Bug: 37277944
Test: E2E
Change-Id: Ia78090a00d956c645725be4fd591e02ded8ec467
Previously, DevicePolicyManager saved password stats (number of letters,
number of symbols, etc) to disk for FDE devices. This made it possible
for the isActivePasswordSufficient() API to return a result before the
password was entered for the first time after a reboot. Access to these
stats would significantly narrow the space of possible passwords an
attacker would need to explore.
Going forward, every time either the password or the password
requirements change, a flag will be persisted indicating whether the
current password meets the requirements. Before the password is entered
for the first time after a reboot, isActivePasswordSufficient() simply
returns the value of this flag. (After the password is entered for the
first time, isActivePasswordSufficient() uses password stats saved in
memory, as is the case today.)
This creates a window where isActivePasswordSufficient() may return an
incorrect value before the password is entered for the first time, if
the requirements are changed after startup so that the current password
no longer meets the requirements. This has been deemed an acceptable
compromise in order to avoid storing potentially sensitive data.
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest
frameworks-services
Bug: 34218769
Change-Id: I5d3cd008a9ee2787bcb10ed5455bb61c6014ae00
- When the DO/PO process crashes twice with a short interval, AM gives up
and the binding will be "died". Once binding is in this state it'll never
be re-connected.
(Still, DO/PO can disable and re-enable their DAS to force DPMS to bind again
though.)
- Detect this and re-connect after one hour.
- Back-off time will be exponentially increased and never reset until DPMS
explicitly re-connects, which happens when:
-- the device rebooted,
-- the user stopped and re-started, or
-- the DAS is disabled and re-enabled.
Test: adb shell am instrument -e class com.android.server.am.PersistentConnectionTest -w com.android.frameworks.servicestests
Test: adb shell am instrument -e class com.android.server.devicepolicy.DevicePolicyConstantsTest -w com.android.frameworks.servicestests
Test: adb shell am instrument -e class com.android.server.devicepolicy.DevicePolicyManagerTest -w com.android.frameworks.servicestests
Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l VERBOSE -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceAdminServiceDeviceOwnerTest
Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l VERBOSE -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceAdminServiceProfileOwnerTest
Bug 37711907
Change-Id: Ie0b227a94e6ce85d72a969a4dea1020baf734e2f
The abbreviation is not in common use. Also remove FBE from
documentation as it also isn't used elsewhere.
Test: Build success
Bug: 37621349
Change-Id: Icf19be5e96e71dcd45aa7cac8f58b05b6d77d02b
When this restriction is enforced Bluetooth sharing option should not be
present when the user tries to share something. Previously this was handled
by explicitly disabling bluetooth sharing activity during managed
provisioning, now this code is to be removed (see topic CLs) and the same
behavior should be achieved by setting this restriction for profile owners
by default.
In Bluetooth:
1) Don't check restrictions on boot, it is invoked anyway through the
listener during boot.
2) Ignore when the restriction is "changed" from true to true - i think
it was the initial intent in that condition.
3) Disable the component for a particular user and not always the
system user. This is something that has to be fixed in O I think since
currently in secondary user the bluetooth itself gets disabled but the
sharing thing still shows up.
In DPMS:
1) Now ActiveAdmin for PO also contains a set of restrictions applied by
default.
2) Now all ActiveAdmins for POs are loaded quite early. That shouldn't
have huge impact though.
Bug: 36249732
Test: run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testBluetoothSharingRestriction
Test: run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testBluetoothRestriction
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerServiceMigrationTest.java
Change-Id: I78c4ffbd503c4a10138e8c0862a9f206f24c5631
Merged-in: I78c4ffbd503c4a10138e8c0862a9f206f24c5631
(cherry picked from commit 7f4ad75218)
Only let notification listeners installed in the primary profile
see work profile notification if allowed by policy
Bug: 36657192
Test: runtest systemui-notification
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Change-Id: If719151644380e9162180a24d12f798e42867c0a
(cherry picked from commit 7e4cbadc6a)
Didn't use @remove because java doesn't support two methods differs from
the return type only.
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_unaffiliatedUser
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerPlusProfileOwnerTest
Change-Id: Ic7c7221ef5e680a6765f028c2ab73d4c2f908c58
Fix: 37622682
Now, network logging will show one notification when it is enabled
and one after the next reboot.
Bug: 36254499
Test: CTS Verifier > Managed Provisioning > Device Owner Tests
> Network Logging UI
Change-Id: I60fc64e96ceb0ec0ae7ca832b74ac8b47e581be4
(cherry picked from commit 55dba53ed4)
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
All the trivial cases, plus some fixes to try to
mitigate collisions with the complex ones.
Complex services to follow in another CL,
Bug: 32584866
Test: make framework services
Change-Id: Ie9663600171d8ede11676e9d66f009dbb06def03
In the normal mode when the DO fetches the logs ASAP, there will still be
no more than one last full batch in memory at once. If the DO is too slow,
or the broadcast queue is too crowded we will store up to 5 of them,
discarding older ones when there are more than 5.
Also the batch gets discarded 5 minutes after it has been retrieved or
another more recent batch has been retrieved. Previously the last batch
would stay in memory until the next one is ready. But it seems
unreasonable for the DO to rely on it since there are no guarantees.
This would probably even save some memory under normal conditions on
average.
Bug: 35753013
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testNetworkLoggingWithSingleUser
Change-Id: Ib8e91a98103d804375cb0d7423f93175b4b9bcb6
(cherry picked from commit 48733074d7)
Merged-in: Ib8e91a98103d804375cb0d7423f93175b4b9bcb6
This CL allows code running under the system UID to call
isSecurityLoggingEnabled(), so that Settings can find out whether
logging is on or off.
Bug: 36584321
Test: m RunSettingsRoboTests
Change-Id: Icf8b7d6cef0f4e23f57bcf0498ffdcf124d16d38
Example: If we got a batch with timestamps [1, 4, 8] and an event
with timestamp 7 was delayed and was added to the buffer later,
if we request the next batch starting from timestamp 8 or 9 that
event will be lost.
The last 3 seconds of events are kept and checked against the next
batch.
Test: afw-test-tradefed-ci run afw-do-security-logging
Change-Id: I55727cfc6143c172edc7dabfd995776f9a0f7eab
Bug: 35373582
Bug: 35026180
Bug: 35648675
We already check if the caller is a DO, PO, or a delegate in
enforceCanManageScope, the additional call to
getActiveAdminForCallerLocked makes this function inaccessible to
delegate applications and was removed.
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegation
Change-Id: I5df0f19a017a3b6e130329940c79b12cbb95ec9e
The intent is for this not to cause any behaviour changes, just to
make it easier to see what is going on with the code.
Permissions are checked in DevicePolicyManagerService. All calls to
CertificateMonitor are privileged.
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I98224087315a62234732f08b53fe91884be86386
Instant Apps have no business being device admins, reject any attempt to
install one as an admin.
Bug: 33387067
Test: None currently -- Instant apps already cannot request becoming
device admin.
Change-Id: Ia1daaff659990ff25f16e8cbad240747b67242e2
