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
This CL removes CursorAnchorInfoRequest and related stuff
in favor of InputConnection.requestUpdateCursorAnchorInfo,
which is more easy to understand. This CL also deprecates
InputMethodManager#updateCursor and related stuff.
Rationale:
1. The spec of #updateCursor says that it provides the cursor
position in local coordinates, while the input method
requires it in the screen coordinates.
2. #updateCursor has never been enabled in AOSP, because
InputMethodManager#isWatchingCursor always returned false.
3. There has been no way to let
InputMethodManager#isWatchingCursor return true.
4. In L, InputMethodManager#updateCursorAnchorInfo is
introduced to address all the issues above.
Given that we no longer need to support #updateCursor,
CursorAnchorInfoRequest is overkill when we need to convey
just a couple of parameters.
BUG: 17185263
BUG: 17182367
Change-Id: I4a577bfd02b37b9e56c80b8b41bb25afa95dd8ef
This CL addresses feedbacks from internal customers for new
input method APIs that are mainly used for physical keyboard
support in L.
For performance reasons, #onUpdateCursorAnchorInfo is not called
back by default and each input method has to enable this
event notification explicitly whenever fine-grained character
locations are needed.
In L-preview, InputMethodSession#setCursorAnchorMonitorMode was
introduced for this purpose. However, we got several feedbacks
to be addressed.
- The effect of #setCursorAnchorMonitorMode is not preserved
during focus change. IMEs need to call
#setCursorAnchorMonitorMode every time when #onStartInput is
called. This is tricky and hard to understand.
- As #onUpdateCursorAnchorInfo is a new API, not all
applications/text editors have supported it. Therefore IMEs
can't always rely on it. However, there is no way to query
if the attached target is supporting this new API or not.
It would helpful for IME authors if we can provide a
reliable way to query if the attached input target is
supporting the new API or not.
In order to address these issues, the triggering method has
moved from InputMethodSession to InputConnection in this CL,
as an analogy of existing InputConnection#getExtractedText API,
which has provided similar functionality including optional
reactive event callbacks from the application to the IME.
BUG: 15812658
BUG: 16118603
Change-Id: I3c6b69bd9d79b199afe68d838f25effa6048e5cc
There is now a special theme for voice interaction activities
to use, so they can be a panel that is better intergrated with
the rest of the voice interaction experience. This is still
not completely working, I have some hacks in the demo app to
get it right; I'll fix that in a future change.
Also improve VoiceInteractor to be retained across activity
instances, for things like rotation.
And bump up the number of concurrent broadcasts that are allowed
on non-svelte devices, since they can handle more and this makes
the boot experience better when dispatching BOOT_COMPLETED.
Change-Id: Ie86b5fd09b928da20d645ec2200577dee3e6889d
New window layer that voice interaction service windows
go in to. Includes a new voice-specific content rectangle
that voice activities are placed in to.
Add specific animations for this layer, sliding down from
the top (though this can be customized by the voice interaction
service).
Also add the concept of activities running for voice interaction
services for purposes of adjusting the animation used for them,
again sliding from the top, but not (yet?) customizable by the
voice interaction service.
Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
This CL introduces a new API IMM#updateCursorAnchorInfo for
floating window support.
BUG: 14579622
Change-Id: I61dec2f8fa671ba891da1d4af08975750e3acb04
This makes VoiceInteractionSession a more first-class
concept. Now the flow is that a VoiceInteractionService
calls startSession() when it wants to begin a session.
This will result in a new VoiceInteractionSession via the
VoiceInteractionSessionService containing it, and the
session at that point an decide what to do. It can now
show UI, and it is what has access to the startVoiceActivity
API.
Change-Id: Ie2b85b3020ef1206d3f44b335b128d064e8f9935
Also adds a few missing styles and reorganizes some XML files. Makes
stackViewStyle public since it's defined in DeviceDefault.
Change-Id: I8f6a0f93410948b38619594474d60dc40ece5917
This is a follow-up CL for I3acf2317ae1d763d11 to improve the
Javadoc for CURSOR_ANCHOR_MONITOR_MODE_CURSOR_RECT
BUG: 14323360
Change-Id: Ie8948eda3ce57da282bd82e8e9a44997f6d53245
From its beginning, InputMethodService#onUpdateCursor has
provided the cursor position in local coordinates in the attached
view. However, the local coordinates is not useful for IMEs
to render a floating UI near the cursor because the IME is not
able to know the origin of the attached view.
With this CL, CURSOR_ANCHOR_MONITOR_MODE_CURSOR_RECT also means
that the IME will receive the cursor position in screen
coordinates. Because this is a new constant in the next release,
conditionally changing the coordinates never causes
compatibility issues as long as its behavior is well documented.
BUG: 14323360
Change-Id: I3acf2317ae1d763d11dae5ef73c2a1348b377c71
This CL introduces an API which allows IMEs to start/stop
receiving onUpdateCursor callback upon their request.
BUG: 13388665
Change-Id: I987326872def181dda5d9d701b762f088e0d9c39
