d8d03a8e1b added new methods to
InputMethodService.
Allowing IME developers to override some of these methods would introduce
unnecessary complexity. Making these methods final makes sure developers
cannot inject some unexpected behavior when called by system.
Bug: 73701052
Test: atest InputMethodServiceTest
Test: atest CtsInputMethodServiceHostTestCases
Change-Id: I1af4ed05a0b7306d840a21129e921a57b4a5fc33
onWindowShown is more like it should called after mWindow.show()
in InputMethodService. Considering the compatibility problem, just
make its javadoc clearer to the IME developers rather than
change the calling order.
Bug: 72922821
Test: N/A
Change-Id: Ibfe20f40a65475f39c8e79d10e2c494e212cf054
Signed-off-by: tiansiming [田思明] <tiansiming@xiaomi.com>
InputMethodService.setBackDisposition() has been broken from a long
time. This is how setBackDisposition() is supposed to work
1. BACK_DISPOSITION_WILL_DISMISS:
When Keyboard is visible back button will show as down arrow (in
navigation bar) and tapping it will dismiss keyboard.
2. BACK_DISPOSITION_WILL_NOT_DISMISS:
When keyboard is visible, back button will be shown as BACK arrow and
tapping it will send the back event to current activity. If activity
doesn't handle onKeyDown() for back button, activity will finish and
keyboard will hide.
Note: backDisposition flags reset when finishInput() is called.
Bug: 38513361
Test: Manual with apk attached in bug
Test: atest InputMethodServiceTest
Change-Id: I99e7c413fe1a93f8d8cff897b5c5f0947690d2c0
This is a follow up CL to a recent CL [1], which aimed to move several
APIs only for InputMethodService from InputMethodManager to
InputMethodService.
This CL removes InputMethodService#hideSoftInputFromInputMethod(),
which is exactly the same as InputMethodService#requestHideSelf() that
is already available as a public API for IME developers.
This CL also virtually renames
InputMethodService#showSoftInputFromInputMethod() to
InputMethodService#requestShowSelf(), which has existed as a
private method but not been exposed to IME developers yet.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
Bug: 70282603
Test: atest CtsInputMethodTestCases
Change-Id: If6a786c5774805d041ea9672ef2721e4a38df7fc
This is a safe refactoring that should have no behavior change in
terms of semantics and performance characteristics.
Test: make -j checkbuild
Change-Id: I30b40c483e490ff42c1c707233ca5cc7b67da28f
This is a follow up CL to a recent CL [1], which deprecated several
APIs InputMethodManager class but forgot to update some of existing
call sites in InputMethodService to use new method names.
This CL only addresses deprecated API usage warnings. There should be
no behavior change.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
Bug: 70282603
Test: atest CtsInputMethodTestCases
Change-Id: I709ca997523ac9a9cd2d236f3158bbb18cf2edc3
With this CL, DecorView#mNavigationGuard that handles navigation bar
only for IME windows [1] is finally gone and replaced with the
standard mechanism to handle navigation bar layout padding /
background color.
This CL addresses multiple anomalies regarding how the following APIs
work for IME windows.
* Window#setNavigationBarColor()
* Previous behavior:
- Only works for Color#TRANSPARENT [2].
- Ignores FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS.
* New behavior:
- Works as documented.
- Requires FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS to work.
* SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION flag
* Previous behavior:
- The system automatically sets
SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION to the IME windows [3].
- Does not work as documented. Content area is not extended to the
navigation bar area.
- Manually unsetting SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION can cause
unexpected layout, because the system expects that this flag is
always set to the IME window.
- Had a special logic for FLAG_LAYOUT_IN_OVERSCAN [4].
* New behavior:
- Works as documented.
- Can set/unset as necessary.
From the viewpoint of IME developers, this CL enables IME windows to
* correctly extend the input view to the navigation bar region by
using SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION as documented, instead of
relying on a special hack with FLAG_LAYOUT_IN_OVERSCAN hack.
* use Window#setNavigationBarColor() to easily change the navigation
bar background color, like other non-floating windows.
Note that SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR is not yet supported for
IME windows, which will be implemented in a subsequent CL.
[1]: I6a93f30aec83f1cecfb854073046cbc87ab4aa66
ae3349e1c3
[2]: Iea77915ecc55eedaf19899e72c44f704ba9d852c
0a9d1ea015
[3]: I460912ee7c117480c57b947ed31eca330819f32c
c68d577f29
[4]: Ic38f204a892bf34e8dae65990d5aa8c95af555d8
9b32a35aa7
[5]: I4b10a19641bd3ce6c43e7629404b6f202d4186e8
Fix: 25706186
Bug: 69002467
Test: ThemedNavBarKeyboard sample [5] works for the following cases
* Extended Dark Navigation Bar
* Separate Dark Navigation Bar
* Floating Mode (if the target app uses dark navigation bar)
Change-Id: I664630099b6eb3fe31675444ba94944cb0eb98b0
InputMethodManager is public InputMethod API for apps. The methods
that take Window-token as parameter are restricted to system
and/or IME developers. Such methods should really live
in InputMethodService.
This CL deprecates such methods in IMM and moves them to IMS.
This is the first step towards simplifying IME APIs.
Bug: 70282603
Test: atest InputMethodManagerTest
Change-Id: I3163f3cbe557c85103ca287bee0874a3b4194032
Now before we fire an a11y event we check if this event has an
observer. As a bonus we don't push the state to clients if the
dynamic service config did not change.
Test: cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases
bug:69427760
Change-Id: Ie208e13b8557bb7a120198a43efcb79c2752f5db
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
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
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
Consider this VirtualDisplay (VD) scenario:
HostActivity creates a VD which holds SettingsActivity. When EditText
on SettingsActivity is tapped, it gains focus.
On eventual taps, it loses focus i.e. the Window in VD loses focus and
the host activity in primary display gets the focus instead. This
happens because WM's TaskTapPointerEventListener.onPointerEvent()
is called on the default display only.
Root cause:
1. Tap detector isn't registered for non-default display.
2. Tap detector has no info on which displayId touch was received.
3. InputFlinger doesn't deliver InputMonitor events for
non-default displays (fixed in a separate CL)
Fixing above results in onPointerEvent(MotionEvent) to deliver the
Touch events successfully to VD. We restrict these changes to physical
multi-displays and VR VirtualDisplays (which uses virtual touch device).
[VrManagerService calls WMInternal.setVr2dDisplayId(int)]
In future, displayId should be part of InputEvent. Bug: 64258305
Bug: 62033391
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I3626f4de5aa9bcf905da9abd39f3ab1baefc4c48
Percentage-base sizes involving screen height are incorrect for watch
devices with non 1:1 display metrics. These are round screens with an
inactive bottom portion. To maintain the correct proportions the
bottom inset must be added to the height.
BUG: 36728475
Change-Id: Ibe351d1db7964b4b89ce9a588c171cd8407e2a50
This will now be controlled by individual accessibility services.
We'll provide the password information to them, and they can
present or hide the information as it makes sense for their users.
Password information was anyway provided when a headset was
connected.
Bug: 28139568
Test: Manually verified that TalkBack now speaks passwords on the
lock screen and in text views. Since I'm removing functionality
that didn't have tests, it's tricky to have specific tests.
Change-Id: Ic3c724ccce5762ee9dcd9e7dcbd4eae6734dd05e
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
6db3bfe33d
[2]: I476d0cf8cbb0a0134941854f9337d9ad15e66a71
f7526b5896
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
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
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
1a5838e966
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
This reverts commit 1a5838e966 [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
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
As explained in the commit message of my previous CL [1], we have
had a design issue in how to notify the full-screen mode change
from the IME to InputMethodManager running in the target application.
Histrically we have done this by using hooking the following IPC
from the IME to the target application.
InputConnection#reportFullscreenMode()
However, since we also want InputConnection to be deactivated in some
situations such as the when the target application is no longer
focused. In other words, InputConnection is not a reliable way to
notify something.
As a result, we have suffered from many stale state issues.
Bug 21455064 and Bug 28157836 are such examples. In Android N, we
introduced yet another hack to work around those issues, but it is
really time to fix the protocol design instead.
The new strategy is to rely on internal IPCs provided by
InputMethodManager to deliver such critical notifications from one
process to the other. This is actually more natural because our goal
is to make sure that InputMethodManager#isFullscreenMode() always
returns the latest value as long as the caller is the focused
application.
For backword compatibility, applications that are monitoring
this callback should continue working, as InputMethodManager emulates
the previous behavior. However, as updated in JavaDoc, IMEs are no
longer allowed to invoke InputConnection#reportFullscreenMode(),
which should be OK because even on previous releases IMEs should rely on
InputMethodService#updateFullscreenMode() instead.
[1]: Iba184245a01a3b340f006bc4e415d304de3c2696
1544def0fa
Fixes: 28406127
Test: Make sure Bug 21455064 is still fixed.
1. Input some words in extract mode.
2. Select a word.
3. Perform copy.
4. Select a word.
5. Rotate the device.
6. Try to select a word.
7. Make sure he word is selected and action mode starts.
Test: Make sure Bug 28157836 is still fixed.
1. Rotate device to landscape mode.
2. Tap on EditText and start full screen extracted mode.
3. Rotate device to portrait mode.
4. Long press to start action mode.
5. Make sure Action mode gets started.
Test: `adb shell dumpsys input_method` to make sure that fullscreen
state is synchronized across the app, IMMS, and the IME.
Change-Id: If23e7c7c265ab3dfb48c2fb6fdb361b17d22c594
This CL hides warning and info log messages from
InputMethodManagerService (IMMS) and InputMethodService (IMS) behind
DEBUG flag like other logs unless the state is certainly unusual.
Of course the definition of "unusual" is still an open question, but
basically that we should not see any suspicious message from IMMS/IMS
just by turning on a new phone, launching some applications, typing
something, and turning off the device. IMMS and IMS should expect all
events that can (easily) occur in that scenario, and no log is
necessary for such things.
Note that warnings suppressed with TODO comments will be tracked
under Bug 34851776 (and Bug 34886274).
Test: adb logcat -s InputMethodManagerService:* InputMethodService:*
to monitor log in the following scenario:
1. Boot the device.
2. Complete the setup wizard.
3. Launch Dialer and type something on it.
4. Launch Contacts app and type something on it.
5. Try some special modes:
- Turn on/off display
- Recents screen
- Split-window mode
- Guest user
- Multi user
- Direct-boot (setup a device password and reboot)
except for logs about actual IPC calls from a background user.
Bug: 34838583
Bug: 34851776
Bug: 34886274
Change-Id: I3fcdeb919bb2f2940da9ff45e17ac00baa1253f4
This makes it clear that on Android L+ devices IME developers basically
no longer need to call InputMethodService#enableHardwareAcceleration(),
because it is deprecated in Android L[1][2]. On L+ devices what IME
developers need to do is to make sure that their IMEs are compatible
with both hardware and software rendering so that the system can choose
the best rendering method.
This is basically a code clean-up that should not change any actual
behavior.
[1]: I906d48cb07af50fa02dae4f4ecdb5e65211fc6ef
5e1565ead6
[2]: I126ea823eb2eeabb29d30999dec9c9411b33b315
e07b595519
Bug: 31202732
Change-Id: I416669b172737e3eb3d77165dcea50289d207514
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
25e0813e6e
Bug: 29450031
Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
This is a follow up CL to my previous CLs [1][2] that introduced
InputConnection#commitContent(InputContentInfo, Bundle) API to enable
IMEs to send a content to the target application.
With this CL, IME developers are able to temporarily expose
InputContentInfo object to the target package without permanently
granting URI permission. Although calling IMS#exposeContent() is
allowed only for the IME that is currently selected, the client is able
to request a temporary read-only access even after the current IME is
switched to any other IME as long as the client keeps InputContentInfo
object.
Here is a sample code snippet about how to use this mechanism.
[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
exposeContent(contentInfo, getCurrentInputEditorInfo());
getCurrentInputConnection().commitContent(inputContentInfo, null);
[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}
[1]: Iaadf934a997ffcd6000a516cc3c1873db56e60ad
152944f490
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588
Bug: 29450031
Change-Id: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
This is a follow-up to my previous CL [1] for Bug 15922840 so that we
can clear the following variables in a more reliable way.
- PhoneWindowManager#mLastInputMethodWindow
- PhoneWindowManager#mLastInputMethodTargetWindow
The idea behind CL [2] is that when InputMethodManagerService (IMMS) is
switching from an IME to another IME, IMMS can send a signal to
WindowManagerService (WMS) to remember the current IME's inset so that
the system can continue using it to reduce jank until the new inset is
specified by the next IME. As summarized in Bug 28781358, however, if
the next IME does not show the window after the IME switch, WMS (or
PhoneWindowManager to be precise) keeps using the previous IME's inset
unexpectedly until the new IME shows its window. All we have seen in
Bug 15922840 and Bug 26663589 fall into this category.
The idea of this CL is just adding a hidden API to InputMethodManager so
that InputMethodService#clearInsetOfPreviousIme() can surely terminate
the IME transition state managed in PhoneWindowManager, rather than
relying on a hack of calling SoftInputWindow#show() and
SoftInputWindow#hide(), which actually does not work for Bug 26663589.
[1]: Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
[2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
Note that addressing all the corner cases in [2] still requires lots of
non-trivial change. Hence this CL focuses only on Bug 26663589 (and
the case we handled in Bug 15922840).
Bug: 26663589
Change-Id: Ib567daa009c1139858dccadcfc6a04465ebecf36
This bug was a corner case of stopping lying about
Configuration#keyboard when "Show software keyboard" is turned on, which
was done by my CL [1] in Android N development cycle.
Previous implementation
if (config.keyboard != Configuration.KEYBOARD_NOKEYS) {
had relied on the fact that the system was lying about config.keyboard,
which is no longer valid. We need to change the behavior of
InputMethodService#onShowInputRequested() depending on
Settings.Secure.SHOW_IME_WITH_HARD_KEYBOARD like we did for
InputMethodService#onEvaluateInputViewShown() in [1] to minimize the
impact on stopping lying about Configuration#keyboard.
[1]: Id4d332e3909590c68345e10e1f2e18650efb2eb7
7b739a802c
Bug: 28423439
Change-Id: I8a774cbf61ac706d8446be91b17bceee57a13656
Provides an alternate presentation of the extract edit area
of an input method window, designed for sub 250dp width screens.
An icon is used on a round material style button in place of a text
action, providing more horizontal space for the editing area.
BUG: 28098677
(cherry picked from commit fd71a6a5d99bad5d3ab32edc328fb5b026b66215)
Change-Id: I0e559d17f78d1a48b37979a49e11ae1aad7503f4
This reverts commit 880602eb64 [1],
which was committed with a wrong author email address and lacked license
notice in some files. To avoid confusion, this we decided to
temporarily revert that CL so that we can commit it with proper license
notice and author address again.
[1]: I16226ce393f2d15065d08e66a36d008eb1a0c8a1
Bug: 22512982
Bug: 28098677
Change-Id: I3dd3c7bf0ee9634fc4f3bf433bf5023675873e46
Provides an alternate presentation of the extract edit area
of an input method window, designed for sub 250dp width screens.
An icon is used on a round material style button in place of a text
action, providing more horizontal space for the editing area.
BUG: 22512982
Change-Id: I16226ce393f2d15065d08e66a36d008eb1a0c8a1
(cherry picked from commit fd71a6a5d99bad5d3ab32edc328fb5b026b66215)
This is a follow up CL to my previous CL [1], which caused a regression
that LatinIME does not correctly initialize its UI when:
1. Make sure SHOW_IME_WITH_HARD_KEYBOARD is off.
2. Pair a hardware keyboard.
3. Reboot.
4. Make sure the hardware keyboard is paird.
5. Focus in a text box.
6. Make sure that LatinIME does not show software keyboard.
7. Tap the IME switcher and turn of "Show Input Method" toggle.
Previously IMS had called many methods from
IMS#onConfigurationChanged(), which was just replaced with
IMS#restartInput() by my CL [1] then broke some assumptions in LatinIME.
This could also break other IMEs' assumptions as well.
To avoid unexpected regressions between M and N like this, this CL
ensures that those methods are called as we have done until [1].
[1]: Id4d332e3909590c68345e10e1f2e18650efb2eb7
7b739a802c
Bug: 26985193
Change-Id: Iebd98f26d388b64cb318ac202b3bcdd956bd3a27
As a preparation to fix bug 26985193, this CL fixes a bug that
IMS#ShowInputFlags is never updated. As a result,
IMS#onConfigurationChanged() has always called
IMS#onShowInputRequested() with specifying 0 to flags parameter, which
is wrong.
With this CL, we can assume that IMS#mShowInputFlags keeps tracking the
last value when it should do. Also, we can remove IMS#mShowInputForced
since it is now determined by IMS#mShowInputFlags.
Bug: 26985193
Change-Id: Ieff634b69ce941d78ffe208547f7edd19ea28643
