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
Loading
Please register or sign in to comment