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
Take advantage of the new authentication flow in LockSettingsService
and allow PO or DO to provision escrow tokens on the device. The
escrow token grants them the ability to change device lockscreen
(if used by DO) or work profile challenge (if used by PO). The
new password reset mechanism is even usable before user unlocks,
and it preserves authentication-bound keys in keystore.
Test: runtest frameworks-services -c com.android.server.SyntheticPasswordTests
Test: runtest frameworks-services -c com.android.server.devicepolicy.DevicePolicyManagerTest
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedDeviceOwnerTest#testResetPasswordWithToken
Bug: 33126620
Change-Id: Iaa684c51946f726cbd909e9ac70ad3e9ca3de1ac
The same application can run as either an instant app or an installed
app. Store this setting per-user instead of based upon the install
location.
Bug: 25119046
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Change-Id: Iff565bb1ac10d631499f0bd0f69b401cb073c10e
To fix the glitch that "kiosk mode" does not persist if device
is rebooted within 10s after addPersistentPreferredActivity is called.
Test: Manual Test
1. Using TestDPC to start kisok mode, reboot right away.
Observed that TestDPC is launched in kiosk mode.
2. Stop the kiosk mode, reboot without 10s.
Kisok mode is stopped.
Fix: 28169791
Change-Id: I555fc18efe86380f2e028b698c2bdb01017bf9f5
