This CL fixes a race condition for IMM#showSoftInput, which surfaces
when it's called during an IME hide animation.
IMM#showSoftInput ends up calling WIC#show asynchronously, but at that
time the running IME hide animation may have already been finished
successfully, and WIC#show may fail to cancel the hide animation
(then the cleanup IMM#notifyImeHidden hides the IME again disruptively).
I think a clean fix is to have IMM#showSoftInput call WIC#show
synchronously. However, this requires a significant refactoring.
As a short term fix, this CL adds a boolean field indicating whether or
not IMM#showSoftInput has been called. If it's called, we skip calling
IMM#notifyImeHidden.
Bug: 221483132
Bug: 225674038
Test: atest InputMethodStressTest
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: I36d570630085d0bc34097a2433208601dc9cb0fd
(cherry picked from commit 4c607982ed)
Merged-In: I36d570630085d0bc34097a2433208601dc9cb0fd
Currently, IMMS will be notified asynchronously when an IME hide
animation finishes, via message dispatching through IMS
(IMM#notifyImeHidden -> IMS#notifyImeHidden -> IMMS#hideMySoftInput).
This creates a race condition when IMM#showSoftInput or WIC#show is
called around the end of hide animation.
This CL fixes the race condition by synchronously and directly
calling IMMS#hideSoftInput from IMM#notifyImeHidden.
Note that there is still another race condition for IMM#showSoftInput
(not WIC#show) if it's called during an IME hide animation;
IMM#showSoftInput ended up calling WIC#show asynchronously, but at that
time the running IME hide animation may have already been finished
successfully and WIC#show may fail to cancel the hide animation
(then the cleanup IMM#notifyImeHidden hides the IME again disruptively).
I will fix the latter issue in a separate CL.
Bug: 221483132
Bug: 225674038
Test: atest InputMethodStressTest
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: I7c71dc5a1d6b61aa79d1666f0e257e6401e4adb2
(cherry picked from commit 9065310f81)
Merged-In: I7c71dc5a1d6b61aa79d1666f0e257e6401e4adb2
Note that the seekbar UI can now get a bit janky if
you have TalkBack on and you very quickly swipe up or down. We can file
a new bug for that if we decide it needs fixing.
Fixes: 216254595
Fixes: 216254099
Test: SeekBarViewModelTest
Test: manual: Turn TalkBack on, select the seekbar, and verify you can
swipe up/down to change the track position.
Test: manual: Verify seeking without TalkBack on still works.
Change-Id: I890e4f396fa704047c5593fff20c8924b890fc75
Because Bitmap mutability is propagated across Parcel and Binder, the
following problem can happen when sending an Icon containing a Bitmap
as part of a Notification:
1. App creates Icon with a mutable Bitmap (1 alloc)
2. App sends Icon to system_server, often creating ashmem Bitmap (2 allocs)
3. system_server converts ashmem Bitmap back to heap Bitmap (3 allocs)
4. system_server sends heap Bitmap to each NotificationListener individually,
converting the heap Bitmap to ashmem each time (3+N allocs)
5. NotificationListener converts ashmem Bitmap to heap Bitmap (3+2N allocs)
This is inefficient. This is especially bad because the API to update
a Notification involves sending a full Notification object, including
Icons, repeatedly, and some apps do that several times per second.
Instead, ensure that all Bitmaps transmitted as part of Icons are
immutable. Instead, we get:
1. App creates Icon, which may copy to immutable Bitamp (1 or 2 allocs)
2. App sends Icon to system_server over ashmem (still 1 or 2 allocs)
3. system_server uses received ashmem Bitmap directly (still 1 or 2 allocs)
4. system_server sends same ashmem Bitmap to NotificationListeners (1 or 2)
5. Each NotificationListener uses the same ashmem Bitmap (1 or 2)
This solves the per-NotificationListener amplification, but it does
not solve sending what is likely the same Bitmap N times per second
when apps update Notifications. That will require either app changes
or Notification API changes to avoid bytewise comparisons for all
Bitmaps.
Test: boot, notifications work, memory in maps/gearhead remains good
Bug: 227920378
Change-Id: If92835f647a76da599f358c7c02888e3e2f59235
This is a follow up CL to my previous CLs[1][2], which are submitted
almost at the same time but not compatible with each other.
The first CL [1] introduced a new behavior that negative indices
passed to
AccessibilityInputConnection#getSurroundingText(int, int, int)
result in IllegalArgumentException, which is a different behavior than
what's observed from IMEs.
The second CL [2] assumed that negative indices passed to that API
result in just receiving null result like what's observed from IMEs.
This CL effectively reverts the new behavior introduced in the first
CL [1] to keep two observable behaviors consistent.
Note that negative indices passed to getSurroundingText() are already
handled in
RemoteInputConnectionImpl#getSurroundingText()
in a graceful manner [3], which guarantees that the IME client process
will not see such an irregular parameter (Bug 169114026) with keeping
the InputConnection commands order (Bug 194110780).
[1]: I5ff2e804cbcf90828370a0612ff54111130bdff4
c60176c1f3
[2]: I62b80916369bdac981dc93c14dcaedc1f2b6e95f
495ac0f55cbcc976995e8c73fdc89babfbdce902
[3]: Ie0c18d0c9b8bf8f02f2fcdca5aac7e580c6bf2cd
8821afef81
Bug: 215633021
Fix: 229981360
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Change-Id: I16a0185343c7c7c3e0947aab2c398714a1077b97
Bug: 210453009
Test: test on the local phone
Change-Id: I8872cdd2917580ff86dcf7a2d7a40a445fbd70b3
(cherry picked from commit 520e7d40ab)
Merged-In: I8872cdd2917580ff86dcf7a2d7a40a445fbd70b3
Notably eliminate references in RangeInfo and CollectionInfo class
descriptions. We've just deprecated obtain and recycle, so keeping
outdated docs is confusing.
Test: builds
Bug: 229991765
Change-Id: Ia2d7963bf572740052e0da03950398d016a3caa4
