tree 57b28b4e490ab07a233957dc18b6ae50f394d993
parent 060a7276bfb9a9a33070405c1f3fce861b9e89b3
author Siarhei Vishniakou <svv@google.com> 1614980386 +0000
committer Siarhei Vishniakou <svv@google.com> 1621285896 +0000

Add LatencyTracker to InputDispatcher

LatencyTracker will be used to record the complete timeline of an input
event dispatch, from the kernel to the presentation of a graphics frame
to the display.

The data about input event timeline is coming from three different
locations:

1) notifyMotion: this is when the InputDispatcher first learns about the
event from InputReader. At this point, we learn the time when the event
was first created, to time when the event was read by the user space,
and we are now adding the timestamps when the InputReader notifies the
dispatcher about the event.

2) finishInputEvent: this is when the app sends an 'ack' that a specific
input event has been processed. Through this call, we learn about when
the event was first sent to the app, and when it was read by the app. At
this time, we are also collecting the 'finishTime', so that we can
measure the total time that the app spent processing the event.

3) sendTimeline: this is when the SurfaceFlinger notifies the app about
the metrics for a specific frame. This metrics information is passed
down through the InputChannel to the InputDispatcher. Here we learn
about the time when the app sent the buffer to the SurfaceFlinger
(gpuCompletedTime), and the time when the frame was presented
(presentTime).

Overall, the end-to-end touch latency is presentTime - eventTime.
The rest of the data can be used to measure the breakdown of this
latency.

The goal of LatencyTracker is to combine all this data and present a
complete, unified timeline for a specific input event for further data analysis.

In a separate CL, we will report this complete timeline to statsd.

Bug: 169866723
Test: atest inputflinger_tests
Change-Id: I6e6e80e3393878fe86f3935c7c0e13dfff8629f9