Paves way for synthetic password flow: Two notable changes:
1. when unify/un-unify work challenges, provide the old work profile password.
2. when clearing lock, supply old credentials.
Test: Unit test to be added in a follow up CL.
Bug: 33126414
Change-Id: I2a9553c5e7cc701338436e99e5a1289cebd1eda9
Mentioned that in the documentation, cleaned up the code
a bit and added unit tests
Bug: 34614754
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Change-Id: I91232bbe494398015094ab977c6a2adce339811f
Note DPM.wipeData() on a secondary user is now blocking, just like
it's been always blocking on the primary user.
Test: Manually tested wipeData() with ApiDemos, both on 1) the primary user,
2) a secondary user and 3) work profile.
Test: adb shell am instrument -e class com.android.server.devicepolicy.DevicePolicyManagerTest -w com.android.frameworks.servicestests
Bug 30681079
Change-Id: Ia832bed0f22396998d6307ab46e262dae9463838
Merged-in: Ia832bed0f22396998d6307ab46e262dae9463838
(cherry picked from commit efdec8f5688ce6b0a287eddb6d5dad93ffa0e1ee)
Add note on DPM#setDelegatedScopes documentation regarding the
broadcast sent to the delegate package to notify its new scopes; and
change the admin ComponentName annotation to @Nullable in
DPM#getDelegatedScopes.
Bug: 33099995
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegation
Change-Id: I28fe3a631c05a9e6b8dae766ce6c42881f2e3a00
Change DPMS to call Intent#putStringArrayListExtra to ensure the extra
is sent as an array list of strings.
Bug: 33099995
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegation
Change-Id: I1466fb457e34adbfb7704320c021210c1569f55f
Note DPM.wipeData() on a secondary user is now blocking, just like
it's been always blocking on the primary user.
Test: Manually tested wipeData() with ApiDemos, both on 1) the primary user,
2) a secondary user and 3) work profile.
Test: adb shell am instrument -e class com.android.server.devicepolicy.DevicePolicyManagerTest -w com.android.frameworks.servicestests
Bug 30681079
Change-Id: Ia832bed0f22396998d6307ab46e262dae9463838
Merged-in: Ib97a92a6af87a5589d2643b9ae0522395735e1a5
The recent addition of DPM API access delegation introduced a bug in
this method. When a system app (UID 1000) called the method, it would
crash.
Bug: 34760123
Test: DPM unit tests
Change-Id: I69390ca30270d64a4d28a74c13a7679f14a62959
Allow device owners and profile owners on a user
to communicate with each other, rather than restricting
it to device owners and managed profile owners as it is
at the moment
Bug: 34429083
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Test: cts-tradefed run cts -a armeabi-v7a --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerPlusManagedProfileTest
Change-Id: I81561a9838c3ccb623354a1b718da2fc6a5af1fe
Handler#sendMessageDelayed() to a wakeful alarm
Messages sent with Handler#sendMessageDelayed() didn't get delivered
until the device woke up after being idle, which resulted in
potentially very long windows of logs accumulation and highly possible
network log loss from before the device becaming idle.
Bug: 34157435
Test: manual with decreased timeout over a few timeout iterations
Change-Id: I22d9cc743acb1a478d2da5407c5718e7f95e89cb
Handler#sendMessageDelayed() to a wakeful alarm
Messages sent with Handler#sendMessageDelayed() didn't get delivered
until the device woke up after being idle, which resulted in
potentially very long windows of logs accumulation and highly possible
network log loss from before the device becaming idle.
Bug: 34157435
Test: manual with decreased timeout over a few timeout iterations
Change-Id: I50b29b9f132856a629e28f46c022f21976bd92fb
The new DPM.createAdminSupportIntent() returns an intent that shows the
"This action was disabled by your admin"-dialog from settings.
This enables apps to inform the user about the cause of restricted
functionality.
A new extra for the intent allows to specialize the dialog for different
restricted features, instead of a generic message for all features.
Bug: 31215663
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Change-Id: I3de7aeec0f88b8f013a63957aec803cd123fbedc
Implement the permission grant, package access, enable system app, and
keep uninstalled packages delegation scope APIs in the
DevicePolicyManagerService.
This feature gives a device owner or profile owner the ability to
delegate some of its privileges to another application.
Bug: 33105287, 33105284, 33105719
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegation
Change-Id: I50d2903eb73ae7844ec1f6fe07e41101ea2760ea
Implement the uninstall blocker delegation scope API in
DevicePolicyManagerSercice.
This feature gives a device owner or profile owner the ability to
delegate some of its privileges to another application.
Bug: 33105718
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegation
Change-Id: Ieb347ce3fb6219fe7f04cafbcd1e6b7359b31a10
If the device or profile owner have set a max password failed
attempts policy, the device or profile should be wiped even if
DISALLOW_FACTORY_RESET / DISALLOW_REMOVE_USER /
DISALLOW_REMOVE_MANAGED_PROFILE was set by that admin. However
it should still fail if another device admin set the policy - this
is in line with what wipeData() does at the moment.
Bug: 34450538
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerPlusManagedProfileTest#testWipeData
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.ManagedProfileTest#testWipeData
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testDisallowFactoryReset
Change-Id: Ifac240692ce74432f7b57f3dfbbbac2a7282297b
- DEVICE_OWNER_CHANGED is an event that could happen maximum of 2 times
after device factory reset. The event rarely
happens, and it shouldn't affect any system health
Fix: 34446573
Test: adb shell am instrument -w -e class
com.android.server.devicepolicy.DevicePolicyManagerTest
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Ic1af2016f590e1200bb3e56f63caa0e0b12f71f8
The DevicePolicyManagerService currently supports delegation of
certificate installation and application restriction management, both
of which are individually handled by DPMS.
Upcoming framework features will add four more delegation types,
namely: block uninstall; app permission management; app access
management; and system app enabler. At this moment it makes sense to
refactor the underlying delegation system in DPMS so that current and
future delegates can be handled in a more generic way.
Bug: 33099995
Test: DPMS unit tests
Change-Id: I9e350143572c6690febdd59d1ed5149af8ee4388
If the device owner has set DISALLOW_REMOVE_MANAGED_PROFILE,
and there is already a managed profile:
it should be allowed to provision a new managed profile by
deleting the old one.
Test: adb shell am instrument -e class
com.android.server.devicepolicy.DevicePolicyManagerTest
-w
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
BUG:34116228
Change-Id: I9e6f39924107aee40b57d22e638487a1ea3132de
We add a variant of notifyPendingSystemUpdate method which takes an
additional isSecurityPatch boolean flag. This information, if available,
will be persisted and available to device and profile owners when they
call getPendingSystemUpdate method.
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases -t com.google.android.gts.devicepolicy.DeviceOwnerTest#testPendingSystemUpdate
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases -t com.google.android.gts.devicepolicy.ManagedProfileTest#testPendingSystemUpdate
Bug: 33102479
Bug: 30961046
Change-Id: If3f1b765bb18a359836ac43ac9a0a9f29e9f8428
To inform the user which apps were granted permissions by the admin,
the Settings app needs to access this information without being a DO/PO.
Bug: 32692748
Test: FrameworksServicesTests unit test
Change-Id: I3770ec6343b85be9c6f7655675ed6db5cb50612c
1) Started returning the default value for getLong() on SystemProperties mock
2) Added a test that the minimum timeout cannot be changed using a system
property on non-debuggable builds
3) Added new within range test for completeness.
4) Started using TimeUnit instead of ms constants.
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Bug: 34317979
Change-Id: I0409451ae39e74ec3d96a098042302291ec3408f
Saving device policy managers settings to clear out
password stats was happening before initializing mAdminList
so could wipe active admins.
Test: manual - flash with N2G05C add google account with dmagent flash wth this fix, check dmagent is still an active admin, reboot check admin is still active.
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Bug: 34277435
Change-Id: I13660b47f30e9aba001eb13f2e457c3b3f36da3e
(cherry picked from commit adbda7474cc1968b66e9948aee566dc346e71340)
Saving device policy managers settings to clear out
password stats was happening before initializing mAdminList
so could wipe active admins.
Test: manual - flash with N2G05C add google account with dmagent flash wth this fix, check dmagent is still an active admin, reboot check admin is still active.
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Bug: 34277435
Change-Id: I13660b47f30e9aba001eb13f2e457c3b3f36da3e
Currently only device owner can set global user restrictions.
With this CL ENSURE_VERIFY_APPS will be global no matter who
enforces it, DO or PO.
To make it possible for system apps to check who enforces a
particular restriction in this case a new API method is added
to UserManager: getUserRestrictionSources which returns a list
of users who enforce the restriction.
Bug:31000521
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.UserRestrictionsTest (ag/1732744)
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/pm/UserRestrictionsUtilsTest.java
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerServiceMigrationTest.java
Test: installed M on a Nexus5x device, created a managed profile with some user restrictions, and checked that after upgrading M->O all restrictions are preserved and split correctly into base, global and local.
Change-Id: I543d3ec9ef0cf2b730da6f7406021c0bba43b785
Currently, those features are available on single user devices only
(since they collect privacy sensitive data device wide). Now making
them available as long as all users are affiliated.
It'll take a certain amount of time between user creation and the DPC
of that new user setting the appropriate affiliation ids. The DO won't
be able to access the logs during that time (and won't get any "logs
ready" callback). Once the affiliation ids are set, if they match,
logs become available again - this includes logs collected while the
user was being setup. Some logs might be lost though if the amount of
data exceeds the internal limit.
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Test: cts-tradefed run cts -a armeabi-v7a --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest
Bug: 32326223
Change-Id: Idfe881dd6497d3ad2bead10addfd37b98b8a6e2b
