summaryrefslogtreecommitdiff
path: root/libs/androidfw/ResourceTimer.cpp
diff options
context:
space:
mode:
author Harry Cutts <hcutts@google.com> 2024-02-12 14:32:03 +0000
committer Harry Cutts <hcutts@google.com> 2024-02-12 16:51:17 +0000
commitb8c7f5eb6bd2c77d41f84b2f6194b41e989bd541 (patch)
tree94c862d8954a705b0f352bfb434aeb750e0398da /libs/androidfw/ResourceTimer.cpp
parent6d92ca2277284a616be079b1fe37f2dfb7920dff (diff)
Reland "uinput: use nanoseconds for delay durations"
(This CL is unchanged. Original description below, with additional Test: line) evemu recordings use microseconds for their time intervals, but we can only schedule handler calls in Device at millisecond precision. So far we've converted the microseconds into milliseconds in EvemuParser, which means that the precision losses compound over time (since each delay will be slightly shorter than it should be, and the next delay will start from that slightly earlier time, etc.). Keeping the delay durations in a more precise unit up until the very last moment means that we'll only get the precision loss once for each event. Since it's somewhat uncommon to use microseconds elsewhere in Android code, and we get the system time in nanoseconds, we may as well use nanoseconds rather than microseconds. Bug: 310958309 Test: play an evemu recording through uinput Test: atest UinputTests Test: atest android.view.cts.input.InputDeviceKeyLayoutMapTest \ android.view.cts.input.InputDeviceSensorManagerTest \ --rerun-until-failure=10 Change-Id: Ibb968487ed114a4c464ac7061af4cda188e92498
Diffstat (limited to 'libs/androidfw/ResourceTimer.cpp')
0 files changed, 0 insertions, 0 deletions