How new a press is, is all the clock was wanted for, and it was read
at every poll while the input block timeout was on. It is read now
only on a poll a pad's button was pressed in; presses held over are
shown, and a tap let go, without it, and a pad with nothing held is
not looked at.
The poll waited up to the input block timeout for an event, and again
after each one, so that a press a pad sends as several events a few
milliseconds apart landed in one poll. That stalled every frame by the
timeout, pressed or not, on the main thread.
The poll no longer waits in the foreground. Instead a pad's presses in
a poll are shown at its end unless the newest of them came within the
timeout of it, by Android's own event times: then they wait for the
next poll, and the rest of the press, coming before that, is shown with
them. Nothing waits more than one poll, an older press is shown at
once, and a press let go before it was shown is shown for one poll. At
0, the default, nothing is kept back and it costs nothing.
The keeping back is android_press_group.h, which
samples/input/android_block_timeout holds to all of that.
Input Block Timeout lets a pad that sends one press as several events
have them all taken in the same poll: the poll waits up to the timeout
for an event, and again after each one, until none follows within it.
The change that stopped the poll draining the battery in the
background waited only for the first event and none after, so the
setting did nothing any more.
In the foreground the timeout is waited after each event again;
backgrounded the poll still waits for whatever wakes it and then
drains the queue without waiting. The waits are in android_poll_wait.h,
and samples/input/android_block_timeout holds them to both, with the
first-event-only way asserted to be caught.
LibretroAdmin