- 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 7f4ad75218bdd3f1bdf9022a146147eae032cc0c)
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 7e4cbadc6a561be62bf3b5e4c949bbb863018cc7)
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 55dba53ed433d713a075ba0de15504a1ed42852b)
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 48733074d7ba80755e40432b7ff02b66e27d3edb)
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
Settings.Secure.DEFAULT_INPUT_METHOD is a misnomer. It does not really
record a permanent default of any sort - it just indicates the currently
chosen IME. Thus, isDefaultInputMethodSetByOwner() should more
appropriately be called isCurrentInputMethodSetByOwner().
Furthermore, it turns out that setting a different IME for a user and
the user's work profile is unsupported. Thus, it is sufficient for the
intended use case to just retrieve the calling user's default IME.
There is no need for a |user| parameter.
Bug: 32692748
Test: unit tests (see DevicePolicyManagerTest.java for invocation)
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: Ia0846d38a1361042429dae7430a8b055575ef2e0
With this API, the system can determine whether a CA cert was
installed by the user or the user's DO/PO.
Bug: 32692748
Test: unit tests (see DevicePolicyManagerTest.java for invocation)
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I3bcae5ac18ec2b110154184fc515df804fd73da6
Adapts all notifications used by system services to use channels.
Channels are initialized by SystemServer after the NotificationService
has started.
Test: runtest systemui-notification
Change-Id: I25c45293b786adb57787aeab4c2613c9d7c89dab
Both inherit from package private BaseParceledListSlice.
This is still bad, but it's not as bad. The existing code that uses
this can just do Foo.bar().getList() now instead of having to marshal
to and from an oddball type at either end as well.
In the longer term ParceledListSlice<> should be eliminated, but it's
not clear how far into the future that is going to happen.
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: runtest -x core/tests/coretests/src/android/content/pm/ParceledListSliceTest.java
Change-Id: Ie69b96b5215d6e04990f6d31345772cdfee21d78
So it can be sent from devicepolicymanager (system_server) to keychain
(a system_app) without waiting on the response and having to do
everything in a background thread.
Side-effect: the regular keychain => app callback is slightly more
efficient now too. in case anyone particularly needs blazing fast
private key user selections.
Fix: 35675253
Test: cts-tradefed run cts --abi=arm64-v8a --skip-device-info --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement' </dev/null 2>&1
Change-Id: I6e9d96ca3c42e6489d879d8cfb0507eb94838bf1
DPMS#setDelegatedScopes generally enforces the delegate is installed in
the device, but this check should be skipped on DELEGATION_CERT_INSTALL
scopes on pre-N. Additionally the check is also skipped when clearing up
delegations on pre-N. The check was extracted to a separate function for
clarity.
Bug: 35234284
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.ProfileOwnerTestApi23#testDelegatedCertInstaller
Change-Id: Ib723b58243f901af907e368017b1ae0bb101360d
They were all broken in that they returned profile admins for parent
queries even when they clearly shouldn't.
Examples:
- disable unredacted notifications
- disable fingerprint
This doesn't seem to have been tested beyond the bare basics of one
user with one device admin. Added some reasonable coverage. It could
still do with more.
Test: make RunSettingsLibRoboTests
Bug: 34929375
Change-Id: I1b0e986056ffa62d47091c0010977ac810ebd690
The previous change was reverted as it broke work profile provisioning.
Clearing binder calling identity before calling into settings provider
should fix the issue.
Test: runtest managed-provisioning
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: Manually tested that work profile is inflated with expected values
of install_non_market_apps
Bug: 33947615
Bug: 35590590
Change-Id: I3c31a73fef0c25c0e682e18f637272adad39b28d
This reverts commit 2e7d6d64b9b16ea27634bc0e8843717a465142b4.
Bug: 35590590
Fix: 35590106
Test: runtest managed-provisioning
Test: manual verified that work profile can be inflated
Change-Id: Ie780b94053e65bca2f96b32055937c0c9e8beae8
Iterating over ArraySet using iterators is still more efficient than
first calling ArraySet#toArray and then iterating over the array.
Test: Minor optimization. make and existing tests should suffice.
Change-Id: Ifc282bfca98cf89b047dddddd78a6de020f27381
Starting from O, install_non_market_apps is deprecated and will not be
checked by the package installer. Device admin apps should be using the
user restriction instead.
Since on managed profiles, the default value blocked install from
unknown sources, the system will set the user restriction on behalf of
the profile owners (if the profile has one).
For non-managed profiles, the user had access to the settings to change
the value of install_non_market_apps. So going forward, any request to
change it's value by dpm#setSecureSetting in such users is going to be
ignored.
Test: Manually tested that:
1. For a profile with PO, when install_non_market_apps was set to 0,
user restriction is set on upgrade
2. For a profile with PO, when install_non_market_apps was set to 1,
user restriction is not set on upgrade
3. After upgrade, newly created managed profiles with PO have user
restriction set
Bug: 33947615
Change-Id: I063e9ee608b52086ffdf8ed2b24e2928574c58cd
We are not moving the restriction from system to the DO in the end.
clearDeviceOwnerUserRestrictionLocked becomes the permanent solution
for DeviceOwner CTS. Looks like no one setting DISALLOW_ADD_USER
directly in UserManager except DO/PO, and so remove it when DO is
clear
Change-Id: I235bebebd02b5e0d9883eea6dd3a4e49b40fe043
Fix: 33476323
Test: runtest frameworks-services -c com.android.server.devicepolicy.DevicePolicyManagerTest
With this API, the system can determine whether a user's default
IME was set by the user or the user's DO/PO.
Bug: 32692748
Test: DPMS unit tests and CTS CtsDevicePolicyManagerTestCases
Change-Id: Ibd703ff5c9e4c072599ad8d6023c94a97d728109
