History log of /frameworks/base/core/jni/android_view_InputQueue.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
a931d5218cfee89c7629ffa6cde324fa966449f9 08-Jan-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Use long for pointers in view/input classes

For storing pointers, long is used in view/input classes,
as native pointers can be 64-bit.

In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)

Change-Id: Iafda9f4653c023bcba95b873637d935d0b569f5d
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
9d3b1a424c5c61e24e9659d15fb353026a00d925 02-Jul-2013 Jeff Brown <jeffbrown@google.com> Move input library code to frameworks/native.

No longer compile libandroidfw as a static library on the device
since it already exists as a shared library. Keeping the static
library would force us to provide a static library version of
libinput for the device as well which doesn't make sense.

Change-Id: I3517881b87b47dcc209d80dbd0ac6b5cf29a766f
a44dd26a75e24cc021802288fb81f4761e47be6b 11-Apr-2013 Michael Wright <michaelwr@google.com> Rewrite input handling for native applications

Bug: 8473020
Change-Id: Ic4353d8924ab877bec21aff8c2dba9fe725bf906
32cbc3855c2a971aa5a801fd339fb6a37db91a1a 01-Dec-2011 Jeff Brown <jeffbrown@google.com> Refactor InputQueue as InputEventReceiver.

This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).

This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.

Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
4952dfd16a0f839559ffa78f5016394caf85294f 01-Dec-2011 Jeff Brown <jeffbrown@google.com> Ensure input events are processed in-order in the application.

As it turns out, it used to be possible for there to be multiple
input events simultaneously in flight in an application. Although
it worked, it made it hard to reason about what was going on.
The problem was somewhat exacerbated by the introduction of a
queue of "InputEventMessage" objects as part of an earlier latency

This change restores order from chaos and greatly simplifies the
invariants related to input event dispatch within the application.

Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
cc4f7db698f88b633a286d8ab1105b28a474cd09 31-Aug-2011 Jeff Brown <jeffbrown@google.com> Fix input channel leak.
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

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
2ed2462aa29c564f5231f317c27b3188da875e52 15-Mar-2011 Jeff Brown <jeffbrown@google.com> Improve VelocityTracker numerical stability.

Replaced VelocityTracker with a faster and more accurate
native implementation. This avoids the duplicate maintenance
overhead of having two implementations.

The new algorithm requires that the sample duration be at least
10ms in order to contribute to the velocity calculation. This
ensures that the velocity is not severely overestimated when
samples arrive in bursts.

The new algorithm computes the exponentially weighted moving
average using weights based on the relative duration of successive
sample periods.

The new algorithm is also more careful about how it handles
individual pointers going down or up and their effects on the
collected movement traces. The intent is to preserve the last
known velocity of pointers as they go up while also ensuring
that other motion samples do not count twice in that case.

Bug: 4086785
Change-Id: I2632321232c64d6b8faacdb929e33f60e64dcdd3
3915bb845b032dc184dba5e60970b803390ca3ed 05-Nov-2010 Jeff Brown <jeffbrown@google.com> Tell system server whether the app handled input events.

Refactored ViewRoot, NativeActivity and related classes to tell the
dispatcher whether an input event was actually handled by the application.

This will be used to move more of the global default key processing
into the system server instead of the application.

Change-Id: If06b98b6f45c543e5ac5b1eae2b3baf9371fba28
4fe6c3e51be77e35f40872cdbca6c80f8f8b7ecb 14-Sep-2010 Jeff Brown <jeffbrown@google.com> Replace epoll() with poll() and rename PollLoop to Looper.

As part of this change, consolidated and cleaned up the Looper API so
that there are fewer distinctions between the NDK and non-NDK declarations
(no need for two callback types, etc.).

Removed the dependence on specific constants from sys/poll.h such as
POLLIN. Instead looper.h defines events like LOOPER_EVENT_INPUT for
the events that it supports. That should help make any future
under-the-hood implementation changes easier.

Fixed a couple of compiler warnings along the way.

Change-Id: I449a7ec780bf061bdd325452f823673e2b39b6ae
2cbecea4c9627d95377fc3e3b8a319116cee7feb 18-Aug-2010 Jeff Brown <jeffbrown@google.com> Fix possible race conditions during channel unregistration.

