diff options
| author | Yohei Yukawa <yukawa@google.com> | 2019-04-25 18:32:15 -0700 |
|---|---|---|
| committer | Yohei Yukawa <yukawa@google.com> | 2019-04-25 18:32:15 -0700 |
| commit | 3d2cc0fffd13f46923d0fcfdd73d375ebbe955ce (patch) | |
| tree | def0d46bc9ee928c74627cbb0027ba6f6e977432 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | 2f956b53dff62e84ce74fdb79a7104900409e79c (diff) | |
Let IC#requestCursorUpdates() fail for cross-display connections
Since Android Q [1], it is intentional that when an IME client app is
running on a (virtual) display where IME should not be hosted, IME
will be hosted in the default display instead. This means that
cross-display App/IME interaction is an expected scenario now.
The problem is that CursorAnchorInfo API, which I introduced in
Android L [2], no longer works as intended in such a cross-display
scenario, because screen coordinates make sense only within the same
display.
The ultimate fallback strategy for this problem is forcing
InputConnection#requestCursorUpdates()
to always return false for such a cross-display scenario, which is
exactly what this CL does.
In subsequent CLs, we aim to introduce a special handling logic for
ActivityView, where the system may be able to keep maintaining
sufficient display hierarchy information so that
CursorAnchorInfo#getMatrix() can be automatically adjusted before it
is passed to the IME.
[1]: Iedd71e4ddf4983f90b02dd72e471e7fa8e838fbf
ef1965bd6d6061cb54bce305a4b99e640db19ddc
[2]: I61dec2f8fa671ba891da1d4af08975750e3acb04
1c7e66c97ce0a5d54e03abdee2f36fdce55944e6
Bug: 115693908
Fix: 131368625
Test: atest MultiDisplaySystemDecorationTests#testCrossDisplayBasicImeOperations
Change-Id: Ie2f7a5117cff3a13ad5c5806fd4b3abef7569549
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions