diff options
| author | 2024-02-21 06:57:36 +0000 | |
|---|---|---|
| committer | 2024-03-08 05:18:55 +0000 | |
| commit | a67623c3daa81ecfe707c131f218bd1d0f416684 (patch) | |
| tree | 22b281c773ce7113c5f2cc035d66f443be195404 /libs/gui/LayerDebugInfo.cpp | |
| parent | 25cf7faf4a428573bec0a900ec628d0919657b2b (diff) | |
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
Diffstat (limited to 'libs/gui/LayerDebugInfo.cpp')
0 files changed, 0 insertions, 0 deletions