Previously, the input dispatcher assumed that the input channel's
receive pipe file descriptor was a sufficiently unique identifier for
looking up input channels in its various tables. However, it can happen
that an input channel is disposed and then a new input channel is
immediately created that reuses the same file descriptor. Ordinarily
this is not a problem, however there is a small opportunity for a race
to arise in InputQueue.

When InputQueue receives an input event from the dispatcher, it
generates a finishedToken that encodes the channel's receive pipe fd,
and a sequence number. The finishedToken is used by the ViewRoot
as a handle for the event so that it can tell the InputQueue when
the event has finished being processed.

Here is the race:

1. InputQueue receives an input event, assigns a new finishedToken.
2. ViewRoot begins processing the input event.
3. During processing, ViewRoot unregisters the InputChannel.
4. A new InputChannel is created and is registered with the Input Queue.
This InputChannel happens to have the same receive pipe fd as
the one previously registered.
5. ViewRoot tells the InputQueue that it has finished processing the
input event, passing along the original finishedToken.
6. InputQueue throws an exception because the finishedToken's receive
pipe fd is registered but the sequence number is incorrect so it
assumes that the client has called finish spuriously.

The fix is to include a unique connection id within the finishedToken so
that the InputQueue can accurately confirm that the token belongs to
the currently registered InputChannel rather than to an old one that
happened to have the same receive pipe fd. When it notices this, it
ignores the spurious finish.

I've also made a couple of other small changes to avoid similar races

This patch set also includes a fix to synthesize a finished signal
when the input channel is unregistered on the client side to
help keep the server and client in sync.

Bug: 2834068
Change-Id: I1de34a36249ab74c359c2c67a57e333543400f7b
ace999b096739d376d4845c0ba94599197ff8477 17-Jul-2010 Jeff Brown <jeffbrown@google.com> Ignore attempts to finish events on unregistered channels.

This is a common race that happens during application shutdown where the window
may be removed before the input event is finished. The input dispatcher
already recovers from this condition gracefully so there are no benefits to
throwing an exception on the client side.

Bug: 2834068

Change-Id: I53dcc3230464d7f528ac8a1cc9f01b5bb642f428
c5ed5910c9ef066cec6a13bbb404ec57b1e92637 15-Jul-2010 Jeff Brown <jeffbrown@google.com> Add support for new input sources.

Added several new coordinate values to MotionEvents to capture
touch major/minor area, tool major/minor area and orientation.

Renamed NDK input constants per convention.

Added InputDevice class in Java which will eventually provide
useful information about available input devices.

Added APIs for manufacturing new MotionEvent objects with multiple
pointers and all necessary coordinate data.

Fixed a bug in the input dispatcher where it could get stuck with
a pointer down forever.

Fixed a bug in the WindowManager where the input window list could
end up containing stale removed windows.

Fixed a bug in the WindowManager where the input channel was being
removed only after the final animation transition had taken place
which caused spurious WINDOW DIED log messages to be printed.

Change-Id: Ie55084da319b20aad29b28a0499b8dd98bb5da68
349703effce5acc53ed96f7ed8556131f0c65e18 22-Jun-2010 Jeff Brown <jeffbrown@google.com> Native input event dispatching.

Target identification is now fully native.
Fixed a couple of minor issues related to input injection.
Native input enabled by default, can be disabled by setting
WindowManagerPolicy.ENABLE_NATIVE_INPUT_DISPATCH to false.

Change-Id: I7edf66ed3e987cc9306ad4743ac57a116af452ff
9c3cda04d969912bc46184f2b326d1db95e0aba5 15-Jun-2010 Jeff Brown <jeffbrown@google.com> More work in progress on native events.

Refactored the code to eliminate potential deadlocks due to re-entrant
calls from the policy into the dispatcher. Also added some plumbing
that will be used to notify the framework about ANRs.

Change-Id: Iba7a10de0cb3c56cd7520d6ce716db52fdcc94ff
46b9ac0ae2162309774a7478cd9d4e578747bfc2 23-Apr-2010 Jeff Brown <jeffbrown@google.com> Native input dispatch rewrite work in progress.

The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.

Includes part of the new input event NDK API. Some details TBD.

To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.

There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.

End-to-end event dispatch mostly works!

To do: event injection, rate limiting, ANRs, testing, optimization, etc.

Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25