summaryrefslogtreecommitdiff
path: root/libs/ui/DisplayIdentification.cpp
diff options
context:
space:
mode:
author Siarhei Vishniakou <svv@google.com> 2025-01-23 16:27:38 -0800
committer Siarhei Vishniakou <svv@google.com> 2025-01-29 16:16:20 -0800
commit231813376544ba24936bac405fed22967e98eaf3 (patch)
tree765016a1060426e2a9e826e71c34eac8e842b7c9 /libs/ui/DisplayIdentification.cpp
parentd1f563013dfe3a2b5f8b412b9ee19b42a36d5932 (diff)
Ensure canceled touch stream uses previous display id
We are observing inconsistent event streams being sent out of TouchInputMapper. Whenever display id associated with a specific device changes while touch is in progress, the generated ACTION_CANCEL event has the new display id instead of the original one. This causes issues later in the pipeline. In the case when a11y is ON, the events are sent to a11y and get later re-injected into InputDispatcher. The InputDispatcher will not resolve the correct verifier, and as a result will incorrectly reject the event. In this CL, we are storing the previous display id before reconfiguration occurs, and then using this stored display id to abort touches just before reset() is called. In reset(), we are also canceling touches. That behaviour has to be maintained, since reset() is a public API that can be called from other places. Bug: 378308551 Test: TEST=inputflinger_tests; m $TEST && $ANDROID_HOST_OUT/nativetest64/$TEST/$TEST --gtest_filter="*ChangeAssociatedDisplayIdWhenTouchIsActive*" Flag: EXEMPT bugfix Change-Id: I275bdd03929be6dd024c250c1276c05622a0e2ce
Diffstat (limited to 'libs/ui/DisplayIdentification.cpp')
0 files changed, 0 insertions, 0 deletions