summaryrefslogtreecommitdiff
path: root/core/java/android/inputmethodservice/IInputMethodWrapper.java
Commit message (Collapse)AuthorAgeFilesLines
* InputWrapper: Opt out early if session == nullLars Greiss2022-10-261-0/+4
| | | | | Change-Id: If111195ba6425ad6b8663601566f9f260738ec77 Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
* Migrate IME to handle back with OnBackInvokedDispatcher.Shan Huang2022-05-041-4/+11
| | | | | | | | | | | | | | We currently close the IME by having the target application forward KEYCODE_BACK to the IME process through InputMethodManager#dispatchInputEvent and having the IME handle the keycode in InputMethodService#onKeyDown. When apps opt in to OnBackInvokedDispatcher API, we will not dispatch KEYCODE_BACK to apps anymore. Thus we need to migrate IME to the new API for it to close on back invocation. This implementation forwards OnBackInvokedCallbacks from the IME process to the app process. This is necessary because all callbacks need to exist in the app process for them to be considered by hardware back keys. While back gestures go through WM to resolve callbacks from the focused window, hw keys are directly sent to the focused window's ViewRootImpl, bypassing server side back nav logic. Bug: 228358882 Test: atest CtsInputMethodTestCases:KeyboardVisibilityControlTest Test: atest CtsInputMethodTestCases:InputMethodServiceTest Test: atest CtsInputMethodTestCases Change-Id: Ie207b63b11a56c9b2173f26b734a27b13ebccc60
* Finish handwriting session for recents gestureTaran Singh2022-03-151-0/+11
| | | | | | | | | | | | | Finish stylus handwriting session when user swipes to recent. Bug: 223748964 Test: Manually: 1. Open an app with editor 2. swipe on editor with stylus [or emulated stylus] 3. Observe ink trail drawn on screen 4. quickly sipe to recents, ink should go away. 5. repeat steps 1-3 for swipe to home Change-Id: Id750ff55cb447247c3eca75daf37cb5aeb1d0cfa
* Introduce InputMethodNavButtonFlagsYohei Yukawa2022-03-071-20/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | This CL reworks my previous CL [1], which let InputMethodManagerService report whether the IME switcher icon needs to be shown or not to the IME process by using IInputMethod IPCs. It turns out that we need to propagate one more boolean value in order to address Bug 219820813. It'd be much clearer if we use bit flags rather than adding a new boolean parameter to each IPC method. Thus this CL rewrites my previous CL by using a bit flag defined in a newly introduced InputMethodNavButtonFlags. This is a purely mechanical refactroing. There should be no behavior change. [1]: I5de9ac0dc8670842edf66306bb4c281c77cea376 75b935a12b37ffa97447b9acd80f94a4172bf3e6 Bug: 215551357 Bug: 219820813 Test: Manually verified with for the following scenarios: * Enabling/disabling multiple IMEs * Attaching/detaching a hardware keyboard * Showing/hinding the IME switcher * Showing an IME on the lock screen Change-Id: I81cb062a08d484ec8ce5d7b2fea64ce19028f82e
* Support IME switcher icon visibility updateYohei Yukawa2022-01-281-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this CL, the IME switcher icon becomes visible only when necessary, even if InputMethodService renders the back button and the IME switcher button in the gestural navigation mode. Implementation idea: InputMethodManagerService#shouldShowImeSwitcherLocked() is the source of truth about whether the IME switcher visibility should be shown or not, and it internally depends on the following conditions: A. com.android.internal.R.bool.show_ongoing_ime_switcher B. Whether the IME switcher is already shown or not. C. Whether the IME is perceptible or not. D. Whether one or more hardware keyboards are attached or not. E. Keyguard state. F. What IMEs and their subtypes are enabled. Here are what those conditions would mean for this project. * A is considered to be a per-device constant value. * B, D, and F can happen at any time outside of the IME lifecycle events such as startInput(). * C is no longer relevant if those buttons are rendered by the IME. * E is considered to be constant throughout each startInput() cycle. This CL uses the following 3 IPCs to notify when the IME switcher visibility is changing. 1. IInputMethod#initializeInternal() 2. IInputMethod#startInput() 3. IInputMethod#onShouldShowImeSwitcherWhenImeIsShownChanged() 1 and 2 will be used to provide the "initial" value to avoid potential flickers. 3 is still necessary to take care of async changes triggered by B, D, and F. Fix: 215551357 Test: Manually verified with for the following scenarios: * Enabling/disabling multiple IMEs * Attaching/detaching a hardware keyboard * Showing/hinding the IME switcher * Showing an IME on the lock screen Change-Id: I5de9ac0dc8670842edf66306bb4c281c77cea376
* Scribe in IMF: Early InkWindow preparation 6/NTaran Singh2022-01-261-0/+11
| | | | | | | | | | | | Allow stylus hover events for: 1. send early signal to IME onPrepareStylusHandwriting() 2. Prepare InkWindow internally. Test: atest StylusHandwritingTest Bug: 210039666 Bug: 203086136 Change-Id: Iebbd62659cb98b3c61edfa35d5a84a1c6837eb23
* Scribe in IMF: Stylus Spy windows Impl 5/NTaran Singh2022-01-261-3/+4
| | | | | | | | | | Implement Handwriting surface spy in IMF that listens and manages Stylus events. Test: atest StylusHandwritingTest Bug: 210039666 Bug: 203086136 Change-Id: I8681a33bb32f20b48cf741ba3ad2116de5db7ffa
* Remove unused IInputMethod#revokeSessionYohei Yukawa2022-01-221-20/+0
| | | | | | | | | | | Seems that IInputMethod#revokeSession has been defined but has never been called since at least Android 1.5. Let's remove it for now for simplicity. Bug: 192412909 Test: presubmit Change-Id: I3de8de1226ae028ac2e6bae8aeb34cd83f4c4f41
* Revert "Revert "Scribe in IMF: startStylusHandwriting & lifecycl..."Taran Singh2022-01-121-4/+40
| | | | | | | | | | | | | | | | Revert^2 "CTS for Stylus Handwriting lifecycle" 493b8d7d3b4d43e483c03b155d38057e3eacd3c9 Reason: Fix API signature related issues by making newly introduced methods in InputMethod.java default Bug: 213976598 Bug: 203086136 Test: atest StylusHandwritingTest Test: atest SignatureTest#testSignature Change-Id: Idfd5d1f84e66e3a19ef384589b4892adb91f8066
* Revert "Scribe in IMF: startStylusHandwriting & lifecycle 2/N"Josh Wu2022-01-111-40/+4
| | | | | | | | | | | | | | | | Revert "CTS for Stylus Handwriting lifecycle" Revert submission 16281467-stylus-handwriting-lifecycle Reason for revert: Breaks apisignaturetests BUGID: b/213976598 Reverted Changes: I7b066c284:Scribe in IMF: startStylusHandwriting & lifecycle ... I7d672b150:CTS for Stylus Handwriting lifecycle Change-Id: Ieec94ea525fdb45cf5316b4a331c2bf9882e1083
* Scribe in IMF: startStylusHandwriting & lifecycle 2/NTaran Singh2022-01-101-4/+40
| | | | | | | | | Introduce InputMethodManager.startStylusHandwriting(View) API and IME lifecycle. Bug: 203086136 Test: atest StylusHandwritingTest Change-Id: I7b066c2841b713e7a00ae2ea4ca0ce04aad751c6
* Deprecate MissingMethodFlags to preserve invocation orderYohei Yukawa2021-09-151-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL effectively replaces my previous CL [1], which made unimplemented methods in InputConnection not fatal errors, with a simplified implementation that still gracefully take care of unimplemented methods without causing app crashes. Instead of propagating missing method information from the IME client to the IME process, this CL will simply catch AbstractMethodError in the IME client process. Doing so enables us to 1. preserve the strict invocation order of InputConnection APIs, and 2. achieve the same goal with fewer lines of code. The additional cost of throwing (and catching) AbstractMethodError every time the IME calls an unimplemented InputConnection API can be justified as it is really an exceptional scenario, and avoiding it would require extra maintenance cost as seen in InputConnectionInspector. The above overhead (and complexity) due to AbstractMethodError can be avoided by adding default implementations to those InputConnection APIs, but doing so requires API signature update hence API council approval to go ahead, which is to be discussed in Bug 199934664. [1]: I3c58fadd924fad72cb984f0c23d3099fd0295c64 19a80a1e807acd00bec999eaac7812da6ffce954 Bug: 27407234 Bug: 27642734 Bug: 27650039 Bug: 194110780 Test: atest CtsInputMethodTestCases Change-Id: I9e801e92496a6e16cee37664870c97ed096f1413
* Simplify IInputMethod#startInput() handler a bitYohei Yukawa2021-09-131-13/+6
| | | | | | | | | | | | | | | | | | | | | This is a follow up CL to our previous CL [1], which introduced a nested SomeArgs to pass more integer parameters while handling IInputMethod#startInput() callback. Now that only 2 integers and 4 objects are required to handle IInputMethod#startInput(), single SomeArgs should be good enough to pack everything into a Message object. This CL does nothing other than applying such a mechanical code clean up. There should be no observable behavior difference. [1]: I1a6300fe167eb205ee2b4214a6e270a52ebae062 eadb1392f85f1ac8801018a02c31427801959b1c Bug: 192412909 Bug: 194110780 Test: presubmit Change-Id: I90eff3bfc5ed0f43472b0cd49aa532474a60c266
* Introduce InputMethodServiceInternal for better abstractionYohei Yukawa2021-07-131-8/+8
| | | | | | | | | | | | | | | | | | | | | | 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
* Rename InputConnectionWrapper to RemoteInputConnectionYohei Yukawa2021-07-071-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove updateImeDisplayIdCharles Chen2021-06-241-6/+5
| | | | | | | | | | | | 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
* Avoid IME restart for configChangesTaran Singh2021-03-301-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Avoid IME restart for configChanges"Yohei Yukawa2021-03-131-4/+3
| | | | | | | | | | | | | | | | | | 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
* Avoid IME restart for configChangesTaran Singh2021-03-101-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Avoid IME restart for configChanges"Taran Singh2021-03-011-4/+3
| | | | | | | | | | | | | | | Revert "Add cts for InputMethodService configChanges" Revert submission 13417792-b/167948419 Reason for revert: Causes bugs like b/181195100 Reverted Changes: Iff88b768c:Avoid IME restart for configChanges Ib7ce13340:Add cts for InputMethodService configChanges Bug: 167948419 Fix: 181195100 Change-Id: I36bca545b09b4f870560964ec61fa6bb344fceaf
* Avoid IME restart for configChangesTaran Singh2021-02-181-3/+4
| | | | | | | | | | | | | | | | | | | | 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
* Optimized workflow for IME tracing on InputMethodService sideIoana Stefan2020-11-131-15/+2
| | | | | | | | | | | | | | | | | Optimized the tracing logic for the IMS information. The InputMethodService triggers a tracing dump through the new method triggerServiceDump, exposed by the meTracing interface. This change was done to be able to support custom dumps from clients and custom dumps from InputMethodService. This change only covers the IMS information. The IMMS information will be dumped in next changes. Bug: 154348613 Test: start IME tracing by calling "adb shell ime tracing start" end IME tracing by calling "adb shell ime tracing stop" pull trace using "adb pull /data/misc/wmtrace/ime_trace_service.pb ime_trace_service.pb" Change-Id: Icda0f82d76fb7db5b2bd8d021069b1ff15a4e15b
* Merge "Remove preRender input"TreeHugger Robot2020-11-021-4/+2
|\
| * Remove preRender inputTaran Singh2020-10-291-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Cleanup unused pre-render input. We've no plans to enable it. It adds unnecessary complexity. Bug: 159201509 Bug: 167948123 Bug: 118599175 Test: atest CtsInputMethodTestCases Change-Id: I32fe3759b9aeb56c868f9abf42bab124b9b83374
* | Improve latency of IME tracingIoana Stefan2020-10-121-1/+1
|/ | | | | | | | | | | | | | Improve latency of IME tracing by increasing the priority of the tracing thread and adding the dump of the debugging information at the beginning of the execution queue. The Design Doc for IME tracing is found here: go/ime-tracing Bug: 154348613 Test: start trace by calling "adb shell ime tracing start" end trace by calling "adb shell ime tracing stop" pull trace using "adb pull /data/misc/wmtrace/ime_trace.pb ime_trace.pb" Change-Id: I153ccac6d8b93f86f3180b0a23240c6a63758ed6
* Add proto-based InputMethodService and server side dumping for IMEAnmol Gupta2020-10-071-3/+16
| | | | | | | | | | | | | | This CL implements a mechanism to dump InputMethodService and IME related server states into a proto file which can later be imported to Winscope to allow easy debugging. The Design Doc for the IME tracing project is: go/ime-tracing Bug: 154348613 Test: start trace by calling "adb shell ime tracing start" end trace by calling "adb shell ime tracing stop" pull trace using "adb pull /data/misc/wmtrace/ime_trace.pb ime_trace.pb" Change-Id: Icbfb8c11e882f29eb45dea9d4c23315c48e9d619
* Let blocked InputConnection APIs fail upon IInputMethod.unbindInput()Yohei Yukawa2020-04-021-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a follow up CL to our previous CL [1], which implemented fail-fast mode for blocking InputConnection APIs based on IInputMethod.unbindInput() async signal from IMMS to IMS. What was not implemented in the previous CL was a mechanism to immediately unblock a sync InputConnection API call that is already requested to the IME client process and waiting for its response. With this CL, any blocking InputConnection API fails immediately when IInputMethod#onUnbindInput() is delivered to the IME process, without waiting for the full time-out period (MAX_WAIT_TIME_MILLIS == 2 sec) to pass. Implementation Note: The key idea is to use CountDownLatch to compose multiple wait conditions.composed wait condition. The CountDownLatch is initialized with 1 then will be decremented when: A. received a result from the IME client B. received IInputMethod.unbindInput() Hence InputConnectionWrapper can simply wait for the CountDownLatch to become 0 with an existing timeout (MAX_WAIT_TIME_MILLIS) then returns failure unless the CountDownLatch became 0 because of A. [1]: I0f816c6ca4c5c0664962432b913f074605fedd27 1d113d041f113feabe0ff4cc57205fe8876b9e0b Fix: 36897707 Test: atest InputConnectionBlockingMethodTest Test: InputConnectionBlockingMethodTest#*FailFastAfterUnbindInput() take shorter time to complete. Test: Monitor logcat with `adb logcat -s InputConnectionWrapper:*` while running `atest InputConnectionBlockingMethodTest` Change-Id: Ic65a95eb5d0fd56f505a02fd9083bcf6694b6734
* Pipe windowToken for hideSoftInputTarandeep Singh2020-02-271-8/+15
| | | | | | | | | | | | | | | | | | Pipe the windowToken of the window requesting hideSoftInput just like we did it for showSoftInput [1]. This calls hideInsets on the correct display when control target is different from IME target e.g. ActivityView. Also hideInsets should be called on InsetsControlTarget instead which was originally attempted in [2] [1]: Ia49e23dd077d264a58d28a7b8acffde54b7db187 [2]: I7133e151a1037c42b275b97857936437a7a6725f Bug: 149870112 Bug: 133381284 Test: Manually using steps mentioned in bug. Change-Id: Ia596a392eb73ae46debd097151c8c9a7edd59833
* Introduces the Bundle to inline suggestions APIs to encode custom UI styling ↵Feng Cao2020-02-191-7/+6
| | | | | | | | | | | | | | | information. * The bundle will be generated/consumed by the support library. * More API documentation and example usage will be added later once we have the support library impl ready. * The old style resource name approach doesn't work due to the potential mismatch in the support library version across the host IME and the platform renderer service, and the non-static nature of the public attribute int id in the support lib. * The Bundle added to the onCreateInlineSuggestionsRequest() is intended for the platform/ExtServices to communicate the UI versions it supports. * The Bundle added to the InlinePresentationSpec is intended for the IME to communicate the custom styles for the chosen UI versions. Test: manual verification, and also atest CtsInputMethodTestCases:InlineSuggestionInfoTest CtsInputMethodTestCases:InlineSuggestionTest CtsInputMethodTestCases:InlineSuggestionsRequestTest CtsInputMethodTestCases:InlineSuggestionsResponseTest Bug: 146454892 Change-Id: Id7fea32a7550fb924fec811b376790474a7b92eb
* Pipe windowToken of window requesting IMETarandeep Singh2020-01-211-5/+8
| | | | | | | | | | | | | It takes time from when IME is requested to the time when IME is ready to be shown. When its ready to be shown, we need to make sure that window that requested IME is still the IME target in DisplayContent. The only realistic way of knowing originating window is passing windowToken from IMM API. Bug: 111084606 Test: CtsInputMethodTestCases Change-Id: Ia49e23dd077d264a58d28a7b8acffde54b7db187
* Use new UnsupportedAppUsage annotation.Artur Satayev2020-01-061-1/+1
| | | | | | | | Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library. Bug: 145132366 Test: m && diff unsupportedappusage_index.csv Change-Id: I0c336de56bc4a041dc97ff9b7927f62f0b44b457
* API for autofill integration with keyboard.Adam He2019-12-161-0/+18
| | | | | | Bug: 137800469 Test: manual verification Change-Id: Id222500c373898d576661cacb7a1cb51061041d4
* Add @UnsupportedAppUsage annotationsAndrei Onea2019-03-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For packages: android.companion android.filterfw android.hardware.camera2.utils android.inputmethodservice android.net.nsd android.os android.preference android.security.keymaster android.service.dreams android.telecom android.telephony.ims.compat.feature android.telephony android.util android.view.accessibility android.media.effect This is an automatically generated CL. See go/UnsupportedAppUsage for more details. Exempted-From-Owner-Approval: Mechanical changes to the codebase which have been approved by Android API council and announced on android-eng@ Bug: 110868826 Test: m Change-Id: I9c2f8347952f3cc65759472b0e1a2717b285e44e
* Pre-render input method (IME transitions 1/n)Tarandeep Singh2019-01-251-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pre-render input method views and window when EditText receives focus. This is a pre-requisite for implementing better IME transitions. Strategy: Once EditText receives focus, startInput is called. If optimization is available, IME views and window (SoftInputWindow) are created and rendered. Until user taps on EditText or showSoftInput() is called, IME window remains invisible. This pre-rendered window is kept around until EditorInfo changes or new connection is started (onStartInput). IME window's visibility will be set using new Insets controller API rather than conventional client-side dialog.show(). Behavior: - This is just IME side preparation CL. No performance improvements yet. - There should be no user perceptible behavior change. - As long as IME developers were following official lifecycle, they shouldn't perceive any behavior change. Availability: This optimization, once fully implemented, will be available when: - Device is not "Low memory" - AND Master flag DebugFlags.FLAG_PRE_RENDER_IME_VIEWS is set. - ViewRootImpl.USE_NEW_INSETS_API is enabled Bug: 118599175 Bug: 111084606 Test: atest CtsInputMethodTestCases Test: atest CtsInputMethodServiceHostTestCases Test: atest ActivityManagerMultiDisplayTests Test: Tested with 4 IMEs and didn't preceive any behavior change. Scenarios tested: 1. With and without hardware keyboard 2. Screen rotation w/ fullscreen mode. 3. split-screen Change-Id: I1a6300fe167eb205ee2b4214a6e270a52ebae062
* Support IME Window to show in secondary display.lumark2018-09-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 1) Moving WMS.setInputMethodWindowLocked to DisplayContent, each display can have its own IME window. 2) Add getDisplayIdFromWindow in WindowManagerInternal, used for InputMethodManagerService to know which display for given IME window token. 3) Support add / remove IME window according displayId. 4) Modify WMS.inputMethodClientHasFocus to traverse all active display if inputMethodClient focused. 5) Add displayId parameter for IInputMethod.initializeInternal to update context display then client can addView to right display. Note: 1) There should be zero behavior difference as long as the target app is running on the default display. 2) The current implementation is not final and there are still chances that the current IME may not work well or even crash depending on how the IME is implemented. Bug: 111364446 Test: manual, use ActivityView & launch Messages in VirtualDisplay, tap search icon to see if soft input keyboard shown & app window size is adjusted by soft input. Change-Id: I8da315936caebdc8b2c16cff4e24192c06743251
* Move InputMethodManagerService to com.android.server.inputmethodYohei Yukawa2018-09-111-2/+2
| | | | | | | | | | | | | | | | This CL moves InputMethodManagerService (IMMS) from com.android.server to com.android.server.inputmethod so that we can mechanically factor out inner classes from IMMS to separate package private classes. This is purely a mechanical refactoring of an implementation detail. There should be no observable behavior difference. Fix: 114660660 Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases Test: atest FrameworksCoreTests:com.android.internal.inputmethod Change-Id: I023d8f2863601ee54f304988117d8ea750770f70
* Add a new Binder interface to allow IMS to directly talk to IMMSYohei Yukawa2018-09-061-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, InputMethodService (IMS) has relied on InputMethodManager's hidden methods to communicate with InputMethodManagerService (IMMS). Because of this, InputMethodManager (IMM) has ended up being a mixture of IPC endpoint for both IME clients and IME itself. There are multiple problems. * IMM is instantiated in almost all user mode processes. This means that unnecessary IPC endpoints have been accessible to them via reflection. Even though those endpoints refuses request without a valid IME window token, and even though we have tighten up use of private APIs in the runtime level, exposing unnecessary IPC endpoints is still questionable. * Mixing multiple responsibilities has been caused unnecessary complexity in IMM. In Bug 70282603, we have moved some APIs from IMM to IMS to sort out this complexity that are surfaced in API boundary, but in the implementation level everything remained to be the same. Now that Bug 70282603 is fixed, the natural next step is to start implementing actual an IPC connection from IMS to IMMS without relying on IMM. Here is the new diagram that describes (most of) IPC interfaces around IMEs. APP---(1)---IMMS \ | \ | \ | \ | \ | (2) (3) \ | \ | \ | \ | \| IME (1): IInputMethodManager.aidl: send requests from APP to IMMS IInputMethodClient.aidl: send requests from IMMS to APP (2): IInputMethodSession.aidl: send requests from APP to IME IInputContext.aidl: send requests from IME to APP -> this is the actual interface behind InputConnection (3): IInputMethod.aidl: send requests from IMMS to IME IInputMethodPrivilegedOperations.aidl: send requests from IME to IMMS IInputMethodPrivilegedOperations.aidl is what this CL is adding. With that, this CL moves 5 IPC methods from IInputMethodManager.aidl (1) to IInputMethodPrivilegedOperations.aidl (3). There remain some IPC methods that are intended to be used only from IMEs in IInputMethodManager.aidl because those methods have been unfortunately exposed via public APIs in InputMethodmanager. Although all of those public APIs were deprecated in Android P as part of Bug 70282603, we still need to keep maintaining those APIs until (most of) IMEs migrate to APIs that are newly introduced in InputMethodService. It would take several years. IInputMethodManager#getInputMethodWindowVisibleHeight() is another method that we cannot migrate right now because some apps have already relied on its corresponding hidden method in IMM, as discussed in Bug 113914148. Fix: 113177698 Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases Change-Id: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
* Skip blocking InputConnection APIs after unbindTarandeep Singh2017-10-191-4/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | InputConnectionWrapper has several synchronous methods which have a timeout. If the application's UI thread hangs, all these synchronous methods are blocked and IME stays on-screen. This CL aims to improve the responsiveness of IMEs by rejecting any blocking calls of InputConnection APIs once IInputMethod#unbindInput() is issued by InputMethodManagerService (IMMS). Currently #unbindInput() is issued only from IMMS#unbindCurrentClientLocked(), which basically means that the previous application is losing the IME focus. Underlying #onUnbindInput() signal is still immediately delivered to the IME process, but it's just waiting to be consumed on the UI thread. Hence in theory we can change the behavior of InputConnection seen from the IME once the signal is delivered to the IME process. This CL does not interrupt already blocked API calls, which is one of future work for this scenario. This CL relies on: A. IInputMethod is marked as oneway B. IMMS guarantees that IInputMethod#bindInput() and IInputMethod#unbindInput() are always paired without nesting, and IInputMethod#startInput() is called 0 or more times only during that pair. In this case, the system guarantees that IInputMethod methods will be called back in the IME process in the same order, and only one IPC thread is handling those IPCs at the same time. See the JavaDoc of IBinder#FLAG_ONEWAY for details. Bug: 36897707 Test: Manual: using the apk in the linked bug: 1. Make sure that a valid InputConnection is established between the test app and a test IME. 2. Let the test app start blocking the UI thread. 3. Let the test IME call InputConnection#getTextBeforeCursor() three times. 4. Tap the Home button on the NavBar. 5. Make sure that the test app is immediately dismissed. 6. Make sure that InputConnection#getTextBeforeCursor() starts returning immediately, once after the initial call was timed- out after 2 sec (InputConnectionWrapper#MAX_WAIT_TIME_MILLIS) Change-Id: I0f816c6ca4c5c0664962432b913f074605fedd27
* Annotate threads for some IME handling methodsYohei Yukawa2017-10-181-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a preparation to work on Bug 36897707. For instance, the reason why most of IME-related callbacks in InputMethodService get called on the main thread is because IInputMethodWrapper keeps forwarding incoming IPCs into the main looper of the IME process as follows: InputMethodManagerService (IMMS) ------ -> one-way binder IPCs over IInputMethod ------ -> IInputMethodWrapper (on the binder thread(s)) -> Handler (to dispatch tasks to main thread) -> InputMethodImpl.* (on the main thread) -> InputMethodService.* (on the main thread) By adding explicit annotations such as @BinderThread and @MainThread in relevant methods, this CL makes that kind of investigation much easier than before. Bug: 36897707 Test: compile Change-Id: I8f9afe9a1986a9fa41fb66fdc64e8f0f67e45c2e
* No-op code cleanup for IInputMethodWrapperYohei Yukawa2017-10-181-23/+14
| | | | | | | | | This CL is a safe and no-op code clean-up, including dead code removal. There should be no behavior change. Test: continuous tests Bug: 36897707 Change-Id: I4a1ad9cb764c7ba82b32e325c4a4b1c8e7296bbf
* Fix duplicate calls of IMS#doStartInput()Yohei Yukawa2017-02-161-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is another follow up CL to my previous CL [1], which had a bug that InputMethodService#doStartInput() is now always called back twice. There was a careless mistake when rebasing the CL [1] onto the previous CL [2], which ended up with dispatching startInput() twice in IInputMethodWrapper. In short, InputMethod#dispatchStartInputWithToken() is the new way to dispatch startInput()/restartInput(). We do not need to call both of them. [1]: I9921b381e02106dbffff5e0b3d13f0a1245ce807 6db3bfe33d92127d203ec872a0b353585a99f256 [2]: I476d0cf8cbb0a0134941854f9337d9ad15e66a71 f7526b58960608887b064670bb42f41aa28b8f41 Test: Set true to InputMethodService#DEBUG and make sure startInput() and restartInput() are called in the following scenario. 1. Complete the setup wizard. 2. adb shell am start -a android.app.action.SET_NEW_PASSWORD 3. Proceed to "Choose your password" page 4. Make sure startInput() gets called only once. 5. Type "aaaa" then hit "CONTINUE" button. 6. Make sure restartInput() gets called only once. Bug: 35079353 Fixes: 35442939 Change-Id: Ifde16c3fad5b787d4c9a11bd886943dfe96f9eb9
* Track event flow to IMMS#setImeWindowStatusYohei Yukawa2017-02-131-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is part of work to introduce historical debugging infrastructure for Android IME. In this CL, we will focus on the following two event flows. A1. IMMS#attachNewInputLocked() queues MSG_(RE)START_INPUT to deliver new InputConnection/EditorInfo to the current IME A2. The IME triggers IMS#onStartInput()/IMS#onRestartInput() and updates the following fields: - InputMethodService#mStartedInputConnection - InputMethodService#mInputEditorInfo B1. IME is expected to call back IMM#setImeWindowStatus() to notify its window visibility change to IMMS. B2. IMMS updates the following field if the caller is still the current IME. - InputMethodManagerService#mImeWindowVis What this CL aims to do is to enable IMMS to access A1 state when it was in B2 state, by considering that for given a B1 the last A2 happened before B1 is the cause of B1 and B2. To do this, IMMS issues a binder token in A1 and each IME keeps it so that it can be passed in B1. By using this Binder token as a key, IMMS can keep tracking state snapshot taken from each A1. Note that those state snapshots keep alive until the Binder token's proxy in the IME process loses strong reference from its GC root. Test: Make sure `adb shell dumpsys input_method | grep mImeWindowVis` matches to the IME window visibility. Test: Make sure the current IME is not receiving any InvalidParameterException from IMMS. Bug: 35079353 Change-Id: I9921b381e02106dbffff5e0b3d13f0a1245ce807
* Merge restartInput into startInput in internal IPCYohei Yukawa2017-02-111-30/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is the 2nd attempt to merge restartInput into startInput in internal IPC after fixing the mistake in new parameter order in the previous CL [1]. As a preparation to start tracking all the event flows that cause InputMethodManagerService#setImeWindowStatus(), this CL merges an internal IPC method IInputMethod#restartInput() into IInputMethod#startInput() in favor of simplicity. This is a refactoring CL that should have no behavior change. [1]: Ifda6f74ac1b1370d9e9a9fe60354b692121fdcb9 1a5838e966eab7a9f0dca71cabbc9922babb995e Test: Set true to InputMethodService#DEBUG and make sure startInput() and restartInput() are called in the following scenario. 1. Complete the setup wizard. 2. adb shell am start -a android.app.action.SET_NEW_PASSWORD 3. Proceed to "Choose your password" page 4. Make sure startInput() gets called. 5. Type "aaaa" then hit "CONTINUE" button. 6. Make sure restartInput() gets called. Bug: 35079353 Change-Id: I476d0cf8cbb0a0134941854f9337d9ad15e66a71
* Revert "Merge restartInput into startInput in internal IPC"Yohei Yukawa2017-02-111-9/+25
| | | | | | | | | | | | | This reverts commit 1a5838e966eab7a9f0dca71cabbc9922babb995e [1]. Reason of revert: There was a mistake in the parameter order of MSG_START_INPUT. [1]: Ifda6f74ac1b1370d9e9a9fe60354b692121fdcb9 Test: none. This is a revert. Bug: 35079353 Change-Id: Ic1487768932febe0f1f1b6e71929464e91f357e0
* Merge restartInput into startInput in internal IPCYohei Yukawa2017-02-111-25/+9
| | | | | | | | | | | | As a preparation to start tracking all the event flows that cause InputMethodManagerService#setImeWindowStatus(), this CL merges an internal IPC method IInputMethod#restartInput() into IInputMethod#startInput() in favor of simplicity. Test: Done some quick manual testing to make sure that IME is still working Bug: 35079353 Change-Id: Ifda6f74ac1b1370d9e9a9fe60354b692121fdcb9
* Use a flag to grant a temporary URI permission.Yohei Yukawa2016-06-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that we can let the system to call InputMethodService#exposeContent(InputContentInfo, EditorInfo), which added in my previous CL [1], during the IME is calling InputConnection#commitContent() as follows. [IME] InputContentInfo contentInfo = new InputContentInfo( contentUri, new ClipDescription(description, new String[]{mimeType}), linkUrl); getCurrentInputConnection().commitContent( inputContentInfo, InputConnection.INPUT_CONTENT_GRANT_READ_URI_PERMISSION, null); [App] try { contentInfo.requestPermission(); // Load inputContentInfo.getContentUri() here. } finally { contentInfo.releasePermission(); } This gives us flexibility to let InputConnection#commitContent() do all the magic for IME developers like other APIs such as Context#startActivity(), rather than asking them to call one more API to grant a temporary URI permission like a scenario where Context#grantUriPermission() is used. [1]: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6 25e0813e6eb6315b1016db805fa9b791b4ae5cc2 Bug: 29450031 Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
* Tell IMS about missing InputConnection methods.Yohei Yukawa2016-03-151-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This CL introduces a unified mechanism to deal with the situation where the application directly implements InputConnection but some of methods are not implemented. Note that there should be zero overhead when the application extends BaseInputConnection or InputConnectionWrapper. Background: When ever we add a new method to InputConnection, there has been a risk that existing applications that directly implement InputConnection can get java.lang.AbstractMethodError exception at runtime, because older SDKs do not require the application developer to implement the methods that are newly added in later SDKs. Because of this we strongly discouraged developers to directly implement InputConnection interface, and encouraged them to subclass BaseInputConnection or InputConnectionWrapper instead. That said, as requested in Bug 26945674, there is a certain demand to be able to implement InputConnection without depending on BaseInputConnection. The goal of this CL is to provide a reliable and sustainable solution to above missing method scenario in InputConnection. One of the reasons why dealing with missing InputConnection methods is so difficult is that what InputMethodService receives to communicate with the target application is actually a proxy class com.android.internal.view.InputConnectionWrapper that runs in the IME process and immediately returns true for most of methods in InputConnection such as #commitText() and #finishComposingText(). Because of this asynchronous nature, it is too late to change the actual return value that the IME receives when the application receives those one-way asynchronous IPC calls. Solution: To handle those cases, this CL checks the availability of InputConnection methods that did not exist in the initial release before the target application calls startInput(), and let the application to send its availability bits to IMMS so that InputConnectionWrapper running in the IME process can be initialized with such availability bits. Note that we do know that BaseInputConnection and its subclasses support all the InputConnection methods, hence for most of applications we can just assume that all the methods are available without reflection. With such availability bits, InputConnectionWrapper is now able to gracefully return failure code to the IME because the availability of those methods is immutable, except for a tricky case where the application relies on a proxy object that dynamically changes the dispatch target. Here is the list of APIs that we start checking the availability in this CL. [API Level 9+] - InputConnection#getSelectedText(int) - InputConnection#setComposingRegion(int, int) [API Level 11+] - InputConnection#commitCorrection(CorrectionInfo) [API Level 21+] - InputConnection#requestCursorUpdates(int)} [API Level 24+] - InputConnection#deleteSurroundingTextInCodePoints(int, int) - InputConnection#getHandler() Ideas alternatively considered: Default methods in InputConnection We once considered having default methods in InputConnection but abandoned this idea because it does not directly solve the problem about how to tell the that the API does not take effect. Also having default methods would make it difficult for application developers to be aware of newly added methods in InputConnection. Bug: 27407234 Bug: 27642734 Bug: 27650039 Change-Id: I3c58fadd924fad72cb984f0c23d3099fd0295c64
* More work on voice interaction visuals.Dianne Hackborn2014-05-301-3/+4
| | | | | | | | | | | | | | | | | There is now a special theme for voice interaction activities to use, so they can be a panel that is better intergrated with the rest of the voice interaction experience. This is still not completely working, I have some hacks in the demo app to get it right; I'll fix that in a future change. Also improve VoiceInteractor to be retained across activity instances, for things like rotation. And bump up the number of concurrent broadcasts that are allowed on non-svelte devices, since they can handle more and this makes the boot experience better when dispatching BOOT_COMPLETED. Change-Id: Ie86b5fd09b928da20d645ec2200577dee3e6889d
* Fix possible NPE in IInputMethodWrapperSatoshi Kataoka2013-07-011-0/+8
| | | | | | Bug: 9093124 Change-Id: If62138a85e46f217ad2d3eda140715961006dcdc
* Use input transport for communications between app and IME.Jeff Brown2013-03-261-13/+39
| | | | | | | | | | | | | | | | | | | The input method manager service now supplies an input channel for communication while creating an IME session on behalf of the application. This change significanly reduces the overhead of IME event dispatch by using a standard input channel to send input events rather than using binder. This results in fewer thread context switches and fewer object allocations. What's more, the IME may perform additional batching of the motion events that it receives which may help it catch up if it is getting behind while processing them. Bug: 7984576 Bug: 8473020 Change-Id: Ibe26311edd0060cdcae80194f1753482e635786f
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 03:04:40 +0000