Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit a67623c3 authored by Prabir Pradhan's avatar Prabir Pradhan
Browse files

InputTracer: Trace events derived from other events separately

InputDispatcher goes through multiple "phases" when dispatching
new event, roughly corresponding to the following:

1. Inbound event processing (e.g. InputFilter, policy filtering,
   generating key repeats, etc.)
2. Target finding (finding the touched/focused window(s) that should
   receive the event)
3. Event modification (generating new events based on the original, such
   as for split motions)
4. Publishing

When an event is modified in step 3, we always create a new EventEntry
with a new event ID to distinguish it from the original. These derived
events need to be traced separately, but need to share the same trace
context as the original event. For example, an event is split across
windows A and B, and the whole event is sent to spy window C. In this
case, windows A and B receive a derived event, and C receives the whole
event. If B is a trace-sensitive window, we must not leak the sensitive
info from the event by tracing the original event through C.

Since event modification (step 3) always happens after target finding
(step 2) for a dispatch entry, we will trace the derived (modified)
events separately. The modified event will never affect
target-finding, so the derived events are more limited, but they share
the same context as the original event by using the same State under the
hood.

Bug: 210460522
Test: atest inputflinger_tests
Change-Id: I772a04b7dfd0322357dd4dfa95387244ca6230e9
parent 25cf7faf
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment