Test cases:
- DO
- Verify disabled for entire device
- Verify still disabled after restart
- Verify no longer disabled when DO is removed
- COPE
- parent
- Verify disabled for entire device
- Verify still disabled after restart
- Verify no longer disabled when COPE PO is removed
- not-parent
- Verify disabled for user
- Verify disabled after restart
- Verify disabled when PO is removed
Bug: 217558483
Test: DevicePolicyManagerTest
OrgOwnedProfileOwnerTest#testScreenCaptureDisabled
ScreenCaptureDisabledTest
Change-Id: I977eb18619da46e1cfc5d0a8d351ea80d3ea7205
OEM can set the config in config.xml to enable / disable enhanced
confirmation mode.
And now we only allow apps with manage appops permission to read
ACCESS_RESTRICTED_SETTINGS op, so bad apps cannot know if the app is
in restricted setting mode
Bug: 217711280
Bug: 217709978
Test: atest AppOpsTest#testRestrictedSettingsOpsRead
Test: With OEM config on, accessibility page for unknown source app is
disabled by default.
Test: With OEM config off, accessibility page for unknown source app is
not disabled.
Change-Id: I6da408306ae43972b7af81c0a3c91bf95e9d6993
Change-Id: I9b79c2edb1341246e75c0d495e3158d370cd7d22
Also, add ability to pass in null to invalidateHomeTaskSnapshot
if the correct permissions are held, so that System UI does not
need to IPC to Launcher to ask it to invalidate itself.
Fixes: 229191103
Test: atest SystemUITests
Test: wake and unlock, note no double launcher
Change-Id: I0c547639979460b3a85b0ef0a8bbf760d60054cb
Add a target for tablets that we can point to in order to run tests
during pre and post-submit.
Test: local atest
Bug: 228851008
Change-Id: Ie0a1186cc97388c1b9c282c81e8bfcab5eec814b
This is a follow up CL to our previuos CL [1], which enabled
AccessibilityService to use a subset of InputConnection APIs.
In that CL we have reused existing AIDL interfaces that were designed
and maintained for IMEs for simplicity, where a non trivial amount of
unnecessary IPC endpoints were included.
From the security and maintainability viewpoints, however, exposing
unnecessary IPC endpoints is discouraged in general. To address such
concerns this CL introduces a set of dedicated IPC definitions for
A11yIME so that we do not need to reuse IPCs for IMEs.
This CL also stops passing InputBinding object to A11yIME process as
it contains IInputContext Binder Proxy, which can still be used to
directly invoke fallback InputConnection. This is doable now because
A11yIME no longer relies on fallback InputConnection [2].
This CL is should not have any observable changes in the semantics.
End-to-end CTS tests guarantee that everything is still working as
intended now and in the future.
[1]: Ia651a811093a939d00c081be1961e24ed3ad0356
fb17e5ae7a
[2]: I2af3cd50444d8ddf25aa0f6479238156914e6fff
dc635efb68
Fix: 215633021
Fix: 215636776
Test: atest CtsInputMethodTestCases:AccessibilityInputMethodTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityInputConnectionTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityImeTest
Change-Id: I5ff2e804cbcf90828370a0612ff54111130bdff4
This will be used to let the application thread
know whether or not to block for network rules to
be updated when coming to the foreground.
Bug: 226299593
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I9bff481a0026fb57af8dbee580e617c8410f9ebe
Merged-In: I9bff481a0026fb57af8dbee580e617c8410f9ebe
It's possible for an app to come to the TOP state before
the oomAdj computation is done and we cannot wait for
oomAdj computation to complete and then inform NPMS about
the state change. So, inform NPMS early about the state
change when we know the app is going to the TOP state.
Bug: 226299593
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I5d582618652cead179c419f7fe084283dd89d514
Merged-In: I5d582618652cead179c419f7fe084283dd89d514
When we know that an app moved to a procstate that is considered
an interaction event, the app will not be in idle state. So, avoid
calling into UsageStatsService for idle state in this case.
Bug: 209338078
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I5648db595d2fd10a151da13e472fd905bcafe182
Merged-In: I5648db595d2fd10a151da13e472fd905bcafe182
Update FLAG_ONLY_ALERT_ONCE docs to match implementation
from Android P and onwards.
Bug: 222328375
Test: atest BuzzBeepBlinkTest
Change-Id: Ic058b8265551362b04b9cd0363e43a4c08ecd736
We read the wallpaper within the synchronized block, this is a long time
operation, might block the other thread who is going to obtain the lock.
So we have to move the operation beyond the synchronized block.
Bug: 228435216
Test: atest WallpaperManagerTest#testPeekWallpaperNotBlockingOtherThread
Change-Id: Ic2a947b473710ffe68db436586769858950588a4
We initially were using PACKAGE_USAGE_STATS permission to guard
the API BroadcastOptions.recordResponseEventWhileInBackground()
but changed it's implementation to use the new
ACCESS_BROADCAST_RESPONSE_STATS permission later but didn't update
the annotation to specify the new permission.
Bug: 228894230
Test: treehugger
Change-Id: I5142e2d2f754e8014c0c291d56b5ec2254449e77
Notification API downscales oversized icons in all formats except in MessagingStyle. This seems to be an oversight that can cause massive memory usage.
This downscales avatars to a reasonable size if they're too big.
Bug:193720474
Bug:221890932
Test: atest NotificationTest
Built a test app with 4000x4000 avatar icon.
Memory usage went from 250MB to ~170KB per notification.
Change-Id: I35377cdb5d61ee6e23fccc2bffb5d3aec6ca2b7d
Even if the app's notifications are disabled.
Test: NotificationManagerServiceTest
Test: NotificationInfoTest
Test: manually call device
Fixes: 227456870
Change-Id: Ib218e57d585a6066ddbc713d2d3a8445ac959ad2
