Bug 3381317
Changes made in https://android-git.corp.google.com/g/#change,91880
displayed the IME onFocus. However, the test was not consistent to what
is done in touch event. textIsEditable is now checked too.
Change-Id: If11382c1c90a557839b87d62494253470c42b621
This fixes a bug introduced in 3c6dd8f9 because we now
have two shift keys. The code now tracks a global state
and looks for up to two shift keys.
Update after review and added code to handle extra
invalidate required by additional shift key.
Change-Id: Ic1728dd0ceec089089cd1beca1b0b30565d6e658
This enables the system bar to carve out a region through which
events will be sent to the IME behind it.
Bug: 3238092
Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
BREAKING CHANGE: Redesigned the key character map format to
accomodate full keyboards with more comprehensive suite of modifiers.
Old key character maps will not work anymore and must be updated.
The new format is plain text only and it not compiled to a binary
file (so the "kcm" tool will be removed in a subsequent check-in).
Added FULL keyboard type to support full PC-style keyboards.
Added SPECIAL_FUNCTION keyboard type to support special function
keypads that do not have any printable keys suitable for typing
and only have keys like HOME and POWER
Added a special VIRTUAL_KEYBOARD device id convention that maps
to a virtual keyboard with a fixed known layout. This is designed
to work around issues injecting input events on devices whose
built-in keyboard does not have a useful key character map (ie.
when the built-in keyboard is a special function keyboard only.)
Modified several places where events were being synthesized
to use the virtual keyboard.
Removed support for the "qwerty" default layout.
The new default layout is "Generic". For the most part "qwerty"
was being used as a backstop in case the built-in keyboard did
not have a key character map (probably because it was a special
function keypad) and the framework needed to be able to inject
key events anyways. The latter issue is resolved by using the
special VIRTUAL_KEYBOARD device instead of BUILT_IN_KEYBOARD.
Added the concept of a key modifier behavior so that
MetaKeyKeyListener can distinguish between keyboards that use
chorded vs. toggled modifiers.
Wrote more robust key layout and key character map parsers
to enable support for new keyboard features and user installable
key maps.
Fixed a bug in InputReader generating key ups when keys
are released out of sequence.
Updated tons of documentation.
Currently QwertyKeyListener is being used for full keyboards
with autotext and capitalization disabled. This mostly works
but causes some problems with character pickers, etc.
These issues will be resolved in subsequent changes.
Change-Id: Ica48f6097a551141c215bc0d2c6f7b3fb634d354
Bug 3064925
Instead of always passing the menu item to the original TextView, do that only
for the 'Select word' option. More ExtractEditText magic, but this ZBB so...
Change-Id: Ic4cb0526dbb9711e2f13a916b997f480307dcad1
- added showInputMethodSubtypePicker to public API
-- show the selector dialog for subtypes
- added getter, setter and event handler to InputMethodManagerService
- extract InputMethodSubtype to the top level class for using it in aidl
- TODO: make an enabler for input method subtypes
- TODO: handle the event of changing an input method subtype in LatinIME
Change-Id: I49f8c6675ac4b06511635d14a37bd398738eff33
Change insertion point on tap is no longer handled by the CommitSelectionReceiver
(as it is not called by ExtractEditText).
Fixed a bug to handle drawing positions when the internal TextView scroller is used.
Change-Id: I87398c7109c5527d21dee6abbdb925848244d594
singleLine flag is set to false by default. However, when no singleLine or input
type is provided, the inputType of the TextView is not set to
EditorInfo.TYPE_TEXT_FLAG_MULTI_LINE for edit texts.
Change-Id: Id747d3319afcddb3ab6ae0463947e8b3e470ef73
Do not correct the touch point if it is within the range of
verticalCorrection from the top of KeyboardView, so that the touch
point will not have negative y-axis value.
Bug: 2659128
Change-Id: I91a3e65fc5dee1383dbbfb45690e307fc0adc1d1
Fixes a memory leak when input methods are switched. Uses a variety of methods
to avoid holding a reference to the InputMethodService which created the binders,
which was leaking those InputMethodServices.
See http://code.google.com/p/android/issues/detail?id=6661 for reproduction steps.
Set a 70ms debounce time - i.e., if you spend less than 70ms on the touch-up key,
which was less time than the time spent on the previous key (assuming they weren't the same),
then don't emit the last key. Use the previous key that you lingered on for longer.
- Added new PasswordEntryKeyboardView to internal/widgets. Widget supports:
- alpha mode with symbols (latin-1 only).
- a numeric keyboard
- IME emulation that applies keyboard input to arbitrary top-level view widget.
- Added new transparent assets to framework resources.
- Modified Keyguard and Keyguard layouts to use new PasswordEntryKeyboardView.
Merge commit 'ace8addce47efc03be5038eef48d7fb066b14aae'
* commit 'ace8addce47efc03be5038eef48d7fb066b14aae':
Create a new ImeOption that disables fullscreen in landscape, and use it.
EditorInfo:
Add a flag to tell the InputMethodService to never go into fullscreen
mode.
InputMethodService:
When the new flag is set, onEvaluateFullscreenMode always returns
false.
WebTextView:
Use the new flag, along with IME_FLAG_NO_EXTRACT_UI. Fixes
http://b/issue?id=2358360
Sometimes quickly touching the screen with two fingers will result
in the firmware thinking one finger moved very quickly. This code
tries to identify the difference between the two based on velocity
of the last N points versus the velocity of the last M points and
figure out if there was mostly acceleration or a sudden deceleration.
It's still not perfect and very dependent on the touch hardware.
This takes care of allowing us to cancel the back button. The
back button is a bear because it is strewn all over the place --
everywhere you can close something, there is some code looking
for the back button that now needs to deal with being canceled.
The main things changed are activity (of course), dialog,
input method, search dialog. There are some other misc places
in the framework (and some I missed here that I will get in a
second pass).
To facility all of this, the key dispatching APIs now provide
a lot more support for dealing with looking for cancelled keys,
and incidentally also provide an actual API for catching long
key presses. This also helped clean up the code in PhoneWindow
where it deals with all of the combinations of key pressed and
releases. (And also allows people to override
Activity.onKeyLongPress() to provide a different long press
action for a standard key like search.)
And while I was doing this, I reworked how we detect long
presses by having this be part of the key event delivered by
the window manager. This should greatly reduce (hopefully
outright eliminate) the problems with long presses being
mis-detected when an application is being slow.
Change-Id: Ia19066b8d588d573df3eee6d96e1c90fdc19f57d
