* DELEGATION_NETWORK_LOGGING
Allow delegated apps to control and retrieve network logging
* DELEGATION_CERT_SELECTION
Allow delegated apps to automatically select client certificates for apps.
* DELEGATION_PACKAGE_INSTALLATION
Allow delegated apps to silently install packages.
Also introduce DelegatedAdminReceiver which is analogue of the existing
DeviceAdminReceiver and enables delegated apps to receive system callbacks
related to their delegated capabilities.
This CL introduces the three new delegation scopes as well as some
implementations changes required to support these three delegations.
it also implements the actual logic around DELEGATION_NETWORK_LOGGING
and DELEGATION_CERT_SELECTION. Handling DELEGATION_PACKAGE_INSTALLATION
will be implmented in a subseqent CL.
Bug: 112982695
Test: atest com.android.cts.devicepolicy.MixedProfileOwnerTest#testDelegation
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegation
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testDelegation
Test: Manual with TestDPC-replica
Change-Id: I508fdda0572041cf121d0e297c93d51e981545e3
Add system APIs isManagedKiosk and isUnattendedManagedKiosk. These will
be defined in the CDD.
The intention is to have privacy and security-approved definitions that
future features (removing user consent dialogs, stronger APIs) can use
specifically for publicly-accessible dedicated devices.
We use 'kiosk' rather than 'publicly-accessible dedicated device' for
ease-of-use, which is actually consistent with ChromeOS.
Bug: 111384878
Test: Each use will have its own CTS tests. The definitions themselves
will be in CDD. Currently tested by calling the methods in TestDPC.
Change-Id: If080a3b9dae285bc28823e6004750908009130d2
When setting a password from DPM.resetPassword(), the actual quality of the
password was not passed to LockSettingsService (instead, the minimum required
quality was passed which is often UNSPECIFIED). As a result, during FRP we
would see inconsistent state and skip it.
Bug: 110172241
Test: Set credential via DPM.resetPassword(), factory reset device to trigger FRP, verify FRP shows.
Change-Id: I54376f60ac53451ace22965d331b47cd8c2e614e
Implement connectivity check to DNS-over-TLS servers, checking that the
RFC-defined port on the host is reachable and a TLS handshake can be
performed.
Bug: 112982691
Test: atest com.android.cts.devicepolicy.DeviceOwnerTest#testPrivateDnsPolicy
Change-Id: I1eb4ec201d7e096b969b7bc2bcba271f99de2d2f
Settings wants to know if there is currently any package that is allowed
for cross profile calendar by PO.
The UI is added in work account settings, which actually runs
in primary user, and we can't call the public
getCrossProfileCalendarPakcages(work_user_admin) from primary user.
So we need to add this hidden API.
Bug: b/117976974
Test: make ROBOTEST_FILTER=CrossProfileCalendarPreferenceControllerTest -j40 RunSettingsRoboTests
Change-Id: I3df29a25a7826639828041b47dcfb7dcf086c411
Adding API to install a system update from a file on the device.
Test: manual in TestDPC, CTS tests for negative cases: atest com.android.cts.devicepolicy.DeviceOwnerTest#testInstallUpdate
Fixes: 116511569
Change-Id: I34b5c6344301a9d2d64c98dedc4ed5e4a75c57d1
A small clean-up CL to follow-up on two comments from the original
review:
* Remove the new permission from privapp-permissions-platform.xml as it
is a signature-level permission, not a privileged premission, and as
such does not need to be in that file.
* Do not store the grant state if it's set to false - since the
de-serialization code will only care if there's a "true" value stored.
Bug: 111335970
Test: Manual
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest com.android.cts.devicepolicy.MixedProfileOwnerTest#testKeyManagement
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testKeyManagement
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testDeviceIdAttestationForProfileOwner
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testDelegatedCertInstallerDeviceIdAttestation
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegatedCertInstallerDeviceIdAttestation
Change-Id: I8b570220f5652846fccc53b5e4daaa57f89eb824
In order to allow inclusion of device identifiers in the key attestation
record generated by the profile owner, the platform needs an explicit
signal that it is OK for the profile owner to access those identifiers.
Add a system-privileged method to the DevicePolicyManager that allows
system applications, as well as Managed Provisioning to indicate that the
profile owner may access those identifiers.
In the DevicePolicyManagerService the following has changed:
* The OwnerInfo now contains a flag indicating whether the profile owner
was granted access to the device identifiers or not.
* The permission check for use of the Device ID Attestation flags in
generateKeyPair has been adjusted to allow profile owner (or its
delegate) to use them, if device identifiers access has been granted.
* A couple of utility methods have been added to ease checking of
profile owner presence for a user and whether the profile owner can
access device identifiers.
Additionally, a new adb command has been added to give this grant to an
existing profile owner for testing purposes.
Bug: 111335970
Test: Manual, using TestDPC + ADB command.
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: Additional CTS tests, see cts change in the same topic.
Change-Id: I05f2323d5edacd774cd3ce082ee9c551100f4afd
When native layer reports onDnsEvent, netId, eventType and
returnCode are available only in NetdEventListenerService, but
not for the clients who register event on it.
Thus, extend the callback to give clients more detail on the
network the look up was performed on and the result of the
lookup.
Bug: 113916551
Test: 1. runtest frameworks-net
2. runtest frameworks-services -c com.android.server. \
net.watchlist.NetworkWatchlistServiceTests
Change-Id: If7beecea50e1baf18cb5c6775ad3ecb1a60b312a
When device identifier access was moved from a runtime permission to a
privileged permission device and profile owner access regressed by no longer
requiring consent to access the identifiers. With this change device and
profile owners will still need to have the READ_PHONE_STATE permission to
access identifiers.
Bug: 117611604
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases \
-t com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases \
-t com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers
Change-Id: Ib2d86440c531eab075d010de183ccfa45c2443e5
A new API for setting the Private DNS settings value programatically via
the DevicePolicyManager.
Since there are two separate settings for Private DNS, and the value
provided for the hostname needs to be validated, a new
DevicePolicyManager API is introduced.
Only a Device Policy Client in Device Owner mode may change these
settings.
The DPC may additionally set a user restriction (added in a separate CL)
to prevent the user from changing Private DNS settings.
Bug: 112982691
Test: atest com.android.cts.devicepolicy.DeviceOwnerTest#testPrivateDnsPolicy
Change-Id: I566437e4fe10e1346858149120c50b3c20ca073f
Move P APIs out of BaseIDevicePolicyManager.
Bug: 73469681
Test: make -j64 checkbuild
Test: make RunFrameworksServicesRoboTests
Change-Id: Ieffafb5c331b0befed5356f8d45e9ac6e0d81bee
This adds a new framework user restriction that can be used by the DPC
to block installs from unknown sources on all profiles of a device.
Test: Manual test, disallowing installs in TestDPC disables installing
unknown sources apps.
Bug: 111335021
Change-Id: Ib9fb672c5e5dea2ac63bf8cbd1b04484b12b4056
In 534d732e9f274ad3f3e0637b9da963f889309afb, we are restricting privileged apps from silently becoming
Device Admins. Privileged apps can now call the following existing Device Admin APIs provided they have the correct permissions:
1. DevicePolicyManager#resetPassword -> Guarded by android.permission.RESET_PASSWORD
2. DevicePolicyManager#lockNow -> Guarded by android.permission.LOCK_DEVICE
The following existing Device Admin APIs already have alternatives hence no change required:
3. DevicePolicyManager#wipeData -> Send ACTION_FACTORY_RESET broadcast.
Guarded by android.permission.MASTER_CLEAR
4. DevicePolicyManager#setKeyguardDisabledFeatures -> Write '0' to LOCK_SCREEN_ALLOW_PRIVATE_NOTIFICATIONS setting
Guarded by WRITE_SECURE_SETTINGS
Bug: 111153365
Bug: 112601004
Test: Manually tested with dev privileged app
Change-Id: Ia4e1ce9b81756e7f84ed0aa22d97e0b968cd8d89
Add @GuardedBy for simple functions that require locks and have a name in
one of the frameworks naming styles for locks ("^.*(Locked|LPw|LPr|L[a-zA-Z]|UL|AL|NL)$").
Derived by errorprone.
Bug: 73000847
Test: m
Change-Id: If70bb03313388af34d547efca20fb5115de95bf1
If a device admin app targets Android Q or above, and it is not a device
owner or profile owner, throw a SecurityException if it attempts to
control the following policies:
- DeviceAdminInfo.USES_POLICY_DISABLE_CAMERA
- DeviceAdminInfo.USES_POLICY_DISABLE_KEYGUARD_FEATURES
- DeviceAdminInfo.USES_POLICY_EXPIRE_PASSWORD
- DeviceAdminInfo.USES_POLICY_LIMIT_PASSWORD
The set of policies available to a device admin targetting Android P or below is unchanged.
Bug: 111546201
Test: com.android.server.devicepolicy.DevicePolicyManagerTest
Test: com.android.cts.devicepolicy.DeviceAdminHostSideTestApi24
Test: com.android.cts.devicepolicy.DeviceAdminHostSideTestApi29
Test: com.android.cts.devicepolicy.ManagedProfileTest
Change-Id: Idcd0b4b91ad2fa363535c718928d382c7da054d4
Also make the new lib only use system-apis.
This allows mainline module to use the new
RestrictedLockUtilsSettingLib.
Unfortunately the whole RestrictedLockUtils would have caused to much
new system-api. Hence it was split into RestrictedLockUtils and
RestrictedLockUtilsInternal. This caused a lot of trivial code changes.
Bug: 110953302
Test: Built
Change-Id: I693b3bf56f3be71f0790776e3aad5694717786ef
Currently Keyguard uses separate counter for invalid password attempts
that is not persisted and is always initialized to zero after boot,
so if the user made several attempts and rebooted the device, the
device will show more allowed attempts before wipe than actually
available. The counter is also incorrectly reset to zero when
fingerprint is used successfully.
With this CL the same counter is used for that message and for actual
wipe triggering, it is persisted and is not reset upon reboot or
fingerprint authehtication.
Counting failed password attempts should be available in DevicePolicyManager
even without PackageManager.FEATURE_DEVICE_ADMIN.
Test: manual, tried using fingerprint and rebooting.
Bug: 112588257
Merged-In: I1f4012a95c6f6758885206f69e7ebe2c3704a567
Change-Id: I1f4012a95c6f6758885206f69e7ebe2c3704a567
Currently Keyguard uses separate counter for invalid password attempts
that is not persisted and is always initialized to zero after boot,
so if the user made several attempts and rebooted the device, the
device will show more allowed attempts before wipe than actually
available. The counter is also incorrectly reset to zero when
fingerprint is used successfully.
With this CL the same counter is used for that message and for actual
wipe triggering, it is persisted and is not reset upon reboot or
fingerprint authehtication.
Counting failed password attempts should be available in DevicePolicyManager
even without PackageManager.FEATURE_DEVICE_ADMIN.
Test: manual, tried using fingerprint and rebooting.
Bug: 112588257
Change-Id: I1f4012a95c6f6758885206f69e7ebe2c3704a567
Allows for other services like window manager to call uri grants without
holding AM service lock.
Bug: 80414790
Test: Existing tests pass.
Change-Id: Ie5b4ddb19a2cedff09332dbeb56bcd9292fd18ac
