Common Criteria mode puts device into a state where certain
funtionalities are tuned or turned on to meet the higher security
requirement from Common Criteria certification. Device Owner
can use the new device policy API to toggle Common Criteria mode.
Bug: 137937540
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest SettingsProviderTest
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testCommonCriteriaMode
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testCommonCriteriaMode
Change-Id: If07c053437e980ed3317d3838cc74e5bfd44efce
Also default the flag to allow more notifications into that
space to on.
Test: atest
Bug: 137397357
Change-Id: I225f462879bdb28411cc631a3e259b4c71ba7394
The base APK is loaded during normal execution even when isolated splits
are requested. This preserves that behavior during instrumented tests,
which previously skipped the base APK (causing class loading errors).
Test: tested on device with a trivial automated instrumented test
Bug: 146183755
Change-Id: Ia54072ee91b7c06cb4a787a8954ad2e69b322cac
At every filtering level (uid -> packageName -> featureId -> op) it is possible that lower level filter would filter out all available data. In such case higher level entity should also be removed.
Test: manual verification
Change-Id: Ibd1b08da5b501c1ecabac7158d70414d955203d7
When a launched application doesn't occupy the entire screen space,
there is a mismatch between the configuration of the process and the
configuration of activities. This leads to compatibility issues with
apps that don't expect this, read display metrics from Application
resources and try to apply them in activities.
The platform may apply a compatibility mode, in which the process
configuration will match the config of the top running activity. This
means that the process configuration may change and runtime and
result in display adjustments that are different from the default
values. This CL propagates resource configuration updates even for
default display to make sure that the config changes are reflected
for non-activity contexts.
Test: CtsWindowManagerDeviceTestCases:AppConfigurationTests
Change-Id: I91cadc83a82a3be8c8dee810bbd1aa97cbe4e97f
Round one - needs polish, and actions may be added or removed
in the future, and demote isn't working yet.
Bug: 137397357
Test: atest
Change-Id: Ia52598bec58fc54b8bde29168cd419a24d1e4dab
Make isOrganizationOwnedDeviceWithManagedProfile a public method, as
there is no reason to keep this information hidden from apps.
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testIsDeviceOrganizationOwnedWithManagedProfile
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedProfileOwnerTest#testIsDeviceOrganizationOwnedWithManagedProfile
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedDeviceOwnerTest#testIsDeviceOrganizationOwnedWithManagedProfile
Bug: 143518237
Bug: 144978467
Bug: 147340575
Bug: 146123237
Change-Id: Iab45f20c9150a6b8bd48eea610484f36f199d3d7
The response may be old and incorrect when leave the app then go back. To
avoid using the wrong response, going back to the app will trigger a new
request.
Bug: 146903532
Test: atest CtsAutoFillServiceTestCases
Change-Id: Ibab426183d39e3c51fb0f89ec6ba6ea48012b6a8
Implementing the new API for A11y services to take the screenshot
of the specified display.
Bitmap takeScreenshot(int displayId)
1. The main codes is moved from the UiAutomationConnection class and
let the UiAutomation change to use this API.
2. Add a capability at metadata to check whether the A11y services could use this
API or not.
3. This API is a async one for A11y services, but is a sync one for
UiAutomation.
Bug: 10931661
Test: a11y CTS & unit tests
Change-Id: I478bd93c60d4742bef20ae0e423ca9de1bda55d2
This allows apps to get the string used so they can properly instruct
the user on how to grant a background permission.
Test: Manual, multiple languages
Bug: 147440267
Change-Id: Ibdc6563e85cae930c25a9338513f747440fee8b4
- Only allow delayed locking for the explicit call, stopUserWithDelayedLocking()
or for implicit user stopping caused by user switching.
- All other explicit user stopping should immediately lock the user. This allows
immediate locking from component like DevicePolicy.
- Product still should enable delayed locking explicitly and if it is disabled,
IActivityManager.stopUserWithDelayedLocking will behave the same with
IActivityManager.stopUser.
- Once user is stopped in delayed locking mode, one of following steps can completely
lock the user (this is not a complete list):
1. User is asked to be stopped with IActivityManager.stopUser call.
2. User is restarted through IActivityManager.restartUserInBackground call.
3. UserManager.evictCredentialEncryptyionKey (involves restartUserInBackground call)
4. When user is removed (involves IActivityManager.stopUser call).
Bug: 131757355
Test: run unit tests
check user locking in car device where delayed locking is enabled.
Change-Id: I663ffde3a5b74738a6f59b4282ff562146f22662
Currently we have no method of telling transports that we have
attempted to make a Key/Value backup, but there was no data to
back up. This means that for apps with K/V backups their last
backup timestamp becomes older and older causing confusion for
users about whether the app data hasn't changed or whether the
app is failing to back up.
By introducing this flag we create a signal for the framework
to tell transports that, if there was any changed data, the
data would have been backed up, but the apps has not indicated
any changes have been made. This allows us to provide a UX
based on last non-erroring attempt rather than last data
change.
Bug: 147481066
Test: No code introduced in the CL.
Change-Id: Id832c7173da6341c6dc7b77fb72c289f2e1da624
The service is already registered in ServiceManager. It needs to be
accessible from SystemServiceRegistry so that other mainline modules
can communicate with it.
Bug: 147255753
Test: Dependent CLs using the service
Change-Id: I940c62064466c3b3b8d2a195b810e90eaade7e6c
Merged-In: I940c62064466c3b3b8d2a195b810e90eaade7e6c
Forced was meant to mean "forced by the user." Renaming the constant and
clarifying the comment so it doesn't get used incorrectly. Also
introducing a "forced by the system" constant and fixing the code so the
correct reason is used.
Bug: 145551233
Test: atest AppIdleHistoryTests
Test: atest AppStandbyControllerTests
Test: atest UsageStatsTest
Change-Id: I0d258d83141670728b758a3ef0056b19fde4a88b
Restrict adding a managed profile when the device has a device owner.
This mode is no longer supported, in favour of Corporate Owned,
Personally Enabled mode (Organization-Owned device with Managed Profile).
The restriction on adding managed profiles is now added by default when
a device owner is set, and is removed when the device owner is removed,
to avoid other system copoments from creating a managed profile when
there's a device owner.
Additionally, the method for checking whether pre-provisioning
conditions are met has been modified to return an error if the
restriction is set.
Bug: 145271440
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Change-Id: Ife25f4e2faffe84d85ab7786407c14997b4cf069
