Due to more complex window layouts resulting in lots of overlapping
windows, the policy around FLAG_WINDOW_IS_OBSCURED has changed to
only be set when the point at which the window was touched is
obscured. Unfortunately, this doesn't prevent tapjacking attacks that
overlay the dialog's text, making a potentially dangerous operation
seem innocuous. To avoid this on particularly sensitive dialogs,
introduce a new flag that really does tell you when your window is
being even partially overlapped.
We aren't exposing this as API since we plan on making the original
flag more robust. This is really a workaround for system dialogs
since we generally know their layout and screen position, and that
they're unlikely to be overlapped by other applications.
Bug: 26677796
Change-Id: I9e336afe90f262ba22015876769a9c510048fd47
Add handling of "replacement" key events in InputReader and EventHub by
consulting device's character key map (if exists) for presence of
replacement key code for given get code and meta state combination,
before passing it to InputDispatcher.
This enables defining special keys, such as ESC, on keyboards lacking
enough physical keys, via combination of normal keys and modifiers, for
example AltR + 1 => ESC.
Bug: 24504154
Change-Id: I7e36104808bedcf724436c1fbb63d37c35cca8af
This reverts commit 9b70ab7a3cb260205e81e40ba181a86710d2eb95, reversing
changes made to 153008efb5a00ed3c18d588ce15f90d2442a9786.
Bug: 24302031
Change-Id: Ia746381b30be3b54cb646ed412b7271962c4b02a
* commit '7c000280a57f352c2485dcaea1d5bfe20f7bfe63':
Fix input tests to work with new MotionEvent member
Revert "Revert "Add new MotionEvent actions for button press and release.""
Introduce ACTION_BUTTON_PRESS and ACTION_BUTTON_RELEASE as actions to
signal a button press or release. If these actions happen
simulanteously with a DOWN or UP event then they're explicitly
ordered to happen after the DOWN or preceding the UP in order to send
them to the most recently targeted view.
Also, introduce new stylus button constants that differ from the
constants we use for mouse buttons.
Bug: 20704355
Change-Id: Ib960a5004db5429ad2fc8db020704773e2978327
Occasionally we'll receive the stylus up signal (pressure = 0) before
we receive the touch screen up signal. Rather than giving pointer a
pressure value of 0 (which is one of the signals of hovering) or
falling back to the touchscreen pressure values (which would make for
an inconsistent stream), use the previous pressure value which should
always be non-zero for a stream of fused data.
Bug: 20449776
Change-Id: I71eb97e7c4ea53e42b0eb54fc1f8ae7f89aad9d1
Even when there isn't movement on the touchscreen we should produce
events for pressure and button state changes generated by external
stylii.
Change-Id: I9fd7ba85902d5d6bfb28d5e5ff5d8f340a94c2bf
Temporarily increase the stylus timeout while we figure out where the
delay in BT information is coming from.
Change-Id: I27ab5a4db4ad14358c6e6803961612420371fce9
Sometimes stylus data will be delayed by 30 - 40ms. By increasing the
timeout we pretty much always pick up stylus data and the touch
latency feels surprisingly small.
Change-Id: I39f5b9037ce0444b1e957149d3f1c3a3137804cb
This prevents us from dropping any states (namely the pressure
transition from non-zero to zero) if we get the touch up before we
get the stylus data.
Change-Id: Ifc198628d35b7079dc5ec23d81f9681d122757a0
To avoid nan or infinity when orientation value is used for
calculation without being initialized, check mOrientedRanges.haveOrientation
value before using mOrientedRanges.orientation.min or .max value.
Change-Id: I68ed9ab36819c5faa6422e9f061e1275aeed11e3
Signed-off-by: Baik Han <baik.han@lge.com>
Tests always get built with the platform now anyways. Also, remove
the dependency on libandroidfw since it causes issues on PDK builds.
Change-Id: Ib73ec620abac3782d9fdae48778064c06b30aae0
When the touch firmware or driver sends a key event that is triggered
by a low-level gesture such as a palm slap. For this to work, the
touch device's .kl file must specify the "GESTURE" flag for each
key that is produced by a gesture.
Note that the "VIRTUAL" flag should also be specified for any such
keys for which we would like to generate haptic feedback.
eg. key 142 SLEEP VIRTUAL GESTURE
Bug: 19264992
Change-Id: Ief494ec7e3ca66d2358a1001fdfae4f263ee1cd1