History log of /frameworks/base/core/jni/android_view_InputEventSender.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
a4ca8ea0ad14c509d1ced46482e83c1b8a518982 03-Apr-2013 Jeff Brown <jeffbrown@google.com> Fix reference cycle in InputEventReceiver and Sender.

If the receiver or sender was not properly disposed, then
the underlying input channel might be leaked because the
native peer was holding a strong reference to the object.

Switched to using a weak reference.

Also updated Binder to use a new helper created for this purpose.

Change-Id: I19680bf96d0548777bff02aa1d91874d1e8e41da
10f9b0997e0bde39fa153060db022a3982b78399 01-Apr-2013 Michael Wright <michaelwr@google.com> Start input event sequence numbers at 1

Change-Id: Ia69574cb25bfced8bbeefbc23350706bacdfee12
44e13ef1a1aee36b4ce667670345de8ce4e6bb7b 27-Mar-2013 Jeff Brown <jeffbrown@google.com> Disable some noisy error logs.

Disabled some error logs that occur when an input channel is
closed remotely by its peer. These can happen during normal
course of operations because the act of removing windows or
finishing IME sessions is asynchronous so both peers may react
to the change independently at different times.

The coordination with the input dispatcher is designed to
avoid logging these errors. However it's not possible to achieve
the same coordination with the IME so we might as well silence
the errors since they don't tell us anything useful.

If something truly bad happens then one of two things will occur:

1. The system will realize that the process crashed because
of a DeadObjectException or other error, so it will take
measures to clean up.

2. If the error was spurious and non-fatal (how?) then at worst
an ANR may occur because the consumer stopped reading from
the input channel. However this has never been observed
and I doubt it's even possible.

Change-Id: I11a05d6d75e63e91be003971a544069b3a0d77f4
c28867a1d67121ce5963de135e3ae2b1dbd9a33d 26-Mar-2013 Jeff Brown <jeffbrown@google.com> Use input transport for communications between app and IME.

The input method manager service now supplies an input channel for
communication while creating an IME session on behalf of the

This change significanly reduces the overhead of IME event dispatch
by using a standard input channel to send input events rather than
using binder. This results in fewer thread context switches
and fewer object allocations.

What's more, the IME may perform additional batching of the motion
events that it receives which may help it catch up if it is
getting behind while processing them.

Bug: 7984576
Bug: 8473020
Change-Id: Ibe26311edd0060cdcae80194f1753482e635786f