| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
This CL undoes part of [1] making removing a local variable.
[1]: Id4c85be1c0eab51f167ba00fc355386f852c424d
Test: make
Change-Id: I6b890e5536c17dd53722e2c3a781c85dd9d6bdf0
(cherry picked from commit d90033999f0282cb1a5d70c66f8102dde3ea58b0)
Merged-In:I6b890e5536c17dd53722e2c3a781c85dd9d6bdf0
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes an issue where if the mServedView gets detached, but a different
view was already set as the mNextServedView, the next served view gets
mistakenly cleared as well.
Fixes: 216548832
Bug: 211105987
Test: atest ImeFocusControllerTest
Change-Id: I3fe42bcb5b08158cbdbf261ba0227075464ffe4c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since when bring an existing app task to foreground or quick switching
app task with gesture navigation will first see the task snapshot
during app transition,
If the task previously focused and shown IME, even the task may hide
IME when switching to the next task, As the goal of
go/ime-transition-improve-s mentioned, if the task is still focused by
editor, we should keep the original focused IME shown and keep
the input connection focused state when navigating back to the
original task.
Bug: 166736352
Test: atest CtsInputMethodTestcases
Test: manual by focusing app with an editor to show keyboard,
switch the app task to the next with gesture nav and then
switched back, expected the soft-keyboard is still shown.
Change-Id: I63b144bed6c37569d79fba1c2b63dd4f1074f0f6
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Revert^2 "Verify lifecycle test when screen on/off"
c2769e41ea17d7f0d261396d28ddde3563422701
Reason: Fix forward Bug 174512702 and Bug 174445559
with CL[1].
CL[1]: Icf1504d40b25fc5f53eae65d4bab48a3070db1d6
Change-Id: Id4e71a822bfde5fe6a263bbe094c0d238017efe1
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "Verify lifecycle test when screen on/off"
Revert submission 12716106-ims_screenstate_lifecycle
Reason for revert: b/174512702
Reverted Changes:
Iba0332ed3:Verify lifecycle test when screen on/off
I8a657e75e:Let IME#onFinishInput called without dup onStartIn...
Change-Id: I16f4a34360a2f64b69978724648a9be741f140b5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also called IME#onStartInput without dup onFinishInput when screen-on,
to fix the long-standing IME input connection lifecycle issue when
device screen state changes.
Bug: 156215187
Bug: 26851566
Test: atest InputMethodStartInputLifecycleTest
Test: manual as below steps
0) Enable InputMethodService debug flag.
0-1) In Settings -> Develop options -> AppCompatibility Changes,
Select Gboard and then toggle
"FINISH_INPUT_NO_FALLBACK_CONNECTION" change.
1) Launch a app with focused a editor and show soft-input
2) When device screen turned-off, will see InputMethodService only
callbacks below logs:
CALL: doFinishInput
CALL: onFinishInputView
CALL: onFinishInput
3) When device screen turned-on, will see InputMethodService only
callbacks below logs:
CALL: onStartInput
CALL: onStartInputView
Change-Id: I8a657e75e274d842fb46b60375f6aeafeab96a59
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL implements a mechanism to dump IME related client states into
a proto file which can later be imported to winscope to allow easy
debugging. A new abstract class ImeTracing.java declares the methods
related to scheduling, collecting and dumping logs. Two child class
implement these methods for server and client separately.
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: Ia89f11d5ef8a220ea7746191b18769cea5a8359d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dismissing a dialog with EditText focused and keyboard shown,
the keyboard does not get correctly dismissed.
This happens because after CL[1] landed, returning to the activity won't start
new input connection, and the activity will thus not regain control over
the IME.
This fix restores the previous behavior, where IMM will start a fake input
connection even without an editor.
[1]: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1
Fix: 161273049
Test: atest CtsInputMethodTestCases
Test: manual as follows
0) Have some files downloaded in the device
1) Launch Files app > Browse > Click Internal Storage
2) Long press on any file > From menu, click "Rename"
3) Enter some name with soft keyboard and click "OK"
4) Expect Keyboard should hide
Change-Id: I022ad658844142ff4a4cf3b91953013f2bfbb58a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As CL[1] we introduced WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR start
input reason to ignore start new input when the focused view is
same as current served view and the input connection remains the same for
prevent additonal onStartInput / onFinishInput callback to
InputMethodService.
The main idea in the CL is good but how to judge whether the input connection
remains the same is not accurate.
CL[1] only checking if IMM#mServedInputConnectionWrapper self and its
input connection instance is stil exists, that breaks the following cases
to start new input:
Case 1:
- When device screen off / on to go back to focused app, this case will
fit WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR use case, so
IMM#mServedInputConnectionWrapper won't be deactivate and clear, this
makes wrong when user taps IME picker dialog to switch IME, will hit
again WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR and never start new
input for new IME.
Actually, in InputMethodManager has an ad-hoc check mRestartOnNextWindowFocus
to start new input when device screen off / on case and switching IME,
we should not ignore start input since that will conflict with the above
case.
Case 2:
- As served view is now tracked by ImeFocusController which is per-window
based instance from the IME focus handling refectoring CL[2],
but InputMethodManager instance is still per-display based, so
IMM#mCurrentTextBoxAttribute might be changed when the same app clinet has
multiple IME focusable window focus changed, because focusing to the next
IME focusable window will start new input connection and changes
IMM#mCurrentTextBoxAttribute, so when focusing back to the
original window, the served view in the original window's
ImeFocusController will same as focused view, in that case if we didn't
check if IMM#mCurrentTextBoxAttribute is really aligned with the given
focused view, will mis-judge start new input timing and caused user can't
type because the input connection state is obsoleted.
Those cases can be addessed by using new introduced method
IMM#isSameEditorAndAcceptingText, if the focused view is not aligned
with same editor or the editor is inactive, we should start new input
for Case 2, that also can fix Case 1 that we previously ignored starting
new input when switching IME.
Beside, we also found CL[3] leverages
InputMethodManager#mRestartOnNextWindowFocus to start new input when window focus
changed, since originally this ad-hoc check is only used to re-start input
for Case 1.
As we re-visited the necessary start new input scenerio is only when:
- Device screen off -> on
- Switching IME
- the input connection obsoleted
(this also includes when window focus changed)
As the result, we can remove all unnecessary logics in IMMS
instroduced by CL[1] and remove unnecessary
InputMethodManager#mRestartOnNextWindowFocus from CL[3], and preserve
the behavior is almost same as Q.
[1]: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
[2]: Ib455704fe1e9d243f93190a84f230210dbceac2a
[3]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
Fix: 160391516
Bug: 158624922
Bug: 152373385
Test: atest FocusHandlingTest
Test: atest InputMethodServiceLifecycleTest
Test: manual for case 1
0) pre-install 3rd party IME app
1) launch message app and taps Search bar to focus.
2) turn off screen
3) turn on screen to back to focused app
4) press IME switch icon from nav bar
5) choose next IME, expect the IME should be changed.
Test: manual for case 2
0) Sample app with 2 activites, each activity the layout has
EditText
1) Launch activity A, focus EditText
2) Launch activity B and focus EditText
3) Press back key to back to activity A
4) Verify if typing with keyboard is workable.
Change-Id: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we tried CL[1] to fix Gboard Translation UI dialog dismissed that
keeping the served view when focused to the next window,
although we can skip starting new input when the window focused back as
the behavior of Q,
However, we overlooked in R, IME insets will rely on IMS#reportStartInput
to get the updated IME input target, which will out of sync for the above
case.
To fix this regression, we report the next window focus gain
to IMMS with WINDOW_FOCUS_GAIN_REPORT_ONLY when the next focused view is
same as current served view and the served input connection remains.
so that in IMMS side won't get StartInputFlags.INITIAL_CONNECTION flags
to set restarting as false when calling IInputMethod#startInput to IMS,
and in IMS side will still call reportStartInput to WMS for updating
IME input target without additional onFinishInputView callback to
client.
[1]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
Fix: 152373385
Bug: 155781821
Test: atest CtsInputMethodTestCases
Test: manual, make sure Bug 155781821 comment #10 works:
1) Launch video call in Hangouts.
2) End call.
3) Click on the text box.
4) Expect Soft-Keyboard shown
Test: make sure not break Bug 148489857 and Bug 148788569, following
auto / manual test to verify:
- Auto: atest FocusHandlingTest#testKeyboardStateAfterImeFocusableFlagChanged
- Manual:
1) Build / install EditTextVariations
2) Select menu -> Direct-Reply, make sure Notification comes up.
3) Tap EditText on Notification, verify soft-keyboard is visible.
Change-Id: I45a9814d812ad906f417c24200fd4219959e2423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0df8812486ff0b104622dec72d6243a783b10257.
The original CL is trying to reduce the dependency of PownerManager to
finish input when screen off by using display state.
However, it doesn't fully fix the original Bug 26851566 since we only
finish input connection but didn't callback onFinishInput callback for
IME client.
Also, for some scenarios, the window / view focus may not change
during screen turns off / on:
- Focusing timing when disable keyguard, then quickly screen off / on.
- Using P-sensor to turning screen off / on.
When the above scenario happens, makes input connection cannot re-start
and soft-keyboard can't be shown.
(The recovery is manually focus on next window or activity.)
As the above reason, we need to re-consider the lifecycle of
input connection, window / view focus when not only screen state but also
device inactive state when always-on-display.
Fix: 156045961
Fix: 154605805
Bug: 26851566
Bug: 156215187
Test: atest CtsInputMethodTestCases
Change-Id: If06daf71160aa44a4254ac125561974ecbdef4f2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a56779d1ab1f73385881cab4a945f376df27a84c [1].
Reason for revert:
Caused multiple test failures in CtsInputMethodTestCases
[1]: I68bb95fc3cbfe1f5992ccf87694b34c3e52bb31f
Bug: 153612876
Fix: 154250671
Test: atest CtsInputMethodTestCases
Change-Id: Ibf6143f46ae18e41e8ecfa50f523216e7340adda
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ImeFocusController#onPostWindowFocus -> onViewFocusChanged,
it implies that the view has focus after onPostWindowFocus, this logics
we keep leveraged from IMM#onPostWindowFocus -> focusInLocked() long
ago, which may not always be true as SearchView layout may call
View#clearFocus when size changed after IME switcher shown.
When IME switched and back to app activity, in the above call path,
even activity window focused, and set the fallback focus view as
activity's root view, but the root view is not actually focused,
if we set this view as the next served view, then calling
View#onCreateInputConnection will return null, because it's not an editor.
Use correct view focus state when calling onViewFocusChanged.
Fix: 153612876
Test: manual as below:
1) Launch Files app, taps SearchView EditText
2) switch IMEs with IME switcher dialog
3) see if Password keyboard shown.
4) keeps 2) and 3) several time.
Expected: There is no password keyboard and
the keyboard input is still workable.
Change-Id: I68bb95fc3cbfe1f5992ccf87694b34c3e52bb31f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When introduced ImeFocusController, we originally would like to
resolve CL[1] enabling IMM#focusOut issue to archieve auto-hide IME when
no more view with focus.
However, some problems that we end up to disable because:
1) Bug 152230171 shows the current view focus may be cleared temporary
when in touch mode, closing input at this moment isn't the right way.
2) Bug 148974380 hits a case when tapping SearchView which is inside
of ListView, several focus in/out events comes up and may break input
connection unexptectly because wheather the next served view is no longer
coming or not is unpredictable from this callback.
Even we fixed the issue with CL[2] to tweak the next served view as
null only when the current served view lost focus, we still can't
guarantee that input connection won't break when current served view
lost focus by moved to other focusable view (e.g. popup window)
3) Setting the next served view as null when no more served view should
be handled more conservative in other special events
(e.g. view detached from window or the window dismissed).
[1]: I2228ae0c48ad3d9e0b55875f0dcb5ef8c55b0c5f
[2]: I9e90428387fcf43fbf86a8407de7535913202872
Bug: 152698568
Test: atest FocusHandlingTest
Change-Id: I6e38c4425233cea4b0a90285a2dc476b76c20979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mNextServedView is set to null when the next view focus is lost.
but we should not set mNextServedView as null when received the
next view focus is lost but the view is not the current served view.
It can happen when received next view focused but input connection will
disconnect when mNextServidedView is null.
The issue is found when the Activity has ListView which added SearchView
as a list item.
When the Activity is launched, input connection will be started when
activity window focused and served view will be SearchView since search
view request focus by default, then when user taps SearchView,
several view focus in/out events comes out quickly that may cause
mNextServedView set to null when the conteiner View lost focus, so input
connection will be disconnected since ImeFocusController#checkFocus checked
there is no next served view.
The fix is to set mNextServedView as null only when the current served view
loses focus.
Fix: 148974380
Test: atest FocusHandlingTests
Change-Id: I9e90428387fcf43fbf86a8407de7535913202872
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ImeFocusController#onScreenStateChanged callback for ViewRootImpl to
callback the screen state for ImeFocusController, and then check the served
view to finish input connection when the screen state is off.
With this change, we can remove InputMethodManagerService#setInteractive
related codes, since we still can finish current input connection
once the device is screen off, ensures the security behavior remains
the same.
This change is expected to reduce accumulated technical debt introduced
by [Prior works] to address multiple edge cases [1][2][3][4], especially
around window focus changes and display-off events.
[Prior works]
[1]. Re-start input when the IME is deactivated but window is focused
(Bug 6188159)
I9189e6d2ac90aa8c621fdb44989728101e00329d
31e4e149941e34cd135dfa0b6d918cc0b3dabbbc
[2]. Fix a crash in InputMethodManager when switching the IME in the
system process
(Bug 6789252)
I66f51da1299532793ef8fa700f35b0811670f235
4e5184f929d2498714bc7734fe10b9b8810cb071
[3]. Call startInput on return from sleep mode
(Bug 17558972)
I95d05110bc1cf310fad23ea1bcbc5890f642d1fc
82ae3ff4cf268f577e19c410b120314cdc11a191
[4]. Make IMM more robust to spurious window focus-in
(Bug 26851566)
I60adb38013b063918b074c7b947649eada77b2c8
8e9214b4bd7e6a9d944ad1527199226e575a7530
Note that one behavior change is that when the screen is on and window focus
back to the app, if the app previously did't request show soft input explictly,
InputMethodManager will not request to show soft-keyboard explicitly for the
next served view.
Fix: 26851566
Bug: 141738570
Bug: 9216494
Test: atest SearchViewTest, FocusHandlingTest
Test: atest ActivityViewTest, MultiDisplayClientTests,
MultiDisplaySystemDecorationTests
Change-Id: Ic11956fe745a829da1ec7c09ea214e9b3961c8e0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 970d9d2 introduced IME focus controller which
added a new method View#hasImeFocus to restrict IME focus
only when the focused window won't have either FLAG_NOT_FOCUSABLE
or FLAG_ALT_FOCUSABLE_IM flags.
Since NotificationShadeWindowController will unset both flags when
RemoteInput active (or when PasswordEntry focused on lockscreen).
But, in ImeFocusControler#onTraversal won't keep update View#hasImeFocus
state, it will affect IME focus handle correctness.
Hence, it needs to fix View#hasImeFocus state update issue.
Fix: 148489857
Fix: 148788569
Bug: 141738570
Test: manual as following steps:
Case 1:
0) make EditTextVariations
1) adb install -r EditTextVariations.apk
2) adb shell am start -n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
3) Tap the 3-dot menu on the EditTextVariations
4) Tap `Direct Reply` on the menu
5) Open notification drawers
6) Try to direct-reply on the notification, expect soft-keyboard should come up after step 6)
Case 2:
1) Device set up with Pwd lockscreen security. Finish setting up the device.
2) Once the device goes into sleep mode > Wake up the device > Swipe up locksreen.
3) Observing that the keyboard should come up consistently.
Change-Id: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Although it makes sense to not get IMM delegate every time, the
instance may need to be refreshed if the associated display is
changed because InputMethodManager returns different instance for
different display.
Fix: 148189172
Test: atest MultiDisplayClientTests# \
testDisplayIdUpdateWhenImeMove_NoRelaunchActivity
Change-Id: Id4c85be1c0eab51f167ba00fc355386f852c424d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make sure onCheckIsTextEditor should be called on the UI thread for
preventing exception in some cases that will break start input background
thread.
- Refine IMM#checkFocus and DelegateImpl#startInput to be out of
lock object to prevent start input background thread may blocked by other
methods which already inside the lock.
- Cache InputMethodManagerDelegate object for ImeFocusController#getDelegate.
Fix: 147447217
Bug: 141738570
Test: manual as test steps:
1) Launch Keeeps app, type some web-URL link.
2) Long press on any URL link > From the toolbar select "open / browser"
and observe.
3) Expect the soft-keyboard should be hidden after entering the
browser page.
Test: atest CtsInputMethodTestCases
Change-Id: I098df41f935438bf1889fb030c7a3e7a0645a168
|
|
|
Introduced ImeFocusController to manage
IME focus target and retrieve IME target event from ViewRootImpl.
With this CL, removed InputMethodManager focus check related methods
and replaced with below methods in ImeFocusController:
- onPreWindowFocus
- onPostWindowFocus
- onViewFocusChanged
- onViewDetachedFromWindow
- onWindowDismissed
- onProcessImeInputStage
Since all methods are guaranteed to interact within View or
ViewRootImpl with UiThread, so it also benefits that we can without any
lock protection, and ViewRootImpl will no longer depend on
InputMethodManager methods call in the end.
Also, Add mHasImeFocus in View.AttachInfo, for propogating if this view's
window is IME focused, if so, View#notifyFocusChangeToInputMethodManager
-> ImeFocusController#onViewFocusChanged will be called to
notify the focus change to corresponding IME focus controller.
Bug: 141738570
Test: atest SearchViewTest, FocusHandlingTest
Test: atest ActivityViewTest, MultiDisplayClientTests,
MultiDisplaySystemDecorationTests
Change-Id: Ib455704fe1e9d243f93190a84f230210dbceac2a
|
