Bug: 5011907
Introduce a 150ms delay in handling volume down keys
while waiting to see if a power key will follow.
Don't trigger the screenshot chord if both volume up and
volume down are pressed together.
Don't trigger the long-press power menu if volume keys are
also pressed.
Require the user to press both keys in the chord within
the debounce time and continue long-pressing them in order
to trigger the screenshot action.
Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
Bug: 5156144
Input channels could leak or simply live longer than they should
in some cases.
1. Monitor channels (used by the pointer location overlay) are never
unregistered, so they would leak.
Added code to handle failures in the receive callback by closing
the input channel.
2. The DragState held onto its input window and application handles
even after the input channel was disposed.
Added code to null these handles out when they are no longer needed.
3. Input channels previously used as input event targets would stick
around until the targets were cleared (usually on the next
event).
Added code to detect when the input dispatcher is in
an idle state and to proactively clear the targets then
to ensure that resources are released promptly.
4. Native input window handles held onto the input channel even
after the input window was removed from the input dispatcher.
Consequently, the input channel would not be disposed until
the input window handle itself was freed. Since the input
window handle is held from managed code, this meant that the
window's input channel could stick around until the next GC.
Refactored the input window handle to separate the properties
(info) and identify (handle) state into different objects.
Then modified the dispatcher to release the properties (info)
when no longer needed, including the input channel.
7. The pointer location overlay does not actually use its
standard input channel, only the monitor input channel.
Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to
request that they not be provided with an input channel
at all.
Improved some of the error handling logic to emit the status
code as part of the exception message.
Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
Bug: 5049148
Finished stylus support, including support for indirect stylus
and mouse tools.
Added TILT axis. When stylus tilt X/Y is available, it is transformed
into an orientation and tilt inclination which is a more convenient
representation and a simpler extension to the exiting API.
Touch devices now only report touch data using a single input
source. Previously touch devices in pointer mode would report
both absolute touch pad data and cooked pointer gestures.
Now we just pick one. The touch device switches modes as needed
when the focused application enables/disables pointer gestures.
This change greatly simplifies the code and reduces the load
on the input dispatcher.
Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE
would be zero whenever the stylus was in direct contact. It appears
that the correct way to determine whether the stylus is in direct
contact (rather than hovering) is by checking for a non-zero
reported pressure.
Added code to read the initial state of tool buttons and axis values
when the input devices are initialized or reset. This fixes
problems where the input mapper state might have the wrong initial
state.
Moved responsibility for cancelling pending inputs (keys down,
touches, etc.) to the InputDispatcher by sending it a device reset
notification. This frees the InputReader from having to synthesize
events during reset, which was cumbersome and somewhat brittle
to begin with.
Consolidated more of the common accumulator logic from
SingleTouchInputMapper and MultiTouchInputMapper into
TouchInputMapper.
Improved the PointerLocation output.
Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
Bug: 5064702
Introduced the concept of an InputListener to further decouple
the InputReader from the InputDispatcher. The InputListener
exposes just the minimum interface that the InputReader needs
to communicate with the outside world. The InputReader
passes arguments to the InputListener by reference, which makes
it easy to queue them up.
Consolidated all of the InputReader locks into one simple global
Mutex. The reason this wasn't done before was due to potential
re-entrance in outbound calls to the InputDispatcher. To fix this,
the InputReader now queues up all of the events it wants to send
using a QueuedInputListener, then flushes them outside of the
critical section after all of the event processing is finished.
Removing all of the InputMapper locks greatly simplifies the
implementation.
Added tests for new stylus features such as buttons, tool types,
and hovering.
Added some helpers to BitSet32 to handle common code patterns
like finding the first marked bit and clearing it.
Fixed a bug in VelocityTracker where the wrong pointer trace
could get cleared when handling ACTION_POINTER_DOWN. Oops.
Changed PointerCoords so it no longer stores useless zero
axis values. Removed editAxisValue because it is not very
useful when all zero value axes are absent and therefore
cannot be edited in place.
Added dispatch of stylus hover events.
Added support for distance and tool types.
Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
This change moves the cached window and application input state
into the handle objects themselves. It simplifies the dispatcher
somewhat because it no longer needs to fix up references to
transient InputWindow objects each time the window list is updated.
This change will also make it easier to optimize setInputWindows
to avoid doing a lot of redundant data copying. In principle, only
the modified fields need to be updated. However, for now we
continue to update all fields in unison as before.
It turns out that the input dispatcher was inappropriately retaining
pointers to InputWindow objects within the mWindows InputWindow
vector. This vector is copy-on-write so it is possible and the
item pointers to change if an editing operation is performed on
the vector when it does not exclusively own the underlying
SharedBuffer. This bug was uncovered by a previous change that
replaced calls to clear() and appendVector() with a simple use
of operator= which caused the buffer to be shared. Consequently
after editItemAt was called (which it shouldn't have, actually)
the buffer was copied and the cached InputWindow pointers became
invalid. Oops. This change fixes the problem.
Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
Fixed some issues where inconsistent streams of events could
be generated by the dispatcher, particularly when switching from
hovering with one device to hovering with another.
Fixed a bug where the touch pad would fail to generate a new
HOVER_MOVE following a tap event. As a result, the hover event
stream would not resume until the user touched the touch pad
again.
Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
When a window registers to listen for outside touches, it doesn't need
the position information for touches that land outside of its activity
for normal use cases.
This patch uses the foreground window's UID as a filter to determine
whether to pass the position information. This will allow applications
to continue to rely on touch information for inputs that were directed
at one of its other windows.
Bug: 4541250
Change-Id: If16eb1ec8404b797d991859eef55ac0a20a355a3
Fix bug where the pointer presentation would be updated on
any input reader timeout rather than only when a pointer gesture
is in progress.
Bug: 4124987
Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
Some drivers report individual finger updates one at a time
instead of all at once. When 10 fingers are down, this can
cause the framework to have to handle 10 times as many events
each with 10 times as much data. Applications like
PointerLocation would get significantly bogged down by all
of the redundant samples.
This change coalesces samples that are closely spaced in time,
before they are dispatched, as part of the motion event batching
protocol.
Increased the size of the InputChannel shared memory buffer so
that applications can catch up faster if they accumulate a
backlog of samples.
Change-Id: Ibc6abf8af027d9003011ac75caa12941080caba3
Also be more careful about canceling fallback keys during focus
transitions, when the application handles the key, or when the
policy decides to do something different.
Fixed a crash due to JNI CallObjectMethod returning an undefined
value (not null) when an exception is thrown.
Fixed a crash due to the policy trying to create a Dialog for
recent apps on the dispatcher thread. It should happen on the
policy's Looper instead.
Bug: 4187302
Change-Id: I043f82913830f411b3bb4018d6422467b6ca454f
Added the concept of pointer properties in a MotionEvent.
This is currently used to track the pointer tool type to enable
applications to distinguish finger touches from a stylus.
Button states are also reported to application as part of touch events.
There are no new actions for detecting changes in button states.
The application should instead query the button state from the
MotionEvent and take appropriate action as needed.
A good time to check the button state is on ACTION_DOWN.
As a side-effect, applications that do not support multiple buttons
will treat primary, secondary and tertiary buttons identically
for all touch events.
The back button on the mouse is mapped to KEYCODE_BACK
and the forward button is mapped to KEYCODE_FORWARD.
Added basic plumbing for the secondary mouse button to invoke
the context menu, particularly in lists.
Added clamp and split methods on MotionEvent to take care of
common filtering operations so we don't have them scattered
in multiple places across the framework.
Bug: 4260011
Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
Some drivers report individual finger updates one at a time
instead of all at once. When 10 fingers are down, this can
cause the framework to have to handle 10 times as many events
each with 10 times as much data. Applications like
PointerLocation would get significantly bogged down by all
of the redundant samples.
This change coalesces samples that are closely spaced in time,
before they are dispatched, as part of the motion event batching
protocol.
Increased the size of the InputChannel shared memory buffer so
that applications can catch up faster if they accumulate a
backlog of samples.
Added logging code to help measure input dispatch and drawing
latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY.
Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
This patch adds a mechanism for capturing, filtering, transforming
and injecting input events at a very low level before the input
dispatcher attempts to deliver them to applications. At this time,
the mechanism is only intended to be used by the accessibility
system to implement built-in system-level accessibility affordances.
The accessibility input filter is currently just a stub.
It logs the input events receives and reinjects them unchanged,
except that it transforms KEYCODE_Q into KEYCODE_Z.
Currently, the accessibility input filter is installed whenever
accessibility is enabled. We'll probably want to change that
so it only enables the input filter when a screen reader is
installed and we want touch exploration.
Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
Also be more careful about canceling fallback keys during focus
transitions, when the application handles the key, or when the
policy decides to do something different.
Fixed a crash due to JNI CallObjectMethod returning an undefined
value (not null) when an exception is thrown.
Fixed a crash due to the policy trying to create a Dialog for
recent apps on the dispatcher thread. It should happen on the
policy's Looper instead.
Bug: 4187302
Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
The input dispatcher sends a HOVER_ENTER to a window before dispatching
it any HOVER_MOVE events. For compatibility reasons, the window will
*also* receive the HOVER_MOVE. When the pointer moves into a different
window or the pointer goes down or when events are canceled for some reason,
the input dispatcher sends a HOVER_EXIT to the previously hovered window.
The view hierarchy behavior is similar. All views under the pointer
receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE
events. When the pointer leaves a view, the view receives HOVER_EXIT.
Similarly, if a parent view decides to capture hover by returning true
from onHoverEvent, the hovered descendants will receive HOVER_EXIT.
The default behavior of onHoverEvent is to update the view's hovered
state by calling setHovered(true/false). Views can query their current
hovered state using isHovered().
For testing purposes, the hovered state is mapped to the pressed
drawable state. This will change in a subsequent commit with the
introduction of a new hovered drawable state.
Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
Added some plumbing to enable the policy to intercept motion
events when the screen is off to handle wakeup if needed.
Added a basic concept of an external device to limit the scope
of the wakeup policy to external devices only. The wakeup policy
for internal devices should be based on explicit rules such as
policy flags in key layout files.
Moved isTouchEvent to native.
Ensure the dispatcher sends the right event type to userActivity
for non-touch pointer events like HOVER_MOVE and SCROLL.
Bug: 3193114
Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
Only initiate fallback key handling if the first key down was
not handled and there is no other fallback key already in progress.
This prevents spurious fallbacks from being generated when
applications handle the initial down but not repeated downs or the up.
Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
Added support for tracking the mouse position even when the mouse button
is not pressed. To avoid confusing existing applications, mouse movements
are reported using the new ACTION_HOVER_MOVE action when the mouse button
is not pressed.
Added some more plumbing for the scroll wheel axes. The values are
reported to Views but they are not yet handled by the framework.
Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
The touch screen sometimes reports more than 10 pointers even though that's
all we asked for. When this happens, we start dropping events with more
than 10 pointers. This confuses applications and causes them to crash.
Raised the limit to 16 pointers.
Bug: 3331247
The default behavior was to identify all touch devices as touch screens.
External devices that are plugged in are more likely to be touch pads
not attached to a screen. Changed the default to be a touch pad
and renamed some internal constants to avoid confusion.
A certain mouse happens to also behave like a touch pad. That caused
problems because we would see multiple concurrent traces of motion events
coming from the same input device so we would batch them up.
Added code to ensure that we don't batch events unless they come from
the same *source* in addition to coming from the same *device*.
Due to batching or misbehaving drivers, it's possible for the set of
pointer ids to be different from what we expect when it comes time to
split motion events across windows. As a result, we can generate motion
events with 0 pointers. When we try to deliver those events, we cause
an error in the InputTransport so we tear down the InputChannel and kill
the application.
Added code to check out assumption about pointer ids and drop the
event gracefully instead.
Patched up the tests to take into account the change in default behavior
for identifying touch screens and touch pads.
Change-Id: Ic364bd4cb4cc6335d4a1213a26d6bdadc7e33505
This change implements two heuristics.
1. When events are older than 10 seconds, they are dropped.
2. If the application is currently busy processing an event and
the user touches a window belonging to a different application
then we drop the currently queued events so the other application
can start processing the gesture immediately.
Note that the system takes care of synthesizing cancelation events
automatically for any events that it drops.
Added some new handle types to allow the native dispatcher to
indirectly refer to the WindowManager's window state and app window
token. This was done to enable the dispatcher to identify the
application to which each window belongs but it also eliminates
some lookup tables and linear searches through the window list
on each key press.
Bug: 3224911
Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
Reject movements from other devices when one device is already down.
This fixes jittery behavior when the user moves the mouse and touches
the screen at the same time.
Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
Added support for loading the pointer icon from a resource.
Moved the system server related bits of the input manager out
of libui and into libinput since they do not need to be linked into
applications.
Change-Id: Iec11e0725b3add2b905c51f8ea2c3b4b0d1a2d67
