summaryrefslogtreecommitdiff
path: root/libs/gui/BufferQueueThreadState.cpp
diff options
context:
space:
mode:
author Siarhei Vishniakou <svv@google.com> 2020-09-08 19:43:33 -0500
committer Siarhei Vishniakou <svv@google.com> 2020-10-20 23:31:53 -0700
commit265ab01bc7be5889521541a2f6ad08e2d204f10a (patch)
treeafa929785f858a17c8ef9ee8d1dae414b7268760 /libs/gui/BufferQueueThreadState.cpp
parent4e21979f459d71d34daf300444815dd603417380 (diff)
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 Bug: 167780081 Test: atest inputflinger_tests Change-Id: I70162d507fa7d65132c83fcba96ad9931e373647 Merged-In: I70162d507fa7d65132c83fcba96ad9931e373647
Diffstat (limited to 'libs/gui/BufferQueueThreadState.cpp')
0 files changed, 0 insertions, 0 deletions