tree bf58104558d722c4eb19ea0ae2466a22b04f7b7d
parent 8991beb24d8e24473a2f9b34c15b30722bd55cdd
author Siarhei Vishniakou <svv@google.com> 1599612213 -0500
committer Siarhei Vishniakou <svv@google.com> 1601936371 +0000

Check for focused window before raising 'no focused window' ANR

Previously, we were relying on the dispatcher trying to send a focused
event prior to raising ANR due to no focused window.

So, the previous expected behavior was:
1. A key comes in, and there is no focused window
2. ANR timer starts
3. Focused window appears
4. We try to dispatch the key again, and realize there's a focused
window
5. We stop the ANR timer

However, there are cases when the pending key event gets dropped. For
example, this could happen if the user touches another application. That
would lead to the following sequence of events:
1. A key comes in, and there is no focused window
2. ANR timer starts
3. User touches another application, and the pending key gets dropped
4. Focused window appears
5. We don't try to dispatch the pending key anymore (since nothing is
pending)
6. We raise the "no focused window" ANR, even though we have a focused
window (and don't even have a focused event to dispatch anymore).

Solution: always check for focused window presence before raising the
"no focused window" ANR. This way, we will no longer rely on other events
happening for this ANR to be functioning correctly.

Bug: 164754075
Test: atest inputflinger_tests
Change-Id: I70162d507fa7d65132c83fcba96ad9931e373647