Handle BadTokenException exception more reliably.
This is a follow up for I2c21573cf972145ab08e66604cdb9344139a3f31, which
added BadTokenException handler so that we can deal with unavoidable
runtime exceptions. However, it turns out that CL does not work well
in a certain case.
One problem in I2c21573cf972145ab08e66604cdb9344139a3f31 that it added
the exception handler in the call site of
InputMethodService#showWindow(boolean) rather than callee side as
follows.
try {
showWindow(true);
} catch (BadTokenException e) {
if (DEBUG) Log.v(TAG, "BadTokenException: IME is done.");
mWindowVisible = false;
}
However, the above code fails to update #mWindowVisible if an IME
overrides InputMethodService#showWindow(boolean) but catch-and-ignore
BadTokenException as follows.
@Override
public void showWindow(boolean showInput) {
try {
super.showWindow(showInput);
// Do something if super.showWindow() succeeds.
} catch (BadTokenException ex) {
// Do something if super.showWindow() fails.
}
}
With this CL, InputMethodService#mWindowVisible is always updated in
the callee side whenever it should be.
Note that this CL does not change anything about which method can
throw BadTokenException and which method catch-and-ignores it so as
not to break existing IMEs unexpectedly.
Bug: 23798142
Change-Id: Id1e5f236f48c8ef01b7f157ba3f6e7ab2c26b135
1 file changed