This CL converts our inhouse Completable class with CompletableFuture.
One of downsides of switching into CompletableFuture is performance.
It creates much more objects, especially in unsuccessful cases
including timeout scenarios:
* CompletableFuture#cancel() always creates a CancellationException
object with full stack trace. This is going to be problematic when
we start cancelling pending InputConnection tasks in Bug 195115071
from the IME client side.
* Timeout cases always creates a TimeoutException object with a full
stack trace.
* Exception cases always creates a ExecutionException object with
full stack trace.
Also, none of its getter methods directly fits our existing use cases
in the input method framework world. We must always use
CompletableFutureUtil to retrieve the result value so as not to
accidentally break existing APIs.
Other than above, there should be no observable semantic behavior
changes in this CL.
Bug: 192412909
Bug: 195699814
Test: presubmit
Test: atest -c FrameworksCoreTests:CompletableFutureUtilTest
Change-Id: I215bbc870f952effa262fa431064b36ace28e8f4
Before WindowProviderService, Service can add windows with several
window types. This is previously not allowed for WindowProviderService
because a context can only associate with a window container.
However, it may cause regressions because Service is used to add
windows with multiple types.
This CL allows WindowProviderService to do so, but WindowProviderService
can only associate with the window type returned by #getWindowType.
This CL also extracts some methods to WindowContext interface so that
WindowContext and WindowProviderService can reuse the same interface.
Test: atest WindowContextPolicyTests StrictModeTest
Test: atest ContextIsUiContextTest ContextGetDisplayTest
Test: atest WindowContextTest WindowContextTests
fixes: 191959013
Change-Id: Ie16916b370a4cbb8a17ccaec9870d47b4b089390
This is a mechanical refactoring CL that renames
com.android.internal.view.IInputConnectionWrapper
to
com.android.internal.inputmethod.RemoteInputConnectionImpl
with no observable behavior change.
Bug: 192412909
Test: presubmit
Test: No lint error under core/java/com/android/internal/inputmethod
Change-Id: I171106ad0b46fbb495a6bf08d10f33915c2d29ac
This is a small code clean up in IInputContext, which should have no
observable behavior change for app/IME developers.
In the following two methods we have used IIntResultCallback to return
a boolean value in a synchronous manner by using 0 to represent false
and 1 to represent true.
* IInputContext#requestCursorUpdates
* IInputContext#commitContent
Now that we have IBooleanResultCallback, we can just use true and
false without any conversion.
Bug: 192412909
Test: presubmit
Change-Id: Id6beaf3c9350b70138eb77f406be86fe2c8b679f
This is a follow up CL to my previous CL [1] in Android L, which
renamed
InputConnection#requestUpdateCursorAnchorInfo()
to
InputConnection#requestCursorUpdates()
per API council feedback before that API was finally published.
Although its API surface has been correctly renamed, there have been
several uses of its older name in our internal code. This CL also
updates such internal uses to avoid confusions.
As this is a purely mechanical renaming, there should be no behavior
change in this CL.
[1]: I772c48ff18918e48a81e807b48ff907614485c09
d8636ea7ca
Bug: 192412909
Test: atest
Change-Id: I75701a5a32d52283497208013c28ceb75c1adfa9
This is a follow up CL to my previous CL [1], which aimed to put an
early-exit check for
InputConnection#commitCorrection(CorrectionInfo)
but mistakenly put it in
InputConnection#commitCompletion(CompletionInfo).
With this CL the early-exit check will be placed at the right place.
[1]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e80
Fix: 193907158
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Change-Id: I497628165072c73d0e279f89afe0d8730531ecfc
This is a mechanical refactoring CL that has no behavior change.
This CL removes the direct dependency on AbstractInputMethodService
from whenever possible. As a result, the following classes no longer
directly depend on AbstractInputMethodService.
* android.inputmethodservice.IInputMethodWrapper
* android.inputmethodservice.RemoteInputConnection
* com.android.internal.inputmethod.ImeTracing
* com.android.internal.inputmethod.ImeTracingClientImpl
* com.android.internal.inputmethod.ImeTracingServerImpl
This is still a purely mechanical refactoring. There should be no
observable behavior change.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Test: Manually verified that IME tracing still works
Change-Id: I2aeeeacd27195ce10059d6590e098a4a969e774d
This is a mechanical refactoring CL that has no behavior change.
Currently all the utility methods defined in
InputConnectionProtoDumper return ProtoOutputStream, while the
returned instances will always be converted into byte[] eventually.
With this CL, those utility methods return byte[] instances directly,
which is expected to make it easier for ART/dexpreopt to do more
optimizations such as code inlining because instances of
ProtoOutputStream will no longer be escaped from those methods.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Test: Manually verified that IME tracing still works
Change-Id: I7b24aee5428da312972aa86b8658429b421490f8
This CL renames classes related to IME tracing as follows
* android.util.imetracing.ImeTracing
=> com.android.internal.inputmethod.ImeTracing
* android.util.imetracing.ImeTracingClientImpl
=> com.android.internal.inputmethod.ImeTracingClientImpl
* android.util.imetracing.InputConnectionHelper
=> com.android.internal.inputmethod.InputConnectionProtoDumper
Other than those renamings, there should be no observable chagnes.
Fix: 175761228
Test: presubmit
Test: Manually verified that IME tracing still works
Change-Id: I6518d946e1832037f240f57aa900d3447083f1fa
This is a purely mechanical refactoring with no behavior change.
An existing non-API class
com.android.internal.view.InputConnectionWrapper
has been used only from another non-API class
android.inputmethodservice.IInputMethodWrapper.
By moving it to android.inputmethodservice package we can make it a
package-private class, which is what this CL is intended
to achieve.
Furthermore, there is another public API class with the same name:
android.view.inputmethod.InputConnectionWrapper
, which has been confusing with this internal one. To avoid such a
confusion, this CL also renames this internal one to
RemoteInputConnection.
Other than those mechanical changes, there should be no observable
behavior changes.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Change-Id: Ic0babecd34a6bc80b917050370abc2db5c03d84e
After InputMethodService migrated to WindowProviderService,
the display is initialized by getInitialDisplayId().
Therefore, we don't need updateImeDisplayId() to initialize
InputMethodService's Display anymore.
Test: atest CtsInputMethodTestCases MultiDisplaySystemDecorationTests
Bug: 149463653
Change-Id: Ia78139b5defc48c8b0354fc1e212eeb38fd71ba4
Also introduce IWindowManager#getDisplayIdToLaunchIme to make IMS
be aware of the launched display to prevent extra onConfigurationChanged
callback
Bug: 149463653
Test: atest MultiDisplaySystemDecorationTests CtsInputMethodTestCases
Test: atest ContextTest ContextIsUiContextTest
Test: manual - moving IME between 2 displays and displayArea within
display - config change received
Test: manual - the app to show IME crashed and focus is set to the
next task - no config change
Change-Id: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
Design doc: go/multi-session-ime-removal
We no longer require this mechanism to support
multi-clients IME, remove it completely.
Bug: 173341412
Test: atest CtsInputMethodTestCases
Change-Id: I0bdc8fe3d32ccabc8ea7996fc689543c3f99331a
Dont cache IME surface when IME was in fullscreen mode. This is done in
order to fix IME closing when it is used with RecyclerView. There can be
a special case where RecyclerView detaches the view holding mServedView
when IME is in fullscreen mode
While exact reason is still a mystery, short term solution is to not
cache IME when it was in fullscreen mode.
Fix: 187772544
Bug: 188818557
Bug: 167948123
Test: Manually using steps in bug
Change-Id: I1194d08a00622f1dfa232209a70dcb0797ba192b
When IME is targeting notification shade, IME will be above status bar,
and IME won't receive status bar insets anymore. The surface position of
the control of IME will be changed because IME fits status bar. If the
IME control target receives the new IME control (new surface position)
after the IME animation starts, the IME position will be stale until the
next IME animation, because the controls would be copied before playing
the insets animation.
This CL lets IME receive insets no matter what z-order IME has. So the
IME position will stay the same while it is moved above system bars, and
the IME behavior will be the same as before Android S (receiving status
bar insets while targeting notification shade).
Fix: 186178729
Test: Steps as below:
1. Make, install, and open EditTextVariations.
2. Open menu, and select Direct Reply.
3. Expand notification shade.
4. Expand the notification of EditTextVariations.
5. Click Direct Teply Test.
6. See if IME is overlapped with (button-based) navigation bar.
If no, press home button and repeat 3-6 for several times.
Change-Id: I53c64a5598f246ad577f652156903e4666a30cd9
-. Remove VoidResultCallback of applyImeVisibility.
and let it be truly asynchronous.
-. Rename this method to applyImeVisibilityAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Change-Id: Ica564c526223d32641a2485c0c0f3490fe4bfd39
-. Remove VoidResultCallback of notifyUserAction.
and let it be truly asynchronous.
-. Rename this method to notifyUserActionAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Change-Id: I384fd689b6bd1d418ff5208444fbba2c1eac6f85
-. Remove VoidResultCallback of updateStatusIcon
and let it be truly asynchronous.
-. Rename this method to updateStatusIconAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Change-Id: Ic7759354ec06a3293ea370ab7afe7422eb2d9356
As previously InputMethodManager#toggleSoftInput is designed to tell
InputMethodService directly through IInputMethodSession to toggle
soft-keyboard visibility, this could be happened some unexpected IME
visibility issues that when the app calling this method in the wrong
state like the app toggling IME visibility when the app is off-screen
but unexpectedly it ends up showing soft-keyboard when the IME is in
invisible state.
To minimize the app compatibility without changing the public API
surface and reducing unexpected IME visibilty been toggled behavior
especially happens when switching the apps, changed the internal IPC
protocols to call IMMS#showSoftInput or IMMS#hideSoftInput directly
according the previous IME consumer requested visibility state,
so that in IMMS side can validate to see if the token user is
still focused and ready to toggle the IME visibility to show or hide.
As the result, we deprecated toggleSoftInput and
toggleSoftInputFromWindow to state the reason as the above, and
recommand to use showSoftInput or hideSoftInputFromWindow instead,
so that framework side no longer has to call {InputMethodSessionWrapper,
InputMethodSessionImpl}#toggleSoftInput.
Bug: 182071625
Test: m checkapi doc-comment-check-docs
Test: atest KeyboardVisibilityControlTest#testToggleSoftInput
Change-Id: I390dc029e7bcc30c200926a9bfbbbd0268a1f714
-. Remove VoidResultCallback of reportFullscreenMode
and let it be truly asynchronous.
-. Rename this method to reportFullscreenModeAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Test: Manually verified as follows.
1. Build flame-userdebug and flash it.
2. Make sure that the screen rotation is enabled.
3. make -j SoftKeyboard
4. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
5. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
6. adb shell ime set com.example.android.softkeyboard/.SoftKeyboard
7. make -j EditTextVariations
8. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/arm64/EditTextVariations.apk
9. adb shell am start -n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
10. Make sure that the device is in the landscape mode,
and the SoftKeyboard sample IME is not yet shown.
11. adb shell dumpsys input_method | grep mFullscreenMode
Then make sure the mFullscreenMode is "false"
12. Tap the first edit field then make sure that SoftKeyboard
sample IME becomes visible in the fullscreen mode.
13. adb shell dumpsys input_method | grep mFullscreenMode
Then make sure the mFullscreenMode is "true"
14. Tap the down button on the navbar to hide the SoftKeyboard
sample IME.
15. adb shell dumpsys input_method | grep mFullscreenMode
Then make sure the mFullscreenMode is "false"
Change-Id: I92e8b0d420be3dd16cc4f3ba29e0bde5f12ab2ce
CL[1] removed setImeWindowStatatus call in showSoftInput()
since showWindow() has a call.
Howerver, the call invokes only when the IME visibility has changed.
It overlooked the case that when the screen unlocked by PIN
lock, since the focused app and IME visiblity is the same, so
the setImeWindowStatus in showWindow() doesn't invoked.
When then keyguard shown, IMMS side will invoke updateSystemUiLocked to
update navbar icon as invisible, so after the user unlocked, user won't
see the navbar icon set visible back.
As the result, we still need setImeWindowStatus called in showSoftInput
to fix this case.
[1]: I0b0750f146634d8e90e0b0ac46e9208675626d0a
Fix: 181294561
Test: manual as below steps:
0) setup PIN lock for the device
1) launch an app (e.g. Messaging) and show IME
2) turn-off the screen and unlock the screen with PIN
3) verify if the keyboard is visible and the navbar icon is visible
Change-Id: I168fda76c1c7bdcabe94f7c2550c6b5c7c41e5e0
-. Remove VoidResultCallback of reportStartInput
and let it be truly asynchronous.
-. Rename this method to reportStartInputAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Change-Id: Ic8e7f888f78f7c536a9228db02a8b355555d7220
Handle onConfigurationChanged() in order to prevent restarting
InputMethodService everytime. We introduce a new API attribute
"configChanges" in InputMethod(attrs.xml) which when declared
by IME, will be responsible for handling mentioned
configuration changes.
This CL re-introduces [1] with fix: Use new Configuration instance for
IMS#mLastKnownConfig and also handle followup comments.
[1] Ib94fddadb0dae648cf73a4c1642e51edebd19f50
Note: this change has no impact for devices not using DisplayAreas.
Bug: 167948419
Test: atest InputMethodServiceTest
Manually:
1. Patch Ie91e7a8e06b80864ef9409031e8543858552d70d to use dual
display area.
2. Open applications with editors on both display areas.
3. Attach a debug point for IMS#onConfigurationChanged().
4. Make sure IMS#resetStateForNewConfiguration() is not called
when IME moves between these two identical DisplayAreas
Also verify that bug 182604598 don't happen.
Change-Id: I43b6b80cdb35410554412ee1d3b0917ee3198272
-. Remove VoidResultCallback of setImeWindowStatus
and let it be asynchronous.
-. Rename function naming to setImeWindowStatusAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Change-Id: Ia9f19ca5ae418089ce43816dcd50487e1b1172f1
Revert "Add cts for InputMethodService configChanges"
Revert submission 13727407-167948419
Reason for revert:
Possible root cause of Bug 182604598.
Reverted Changes:
Ib94fddadb:Avoid IME restart for configChanges
Ieca327b2e:Add cts for InputMethodService configChanges
Bug: 167948419
Bug: 182604598
Test: presubmit
Change-Id: I3accc55ac65d0e2ec30c3f6023680fda27ad3e97
Handle onConfigurationChanged() in order to prevent restarting
InputMethodService everytime. We introduce a new API attribute
"configChanges" in InputMethod(attrs.xml) which when declared
by IME, will be responsible for handling mentioned
configuration changes.
This CL re-introduces [1] with fix: Use new Configuration instance for
IMS#mLastKnownConfig
[1] Iff88b768c6b06cf5cf1fe9e97ee97f8f78e6f0bd
Bug: 167948419
Test: atest InputMethodServiceTest
Manually:
1. Patch Ie91e7a8e06b80864ef9409031e8543858552d70d to use dual
display area.
2. Open applications with editors on both display areas.
3. Attach a debug point for IMS#onConfigurationChanged().
4. Make sure IMS#resetStateForNewConfiguration() is not called
when IME moves between these two identical DisplayAreas
Change-Id: Ib94fddadb0dae648cf73a4c1642e51edebd19f50
Handle onConfigurationChanged() in order to prevent restarting
InputMethodService everytime. We introduce a new API attribute
"configChanges" in InputMethod(attrs.xml) which when declared
by IME, will be responsible for handling mentioned
configuration changes.
Bug: 167948419
Test: atest InputMethodServiceTest
Manually:
1. Patch Ie91e7a8e06b80864ef9409031e8543858552d70d to use dual
display area.
2. Open applications with editors on both display areas.
3. Attach a debug point for IMS#onConfigurationChanged().
4. Make sure IMS#resetStateForNewConfiguration() is not called
when IME moves between these two identical DisplayAreas
Change-Id: Iff88b768c6b06cf5cf1fe9e97ee97f8f78e6f0bd
Followup to I5a5e73e1dec776665f28a7e2eb091b555198001b.
internalImeOptions field should be parcelable.
Fix: 157870379
Test: Manually using steps in bug
Change-Id: I12b442b8b2d8cf83aa4cc789133b42251ad2c191
As of today, IME surface is removed immidiately after its hidden.
This causes IME surface to be recreated when next time its requested,
which takes noticeable amount of time ~30ms on a typical phone [1]
In order to improve IME latency, we keep the surface in memory a little
longer.
This is ideal for use cases where IME has to move between DisplayAreas
OR when IME is closed only briefly.
While there could be other strategies to hold IME surface in memory,
timeout is simplistic and is also unaffected by IMF lifecycle, which
could vary when moving between DisplayAreas or Displays.
Bug: 167948419
Bug: 167948123
Test: atest CtsInputMethodTestCases
[1] refer design doc in bug 167947940
Change-Id: Ib062640b68164efbb647e7bf27b7f8eb5ed252dc
When an app is running in portrait orientation, regardless of
what orientation display is in, IME shouldn't use fullscreen-mode.
Setting IME_FLAG_NO_FULLSCREEN in EditorInfo makes sure IME doesn't go
fullscreen.
Bug: 157870379
Test: Manually using steps in bug
Change-Id: I5a5e73e1dec776665f28a7e2eb091b555198001b
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
