Service requests can interrupt node prefetching
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
Loading
Please register or sign in to comment