This is the re-merging of ag/12923546 (where most of that original
message is posted below), which includes various bug fixes.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.
On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.
When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches.
We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330
Messages should be added to PrivateHandler and
mPendingFindNodeIdMessages at the same time to avoid a race condition
where we try removing a message from the handler before it's actually
enqueued. This was causing double recycling
UiAutomation does't require a main thread, so getMainLooper may
return null. In this case, instead of posting to the main looper,
we cache nodes on the binder thread (which is our ultimate goal).
Added tests to verify AccessibilityInteractionController interactions
Test: atest AccessibilityInteractionControllerNodeRequestsTest,
FrameworksServicesTests FrameworksCoreTests, CtsAccessibility, Manual
testing
Bug: b/176195360, b/175877007, b/175884343, b/178726546, b/175832139,
b/176195505, b/181701570
Change-Id: I66902f995f33f0236003faa439925ec72fcf6952
Test: Manually tested on device via SurfaceControlViewHost.setView()->WindowlessWindowManager.addToDisplay()
Bug: b/171914211 (for original change on rvc-wear-dev)
Change-Id: I474949b53c570e01ba678e088a5001618ff0b26e
(cherry picked from commit 9eec64f031a1a1992461251ed3451fc48fd59224)
Describe when current and max should be used explicitly, to prevent app developers from mis-using getMaximumWindowMetrics in multiwindow modes.
Bug: 175209525
Change-Id: I953917f088325a6a029691cdaafddb94809dde05
Test: manual
When a frame is determined to be caused by an input event, it will be
labeled with a specific input event id. The newly added entity,
InputEventAssigner, is responsible for determining which input
event we should use.
For regular ACTION_MOVE events, we will take the latest input event as
the event that has caused the frame. For the initial gesture
(ACTION_DOWN), we will use the first event (the ACTION_DOWN itself) to
figure out the down latency. This will allow us to split up 'down' and
'scroll' latencies.
Bug: 169866723
Test: looked at the data printed locally to logcat
Test: atest InputTests
Change-Id: I8513a36960e5d652d07655d1267e758d0c59ced7
1. Only send navigation bar target when:
- The transitition is app launch
- In gesture navigation bar mode
- The navigation bar is not controlled by fixed rotation or recents
2. Add a windowType field to RemoteAnimationTarget so that the remote
clients could use this to find the non-app window they want.
Bug: 139273001
Test: atest RemoteAnimationControllerTest
Change-Id: I7003011351913b040b47e6fb567eedb4baf34a55
--Ported SKSL based stretch shader from OpenGL prototype
--Hooked up the stretch APIs in RenderNode to the stretch
shader.
--Updated RenderNode layer logic to promote the RenderNode to
a layer if there is a stretch to be applied to it in order
to feed the layer as input to the stretch shader
Bug: 179047472
Test: builds + sample overscroll stretches + updated CTS test
Change-Id: I744ff70099fe251ce07f23d067bf13444a468c08
* Old codepath is maintained; switch with config_showNotificationGroupCountInExpander.
* Use the default expander colors for low priority header.
* Uses the correct color for the old group overflow.
* Fixes the header view to correctly accomodates growing expander.
Bug: 181048615
Test: manual, visual inspection of groups and notification types that use headers
Change-Id: Ia314a6028645016df39d3e948fdc4eb194ed9ff2
This reverts commit f94c85b130.
Reason for revert: Causing app crashes and runtime restarts in tests. See b/181701570 for details.
Change-Id: I2b5f7b80f07f5d8f564acdf20fcdb1e9b5b9da19
1. Update UiTranslationManager APIs to use ActivityId parameter
2. Keep old APIs definition until AiAi is ready for new APIs.
Bug: 177789967
Test: manual. Local add test app in allow list, and get token from local
content capture service and use it in UiTranslationManager api.
Change-Id: I96aa5704600fd9b81eff7a2f42eefe78a43112da
Organize the code so that it is easier to read.
Add lots of display-related tests.
Test: atest com.android.server.display
Bug: 168208162
Change-Id: Iacdb9da032fe53d6d586dd33a4f0720769994d8c
A new hidden flag is introduced to layout params to let system UI
components get the global insets state regardless of the z-order. That
is necessary to let components like power menu and system UI dialog.
Test: atest InsetsStateControllerTest
Bug: 178420426
Bug: 178115003
Change-Id: Ib103639ff00bf15919796788c0ba323aba0b4b4a
In order to support auto translation, we need to give information to
content capture service to let the app can use this information to
find the Activity which needed to be translated.
It's not safe to provide an activity token to the client app directly
even if it is a privilege app. They can use this activity token to
access many activity/windows related functions. We create a new token
for use for content capture and translation. This token will be used
get the target Activity for translation new APIs.
This change focuses on the Content capture API change, the API change
about translation will be done in the next change,
Bug: 177789967
Test: manual. Make sure cc service can get the information.
Test: atest android.view.contentcapture.ContentCaptureContextTest
Test: atest CtsContentCaptureServiceTestCases
Change-Id: Ife8096a8bd1e71ce4e686d95043e347222ad7ee6
Read the selection timeout value from ViewConfiguration,
ViewConfiguration is statically configurable by the OEM. OEMs can
set the value which works on their device before shipping it.
After privacy sync, we can make the selection context size
configurable by DeviceConfig but we need to provide a
reasonable upper bound. The value is 240 after experiment.
Bug: 169042855
Test: atest CtsTextClassifierTestCases
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest android.widget.TextViewActivityTest
Test: manual. Changes values by command and checks the values.
Change-Id: I59346fdc3b482bca586c13ba6c653d1e9b593922
This is the re-merging of ag/12923546 (where most of that original
message is posted below), which includes various bug fixes.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.
On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.
When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches.
We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330
UiAutomation does't require a main thread, so getMainLooper may
return null. In this case, instead of posting to the main looper,
we cache nodes on the binder thread (which is our ultimate goal
once b/180957109 is fixed).
Added tests to verify AccessibilityInteractionController interactions
Test: atest AccessibilityInteractionControllerNodeRequestsTest,
FrameworksServicesTests FrameworksCoreTests, CtsAccessibility, Manual
testing
Bug: b/176195360, b/175877007, b/175884343, b/178726546, b/175832139,
b/176195505
Change-Id: I346a3f40c84c6697b8a1e1d84a636eada655b984
This CL exposes an API to let apps know when the blur has been enabled
or disabled dynamically.
This could be due to battery saving mode turned on, tunnel mode being
used, minimal post processing requested, etc.
This adds a WindowManager.addCrossWindowBlurEnabledListener, which allows
apps to add/remove a listener for blur enabled state changes. The
listeners are registered in a CrossWindowBlurListeners, which receives
updates from WindowManagerService when blurEnabled changes.
CrossWindowBlurListeners only registers a remote listener if the client
initializes it. I.e. if the app is not interested in blurs, the
CrossWindowBlurListeners won't get initialized and won't register a
remote listener.
WindowManagerService holds a RemoteCallbackList, which holds listeners
for each client process and notifies them when there are updates. If any
of the listeners' process dies, the entry is removed from the list.
Bug: 177524486
Test: m
CTS-Coverage-Bug: 179990440
Change-Id: I3fe8f2d2008171d6b069e8ee6f3b47e5b5d60cfa
