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
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
InputMethodService#onExtractedDeleteText doesn't reset composing
region and InputConnection#deleteSurroundingText deletes text around
the composing region. As a result, #onExtractedDeleteText can delete
unintended region of the text.
This happens when a user perform Drag&Drop or tap "Delete" in
SuggestionsPopup in full screen extracted mode.
Bug: 22440907
Bug: 27536702
Change-Id: I875f2919896f8ff453a77fb4a1b642ad78079b78
This is a follow up CL for the previous commit [1], which may have
triggered an unknown bug in either Android Framework or LatinIME.
[1]: Id4d332e3909590c68345e10e1f2e18650efb2eb7
7b739a802c
InputMethodService#mSettingsObserver is initialized in #onCreate() and
cleard with null in #onDestroy(). Hence hitting NPE against it implies
that InputMethodService#onEvaluateInputViewShown() can be called before
InputMethodService#onCreate() or after InputMethodService#onDestroy().
Both possibilities are equaly problematic. Note that this might be a
long-standing issue that just became obvious because of [1].
This CL does not attempt to fix the root cause but just tries to
suppresses the NPE to unblock QA tasks. A proper fix should be made in
subsequent CLs.
Bug: 22517687
Bug: 26511607
Change-Id: I6bc87c3d18b560fe2253fb9f05557b95b04d0cf0
Here is a brief history of "Use Physical Keyboard", or "Show input
method", or SHOW_IME_WITH_HARD_KEYBOARD.
In Honeycomb, we introduced a mechanism which allows users to temporary
disconnect the physical keyboard connection from a UI [1]. That state
was temporary and non-persistent, but it was implemented to have
system-wide effect. Whenever the user turned on that temporarily
disconnected state, not only IMEs but also other processes would be
notified that Configuration#keyboard was changed to KEYBOARD_NOKEYS.
The UI to do that was available only in tablet UI at that point and
nothing changed in phones.
In JellyBean, we decided to port that UI to phone, and the "Use Physical
Keyboard" toggle switch found its new home on the IME switcher
dialog [2].
In Lollipop, we revised the wording for the toggle switch on the IME
switcher dialog. Now it's labeled as "Show input method" [3].
In Lollipop, we also decided to make the settings of "Show input method"
to be persistent as @hide entry in the secure settings [4].
[1] 2992ea782f
I136087ca4f726d0068d5983d7d3686787ba60c55
[2] cb598b11ea
(Ica768083f95c33dc1e494a28ba7d8b6eb989b0ef)
[3] be11f3a5cea67c68a08c8da9ce85b3418501060a
(I9c8a7eb98b5277f1d09cc19fa7402e9b4cf51d92)
[4] b64e56aad3ffb267aec44308f57641a4c91caa83
(I2237ded850a0d4ab43ca441d0b7df13e0958e630)
Now, we have hard time making everyone happy. Having an easy way to
bring software keyboard back is probably still a valid use case, but
after several wording changes it is no longer obvious why
onConfigurationChanged() event is sent to all the processes as a
consequence of tapping that toggle.
In order to address above confusions, this CL removes the concept of
"temporarily disconnected physical keyboard" but tries to implement
"Show input method" functionality in InputMethodManagerService and
InputMethodService to keep the affordance that has been offered in the
IME switcher dialog. As long as the IME overrides
InputMethodService#onEvaluateInputViewShown() as follows, the behavior
of "Show input method" toggle remains the same except for processes
including IMEs no longer receive onConfigurationChanged() event with
faked Configuration#keyboard value.
@Override
public boolean onEvaluateInputViewShown() {
// If the default implementation returns true, recommend honoring
// it.
if (super.onEvaluateInputViewShown()) {
return true;
}
// Implement the logic that is specific to your IME here.
return myOnEvaluateInputViewShown();
}
Bug: 22517687
Change-Id: Id4d332e3909590c68345e10e1f2e18650efb2eb7
A recent change in how the handler is created in KeyboardView
caused the password change flow to crash in ChooseLockPassword.
Change-Id: Id5fcb256f9a09b75bf91c5c79614d8abfc29747f
This is a follow up for I2c21573cf972145ab08e66604cdb9344139a3f31, which
added BadTokenException handler so that we can deal with unavoidable
runtime exceptions. However, it turns out that CL does not work well
in a certain case.
One problem in I2c21573cf972145ab08e66604cdb9344139a3f31 that it added
the exception handler in the call site of
InputMethodService#showWindow(boolean) rather than callee side as
follows.
try {
showWindow(true);
} catch (BadTokenException e) {
if (DEBUG) Log.v(TAG, "BadTokenException: IME is done.");
mWindowVisible = false;
}
However, the above code fails to update #mWindowVisible if an IME
overrides InputMethodService#showWindow(boolean) but catch-and-ignore
BadTokenException as follows.
@Override
public void showWindow(boolean showInput) {
try {
super.showWindow(showInput);
// Do something if super.showWindow() succeeds.
} catch (BadTokenException ex) {
// Do something if super.showWindow() fails.
}
}
With this CL, InputMethodService#mWindowVisible is always updated in
the callee side whenever it should be.
Note that this CL does not change anything about which method can
throw BadTokenException and which method catch-and-ignores it so as
not to break existing IMEs unexpectedly.
Bug: 23798142
Change-Id: Id1e5f236f48c8ef01b7f157ba3f6e7ab2c26b135
This Cl is just a mechanical removal of redundant casts.
Nothing is changed logically.
Bug: 22285167
Change-Id: I460b781753553c002b6cd232ae5918b7acd616d9
This is just a mechanical merge of nested if statements with a dead code
removal. Nothing is changed logically.
Bug: 22285167
Change-Id: I28c1de84635b68108b25ec32ec58de2128758512
Replace text was handled by the original EditText; thus, we
couldn't correctly decide popup window position.
Also, changing selection range replaces entire text of the
extracted EditText. As a result, text cannot be replaced
with the selected item when there is a selection.
This change is a workaround for this issue. This quits
offering "Replace" for selection in extract mode.
Bug: 22038802
Change-Id: I052b027cfd10eeb289f77f4c6b228acf58fea636
Stop calling onExtractTextContextMenuItem if "Select All"
is selected (the action does not modify text thus does
not need batch editing). Editor#finishBatchEdit reports
that text changed which in turn can stop the action mode
and the selection after it was started by onPreDraw.
Bug: 22059417
Change-Id: I5354cbe4bae374e0d5f3de39616336170ee33b92
Need to update fullscreen state on hiding window as well as showing
window, otherwise IMM#isFullscreenWindow reports obsolete state after
hiding window by back key or device rotation.
Bug: 22238567
Change-Id: Ic8de161cd5d2ee161f32b9942cdc2c331ea4d48e
In extract mode, on every screen touch
TextView#setExtractedText gets called which calls
SpannableStringBuilder#sendTextChanged which in turn stops
the action mode. As a fix, if the text is the same only
copy the spans without replacing everything.
Bug: 22315095
Change-Id: I28da760b3dc11e1cfbaf720e547bd817c5b89d7e
This CL is a follow up to I7998c8ee2162a0e01525a0cd66ec14fa505,
which completely removed ExtractActionMode including back key
handling in InputMethodService when full-screen mode is enabled.
It turns out that back key events still need to be handled in
InputMethodService when full-screen mode is enabled so that
users can still cancel floating text action mode with back key.
Bug: 22034992
Change-Id: I5f8db34f7425eef343d40d9820925ea6aaf9fccc
Select with double tap in extracted mode has suffered
a regression recently: flickers and it does not correctly
select. Found this fix after a lot of trials.
Bug: 20128047
Change-Id: I1bbe8c11982d37e5409bac2b648a31b0ca1f0bbc
The boolean parameter of Keyboard.Key#onReleased(boolean) has
been somehow ignored since Capcake. With this CL, that method
starts working as documented.
Alternatively we could fix the issue when and only when the
application's targetSdkVersion >= 23. We didn't do that because:
- Although Keyboard.Key class is a public API, it is supposed to
be used almost only by android.inputmethodservice.KeyboardView.
The risk of unwanted compatibility problems is low.
- Fixing that is beneficial for users because it actually fixes
UX issue when applications/IMEs that still rely on KeyboardView
run in Android M.
- All the fields that are related to Keyboard.Key#onReleased are
public fields so developers can easily work around anyway.
Bug: 21446448
Change-Id: I392166c77cd9dd2c432dc4f1274312f8355de02b
Use the floating toolbar action mode instead.
This change is identical to 7315b15a034eeb2d9a4cd24c100023c048ca
(minus string changes). Due to scary conflicts in strings I will
make the string changes in the next CL.
Change-Id: Ia66ef5e886df1fc42a8e1ba52d77141e1e88dbd4
Use the floating toolbar action mode instead.
This CL is identical to ag/701639. The merge to master was skipped
due to a conflict. This is the 'manual merge'
Bug: 20128047
Change-Id: I5ef9b4b5b9574a4a360a853b2d1abd5b374f2fd5
This is a follow up CL for Ib04967f39b2529251e4835c42e9f99dba2cf43f2.
As well explained in the I2c21573cf972145ab08e66604cdb9344139a3f31,
the race condition here cannot be avoided without an unacceptable
performance penalty. For now, we follow the same way.
Bug: 21600287
Change-Id: I0ffdf8bf7e8a53cf8aba1339024b32da65d4f32d
When we got rid of the paste popup, we merged it into the Selection
ActionMode and moved all its invocations to the ActionMode. Some apps
actually want the paste popup without the Selection ActionMode, hence
separating them again allows them to cancel the one they want.
Bug: 21571422
Change-Id: I91bcd0d9c3e68d9c736698fe0bec010b4c9f5cf3
In the following scenario, the system continues keeping the previous
IME's inset in the display until the new IME shows its window.
1. an IME shows its software keyboard with reporting non-empty inset.
2. the user switches to another IME, which does not show the software
keyboard when it is selected (e.g., because the physical keyboard
is connected.)
This CL tries to address above situation by introducing a new state
flag IMMS#mShouldClearInsetOfPreviousIme to clear the previous IME's
inset when necessary.
Bug: 15922840
Change-Id: Ib04967f39b2529251e4835c42e9f99dba2cf43f2
To change the back icon, need to notify IME visibility to the
InputMethodManagerService when guest IME service calls showWindow().
IME can call showWindow() if it want to show software input, but it
doesn't send IME_VISIBLE state to the InputMethodManagerService,
hence the arrow icon is different from what we expect. This
typically happens when Latin IME shows Emoji panel by left-alt keys.
Bug: 20318050
Change-Id: I0ec2c71ad9bc3b7e9259d9180375d9062fc7e154
When marking text and opening the edit text dialog
and then rotating the device would result in references
being kept to the edit text dialog and the memory would
never get released again.
Change-Id: I3e95083e4923844d2b496ea79174ef97e77f8686
OnComputeInternalInsetsListener is added when initViews is called,
and initViews is called by onCreate and onConfigurationChanged.
But it is removed only by onDestroy.
Therefore listeners are accumulated and it results performance issue.
So before adding, remove mInsetListener that was previously added.
Change-Id: I494d3f1875613d73d3f9b8e2af286b5800f03196
