summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorSiarhei Vishniakou <svv@google.com>2020-06-22 12:53:35 -0700
committerMichael Wright <michaelwr@google.com>2020-06-25 19:09:53 +0100
commit48f110ec7bcbc28f9e2f0625f1e6f936827d26d6 (patch)
treef0257b4d96e5f422004b7a12234f233a004b286e /tools/aapt2/java/JavaClassGenerator_test.cpp
parent17761fff2a5ba2e35b84c932c58508c43191ea38 (diff)
Prevent ANR if window is stopped
When an activity is stopped, there could still be some pending events in the inputconsumer due to batching. Those events are supposed to be handled when choreographer's 'CALLBACK_INPUT' occurs, but this will never happen if the window is stopped. There are two possible ways these events can occur: 1. The last input event happens before onStop, but at that point, choreographer will already stop sending callbacks. The solution to this is to add a call to "consumeImmediately" inside setWindowStopped. 2. Input events come in after window has already been stopped. At that point, the callback we posted in 1. would already have executed (and found that there's no events). The solution to this is to immediately consume all input if mStopped=true. We do this by switching to "unbuffered" mode for simplicity. This is reproducible via monkey testing, but it's plausible that such race condition can occur in real world usage. Test: adb shell monkey --throttle 40 50000 Bug: 159239700 Change-Id: I74d8f55503ef7df2fd01931afb362d68e5026e86
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions