summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorYohei Yukawa <yukawa@google.com>2018-10-26 08:43:30 -0700
committerYohei Yukawa <yukawa@google.com>2018-10-26 13:03:11 -0700
commit052ab8ceea4b2d188578ef529c5dabda4f0a256f (patch)
tree05368c246b90c131aa12326794f967b8101e1b9f /tools/aapt2/java/JavaClassGenerator_test.cpp
parentf95d6a17f5721144ac207b91307ce5146a64eab7 (diff)
More robust display ID mismatch detection in IMM
This is another follow up CL to my previous CL [1] that enabled per-display InputMethodManager (IMM) instance (Bug 115893206). What we learned in Bug 118341760 is that for some apps view.getContext() may return a ContextWrapper subclass whose Context.getDisplayId() and Context.getSystemService() are not consistent with each other. Although this is considered to be a bug of such a ContextWrapper subclass, application developers may not be aware of the issue when such a problematic ContextWrapper came from libraries that app developers happened to, or had to, depend on. The key idea of this CL is that view.getViewRootImpl().getDisplayId() would be a more robust source of display ID than view.getContext().getDisplayId() for most of cases, because to which ViewRootImpl a given View belongs is already a strong signal about to which display the View belongs. As far as I've tested locally, this approach seems to be more promising and is expected to give us better app compatibility in multi-display scenarios. [1]: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b 4052a10f2970f83d40bf5a45f3632cd63d084e51 Bug: 118252837 Fix: 118341760 Test: atest ActivityManagerMultiDisplayTests Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest Change-Id: If47e48bc8176657bf4bb882146d2affdfe457c90
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions