History log of /frameworks/base/core/jni/android_view_InputChannel.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>
/frameworks/base/core/jni/android_view_InputChannel.cpp
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
/frameworks/base/core/jni/android_view_InputChannel.cpp
1951ce86c21445ac191e4d2d95233f4f5c096b56 05-Apr-2013 Jeff Brown <jeffbrown@google.com> Correctly manage the lifecycle of IME InputChannels.

InputChannels are normally duplicated when sent to a remote process
over Binder but this does not happen if the recipient is running within
the system server process. This causes problems for KeyGuard because the
InputMethodManagerService may accidentally dispose the channel
that KeyGuard is using.

Fixed the lifecycle of InputChannels that are managed by the IME
framework. We now return a duplicate of the channel to the application
and then take care to dispose of the duplicate when necessary.
In particular, InputBindResult disposes its InputChannel automatically
when returned through Binder (using PARCELABLE_WRITE_RETURN_VALUE).

Bug: 8493879
Change-Id: I08ec3d13268c76f3b56706b4523508bcefa3be79
/frameworks/base/core/jni/android_view_InputChannel.cpp
d84e1ce0b535128f03416145554fb405f9fade3e 07-Mar-2012 Jeff Sharkey <jsharkey@android.com> Split Parcel JNI details away from Binder.

This is purely a refactoring, with no change to the underlying
functionality.

Change-Id: I41b59f14e57d1cc144274a01f77658d99a1bfe02
/frameworks/base/core/jni/android_view_InputChannel.cpp
b93a03f841d93498bfea6cc92a22faa34bce1337 18-Feb-2012 Mathias Agopian <mathias@google.com> frameworks/base refactoring.

First step. Move libui includes to their new home: androidfw.

Change-Id: Ic042b52fdba72f30edc3cc6339bf30b4c1b99662
/frameworks/base/core/jni/android_view_InputChannel.cpp
91e328984c0d1e0f95b3d37f779d9d4fa9bfe8f8 15-Feb-2012 Jeff Brown <jeffbrown@google.com> Clean up InputChannel file descriptor data type.

File descriptors are ints.

Change-Id: Ie36733bf36ddfeaa9a09ef6ebd7bd2f1788f5d27
/frameworks/base/core/jni/android_view_InputChannel.cpp
cbee6d6ede0499fb4a2c00bfc00d5db8d9ed5139 04-Feb-2012 Jeff Brown <jeffbrown@google.com> Rewrite input transport using sockets.

Since we will not longer be modifying events in place, we don't need
to use an ashmem region for input. Simplified the code to instead
use a socket of type SOCK_SEQPACKET.

This is part of a series of changes to improve input system pipelining.

Bug: 5963420

Change-Id: I05909075ed8b61b93900913e44c6db84857340d8
/frameworks/base/core/jni/android_view_InputChannel.cpp
3762c311729fe9f3af085c14c5c1fb471d994c03 06-Jan-2012 Steve Block <steveblock@google.com> Rename (IF_)LOGE(_IF) to (IF_)ALOGE(_IF) DO NOT MERGE

See https://android-git.corp.google.com/g/#/c/157220

Bug: 5449033
Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
/frameworks/base/core/jni/android_view_InputChannel.cpp
8564c8da817a845353d213acd8636b76f567b234 06-Jan-2012 Steve Block <steveblock@google.com> Rename (IF_)LOGW(_IF) to (IF_)ALOGW(_IF) DO NOT MERGE

See https://android-git.corp.google.com/g/157065

Bug: 5449033
Change-Id: I00a4b904f9449e6f93b7fd35eac28640d7929e69
/frameworks/base/core/jni/android_view_InputChannel.cpp
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
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
/frameworks/base/core/jni/android_view_InputChannel.cpp
02cafc9f6ec018ae31ca9032be67a2d8d410736a 27-Feb-2011 Jeff Brown <jeffbrown@google.com> Log errors reading input channel from parcel.

Bug: 3378634
Change-Id: I47908e48b8348f0366dcef545e828b65d99d81a6
/frameworks/base/core/jni/android_view_InputChannel.cpp
5c225b1680e696ae8bbf505a1997d6f720672f74 16-Jun-2010 Jeff Brown <jeffbrown@google.com> Even more native input dispatch work in progress.

Added more tests.
Fixed a regression in Vector.
Fixed bugs in pointer tracking.
Fixed a starvation issue in PollLoop when setting or removing callbacks.
Fixed a couple of policy nits.

Modified the internal representation of MotionEvent to be more
efficient and more consistent.

Added code to skip/cancel virtual key processing when there are multiple
pointers down. This helps to better disambiguate virtual key presses
from stray touches (such as cheek presses).

Change-Id: I2a7d2cce0195afb9125b23378baa94fd2fc6671c
/frameworks/base/core/jni/android_view_InputChannel.cpp
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
/frameworks/base/core/jni/android_view_InputChannel.cpp