IMS might throw IllegalStateException in
WindowContextController#attachToWindowToken when #initializeInternal
is called. A possible root cause may be #initializeInternal is called
after onDestroy, which detach IMS from ImeContainer.
This CL add a flag in #onDestroy to prevent #initializeInternal from
being called after #onDestroy.
Bug: 211062619
Test: presubmit
Change-Id: Ie7814da801878a3487123fefdc9e71d0e1ed28d7
This CL introduces a new runtime mode where the SysUI no longer
renders the back button and the IME switcher button when the IME is
shown, which is the first milestone to move those buttons to the IME
process.
To enable this mode, run the following commands:
$ adb root
$ adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
$ adb reboot
Keep in mind that you always need to reboot the device after changing
this sysprop.
Note that only AOSP-based gestural navigation mode is officially
supported by this flag, which is when
com.android.internal.R.integer.config_navBarInteractionMode
is set to
WindowManagerPolicyConstants#NAV_BAR_MODE_GESTURAL.
Note that nav button rendering in the IME process is yet to be done in
subsequent CLs. Hence the expected behavior right now is only one
thing that the SysUI stops rendering the back button and the IME
switcher button any more when the flag takes effect.
The flag is treated as off by default. Hence there should be no
visible behavior changes unless you manually enable it.
Alternatives Considered:
Instead of letting NavigationBarView directly read the sysprop, we
could propagate the information from the InputMethodService to the
SysUI via InputMethodPrivilegedOperations#setImeWindowStatusAsync().
This approach was abandoned because of the following reasons.
* Such a complex mechanism is not necessary for production code.
* There are some ad-hoc invocations of
IMMS#updateSystemUiLocked(0, mBackDisposition),
which makes it difficult to keep IMS and SysUI in sync.
Bug: 205803355
Test: Manually done as follows
1. Build aosp_coral-userdebug and flash it
2. Tap any edit field to show AOSP Keyboard.
3. Confirm that nav buttons are rendered in 3-button nav mode
4. Switch to gestural navigation mode.
5. Confirm that nav buttons are still shown when IME is visible.
6. adb root
7. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
8. adb reboot
9. Tap any edit field to show AOSP Keyboard.
10. Confirm that nav buttons are not shown when IME is visible.
11. Switch to 3-button navigation mode.
12. Tap any edit field to show AOSP Keyboard.
13. Confirm that nav buttons are shown again when IME is visible.
14. Switch to gestural navigation mode again.
15. Confirm that nav buttons are not shown when IME is visible.
Change-Id: I7a2e9f08072a97d61b78dddb144282a5728d1407
Introduce InputMethodManager.startStylusHandwriting(View) API
and IME lifecycle.
Bug: 203086136
Test: atest StylusHandwritingTest
Change-Id: I7b066c2841b713e7a00ae2ea4ca0ce04aad751c6
This is a follow up CL to my previous CL [1], which made it clear that
the following 4 tracing fields in SoftInputWindowProto had always been
logged with the same values.
- name: "InputMethod"
- window_type: WindowManager.LayoutParams.TYPE_INPUT_METHOD
- gravity: Gravity.BOTTOM
- takes_focus: false
This CL simply deprecates those fields in favor of simplicity and
smaller code size.
There should be no behavior change unless IME tracing is enabled.
[1]: I619ae6011f5e66dba126931719569a97513eaa7e
ea7801bd26
Bug: 192412909
Test: IME tracing still works
Change-Id: I04b59307ecf2c692282c7882ac839f77c94b938f
This CL merges
SoftInputWindow#initDockWindow()
into
InputMethodService#onCreate()
so that we can see what parameters are set to the IME window at a
glance, rather than having to check 2 different files.
The end result is expected to be the same, and in theory there should
be no observable behavior change.
If you are reading this commit message to look for why those
parameters have been set, here are some quick links to relevant CLs.
* `FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS`
- DecorView#mNavigationGuard is gone [1]
* `window.setDecorFitsSystemWindows(false)`
- Updated InputMethodService to not inset by navigation bar if
requested by automotive. [2]
- Smooth out IME animation for automotive devices [3]
* `setFitInsetsTypes(statusBars() | navigationBars())`
- Do let IME fit invisible insets [4]
* `setFitInsetsSides(Side.all() & ~Side.BOTTOM)`
- Make IME fit navgation bars at left and right sides [5]
* `receiveInsetsIgnoringZOrder = true`
- Let IME receive insets ignoring z-order [6]
[1]: I664630099b6eb3fe31675444ba94944cb0eb98b0
8f162c6e84
[2]: I4faf82bdd7536bd2d049ded04034a9635d8ca0d3
7eec316f54
[3]: I5d7b03d5c829a2679efdd06fa961d1158494e08f
b0d0d7c46a
[4]: I6e7d665c55839dfbb14c8d2e5365537416f5f6c6
145f71182a
[5]: I0ef3d6379a9ae52b3749154d2fdc54e9aa94a9e0
c8364e3878
[6]: I53c64a5598f246ad577f652156903e4666a30cd9
ea491da863
Bug: 192412909
Test: presubmit
Change-Id: If0f2bac45e6752612cc11e57d2fac55626221bd1
Now that SoftInputWindow is used only by InputMethodService [1], we
can safely simplify SoftInputWindow.
This is still mechanical refactoring. There should be no observable
behavior change.
[1]: 5ed8dae6bc9cca87d5f35e781f173477a2388c2e
Bug: 192412909
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/SoftInputWindow.java
Change-Id: I619ae6011f5e66dba126931719569a97513eaa7e
This is a mechanical refactoring CL as a preparation to remove the
dependency on
android.inputmethodservice.SoftInputWindow
from
android.service.voice.VoiceInteractionSession.
Before creating a copy of SoftInputWindow for VoiceInteractionSession,
this CL aims to clean up lint errors and style nits as many as
possible, notably:
* Addressing lint errors
* Adding missing @Override
* Making SoftInputWindow a final class
* Making internal member fields private
* Removing SoftInputWindow#{get,set}Gravity(), which are no longer used
* Renaming SoftInputWindowState to WindowState
There should be no observable behavior change in this CL.
Bug: 192412909
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/SoftInputWindow.java
Change-Id: I547489d3946bf523a59ada80f63cfd934e70c1f4
The flicker happens when the app in landscape mode with focusing the
search editor without enabling full-screen editText, after typing something
and pressing search button, the app quickly clears the editor focus then
makes the main activity focused and starts the fallback connection to
enable the fullscreen mode, so that the extracted view been inflated and
occcupied in mFullscreenArea,
Even though the full-screen mode changed to false during hiding the
keyboard, in updateExtractFrameVisibility() still makes mFullscreenArea
visible and flicker until the keyboard is hidden.
As the mFullscreenArea contains 2 frames: ExtractFrame & CandidateFrame,
Since ExtractFrame is used when enabling the full-screen editor mode,
for non-full-screen mode, we can rely on the candidate frame visiblity
to see if mFullscreenArea has to set visible, in case flicker happening
by unnecessary visible setting.
Fix: 211085869
Test: manual as steps:
1). Set device dark theme is on.
2). Open Messages on Landscape mode > Split screen.
3). Tap Search box > input something.
4). Tap Search icon on keyboard.
5). Expect no flicker happens when hiding the keyboard after 4).
Change-Id: I0d50ae68016993329e8bb84b90ec835445f3db31
IME_VISIBLE isn't set until the keyboard is "perceptibly" visible to the user (e.g. based on alpha). But we want to signal to taskbar as soon as we know IME will be visible.
Test: tap an edit field to open keyboard, ensure taskbar reacts immediately instead of halfway through the transition
Bug: 202511986
Change-Id: I39c15578ed3e5b729f4645ad76988b113f0b57a6
Historically TextView#setText() has internally called
InputMethodManager#restartInput(View)
simply because the text seen from the IME is going to be out-of-sync.
Although this behavior is semantically helpful for IMEs, especially
after the initial surrounding text information became available in
EditorInfo, issuing a sync IPC from the calling thread (UI thread
actually) is not plausible from the performance perspective.
This CL fills this gap by adding a new API
InputMethodManager#invalidateInput(View)
for the scenario where apps independently modify the text with keeping
other text metadata such as input-type to be the same.
All the observable behaviors from the IME remain to be the same as
InputMethodManager#restartInput(View).
For instance, any pending tasks that are already issued with
InputMethodService#getCurrentInputConnection()
will be effectively cancelled by using a recently added mechanism [1].
[1]: I383c3958d2ac1a8d217706509fa12a92b381bbb3
Fix: 203086369
Test: atest -c CtsInputMethodTestCases:InputMethodStartInputLifecycleTest
Change-Id: I3161755779080f98bcef0e47dd0c5247d8a3a256
Add the TextAttribute class and variant of setComposingText(),
setComposingRegion(), commitText() to support IME to take extra
information to editor.
Bug: 198732184
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest CtsInputMethodTestCases:TextAttributeTest
Change-Id: Ic9c917b70726ca32c2097b0374951c20af9624c4
Originated from CL[1] to fix a crash edge case that happened when
calling InputMethodPrivilegedOperationsRegistry#put that assumes there
is only one pair of window token and IInputMethodPrivilegedOperations
in the container.
However, InputMethodPrivilegedOperationsRegistry is a process-level
singleton instances that may run into a timing when there are 2
InputMethodService (IMS) instances, one is just created and the other
is in the way of destorying.
Before the destorying one calls
InputMethodPrivilegedOperationsRegistry#remove, IMS#initializeInternal
invoked for the new one with the same window token, that makes system
ignored the initialization process because CL[1] introduced
InputMethodPrivilegedOperationsRegistry#isRegistered(token) and system
thoughts the token has been registered before, but actually this method
is problemetic to aware this token registraction is for previous IMS.
As the result, IME will crash when SoftInputWindow.show because the
windowState is still under TOKEN_PENDING and lose the token attachment.
To fix this crash timing issue, making
InputMethodPrivilegedOperationsRegistry be able to maintain more than
one pairs of IME token and IInputMethodPrivilegedOperations makes more
sense and we can remove the ignore logic in initializeInternal to
fix the token attachment issue.
[1]: Ie6bfbae735724fe744590e715124d2737d2b665d
Fix: 202081442
Test: atest CtsInputMethodTestCases
Test: atest MultiDisplaySystemDecorationTests
Change-Id: I21cec3f228520ed703cd8ad68ea0ef59c966ed9d
Binder tracing can be very expensive. In dogfood builds its triggered
time to time and it should only be called manually when needed.
Fix: 202721321
Test: atest CtsInputMethodtestCases
tested with winscope trace.
Change-Id: I0a4ee1b90e56ed1b20e44b5a0b42c17d565d05dd
This is a follow up CL to my recent CL [1], which aimed to consolidate
dependencies on InputMethodService from RemoteInputConnection.
One thing I overlooked was that InputMethodService did not retain a
strong reference to InputMethodServiceInternal object that I
introduced there, which means that the newly instantiated
InputMethodServiceInternal could be garbage-collected even before
InputMethodService became unreachable.
As a result, the following InputConnection APIs could start failing at
some point and would never work without restarting the IME, which is
likely to be the root cause of the recent flakiness in
InputConnectionEndToEndTest discussed in Bug 193822485.
* InputConnection#requestCursorUpdates()
* InputConnection#commitContent()
Also, the following functionality might have stopped working at some
point.
* InputMethodService#dump()
* InputConnection tracing in IME tracing
* Updating IME switching order based on user inputs
With this CL, the InputMethodServiceInternal instance is guaranteed to
be instantiated once and remain to be alive until
AbstractInputMethodService becomes unreachable.
[1]: I2aeeeacd27195ce10059d6590e098a4a969e774d
a975bfc447
Fix: 193822485
Fix: 199288389
Test: atest CtsInputMethodTestCases
Test: Manually verified with Imege Keyboard sample IME/app
Change-Id: I7ee0270bad94ed606048bfaf76e8545336715d83
We concluded that the behavior of sendDefaultEditorAction should be kept
for compatibility. To compensate that, we should update the javadoc to
reflect the current behavior.
Test: None
Bug: 28898996
Change-Id: Idcb2b7180f9e22818ab819715fe2723a05b4894a
This is a follow up CL to our previous CL [1], which introduced
early-exit paths to some RemoteInputConnection methods to protect
innocent IME clients from unexpected process crashes when an IME is
calling InputConnection APIs with invalid parameters.
Although protecting IME clients from crashes still makes much sense,
implementing it as an early-exit style in RemoteInputConnection may
expose observable inconsistency to IME developers in terms of the fact
that InputConnection#getText{Before,After}Cursor() can also work as a
fence operation that would not return until all the previously issued
InputConnection API invocations are handled in the IME client side.
With this CL, the following methods start behaving as a fence
operation even when an invalid parameter is passed, by checking the
parameters in the IME client side.
* RemoteInputConnection#getTextAfterCursor()
* RemoteInputConnection#getTextBeforeCursor()
* RemoteInputConnection#getSurroundingText()
There should be no performance impact for IMEs that do not make such
an invalid (and unnecessary) API calls.
[1]: I95169735198f8363c981a61e20234dfebfd645b1
1e72ef2893
Bug: 169114026
Fix: 194110780
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Change-Id: Ie0c18d0c9b8bf8f02f2fcdca5aac7e580c6bf2cd
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
19a80a1e80
Bug: 27407234
Bug: 27642734
Bug: 27650039
Bug: 194110780
Test: atest CtsInputMethodTestCases
Change-Id: I9e801e92496a6e16cee37664870c97ed096f1413
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
eadb1392f8
Bug: 192412909
Bug: 194110780
Test: presubmit
Change-Id: I90eff3bfc5ed0f43472b0cd49aa532474a60c266
This is a follow up CL to my previous CL [1], which used
MissingMethodFlags mechanism [2] to let that API fail when the IME and
the target app are not running on the same display.
As discussed in Bug 194110780, however, there is a problem in the
MissingMethodFlags mechanism that it could have caused unexpected task
reordarings from the IME developer when sync InputConnection APIs
immediatelly fail without waiting for those tasks to be scheduled to
the target app then handled.
As a preparation to fully deprecate MissingMethodFlags, this CL
enables InputMethodManagerService to stop lying about
MissingMethodFlags.REQUEST_CURSOR_UPDATES
when the IME is rendered on a diffirent display than the target app.
Such check is now explicitly implemented in
RemoteInputConnectionImpl.
Other than that, there is no observable behavior change.
[1]: Ie2f7a5117cff3a13ad5c5806fd4b3abef7569549
3d2cc0fffd
[2]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e80
Bug: 131368625
Bug: 194110780
Test: atest CtsInputMethodTestCases
Test: atest MultiDisplaySystemDecorationTests#testCrossDisplayBasicImeOperations
Change-Id: Iec12733d37e112b7271436bba15094ae2a55a450
This CL consolidates weak-ref handlings in RemoteInputConnection so
that IME developers can find more useful messages in logcat when they
are using RemoteInputConnection after InputMethodService#onDestroy().
RemoteInputConnection has been designed to not hold a strong reference
to its parent InputMethodService instance.
While IME developers can manually keep a strong reference to
(Remote)InputConnection object that they obtained from
InputMethodService#getCurrentInputConnection(), doing so does not
prevent the system from garbage-collecting InputMethodService
instance.
With this CL, an error message will be shown in logcat if somehow
RemoteInputConnection object is still touched after InputMethodService
is destroyed, which hopefully can help IME developers realize they
might be doing something unexpected.
Other than showing error messages in logcat, there is no behavior
change in this CL.
Bug: 192412909
Bug: 194110780
Test: atest CtsInputMethodTestCases
Change-Id: I514630d27c8953f62fdb34cd3133a662b3fbbf76
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
