| d6058f44f47b2379200bc69aecbcf34fe2b3f873 |
|
04-Jan-2018 |
Siarhei Vishniakou <svv@google.com> |
Do not return pointer to freed memory
Since the code was changed to use std::string instead of String8, it is
no longer safe to pass a raw pointer to internal memory of the string
object, since std::string creates a copy even if the data itself is not
being modified.
Instead, return std::string to the calling function and let the function
access the pointer when necessary.
Bug: 71541263
Test: boot up asan build on pixel 2 xl, then interact with google
calendar and chrome. Observe no crashes with the patch.
Change-Id: I6af2d23985d0553dd0707ad985f7f1e7b2240611
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 8e960d700c5e3bfe812affdb22252aac2d009f91 |
|
23-Nov-2017 |
Siarhei Vishniakou <svv@google.com> |
Prefer std::string over String8
String8 is obsolete, only use std::string in the
input libraries now.
Bug: 64258224
Test: make, boot device, interact with UI
Change-Id: I0e610f8290438ab1e21e466288e3217015b49699
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 7def2eea97600812f73ccf62a8433c069ef4da46 |
|
02-Aug-2017 |
Tarandeep Singh <tarandeep@google.com> |
Merge "Fix keyboard focus in VR" into oc-dr1-dev
am: 986995d481
Change-Id: Ide81e21c24c6efd66c03c997dcaefbd0a3efd7b8
|
| e1cfcf4c4d15417bc912d36d487b4454c19b30fa |
|
11-Jul-2017 |
Tarandeep Singh <tarandeep@google.com> |
Fix keyboard focus in VR
Consider this VirtualDisplay (VD) scenario:
HostActivity creates a VD which holds SettingsActivity. When EditText
on SettingsActivity is tapped, it gains focus.
On eventual taps, it loses focus i.e. the Window in VD loses focus and
the host activity in primary display gets the focus instead. This
happens because WM's TaskTapPointerEventListener.onPointerEvent()
is called on the default display only.
Root cause:
1. Tap detector isn't registered for non-default display.
2. Tap detector has no info on which displayId touch was received.
3. InputFlinger doesn't deliver InputMonitor events for
non-default displays (fixed in a separate CL)
Fixing above results in onPointerEvent(MotionEvent) to deliver the
Touch events successfully to VD. We restrict these changes to physical
multi-displays and VR VirtualDisplays (which uses virtual touch device).
[VrManagerService calls WMInternal.setVr2dDisplayId(int)]
In future, displayId should be part of InputEvent. Bug: 64258305
Bug: 62033391
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I3626f4de5aa9bcf905da9abd39f3ab1baefc4c48
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 2279b2534272282a5b5152723235da397e49195c |
|
19-Jul-2017 |
Steven Moreland <smoreland@google.com> |
frameworks/base: use proper nativehelper headers
libnativehelper exports headers under nativehelper. These were
available before incorrectly as global headers in order to give
access to jni.h.
Test: modules using frameworks/base find headers
Bug: 63762847
Change-Id: I0f9f231acdebe460f279135462f43d3e32eff64d
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 76f6a86de25e1bf74717e047e55fd44b089673f3 |
|
19-Sep-2015 |
Daniel Micay <danielmicay@gmail.com> |
constify JNINativeMethod function pointer tables
Change-Id: I4036c924958221cbc644724f8eb01c5de3cd7954
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 46c82b4cd241a447834ed2f5a6be16777b7a990b |
|
30-Nov-2014 |
Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org> |
Adjust format strings to work on both 32-bit and 64-bit builds
Adjust format strings to not produce Clang warnings in both 32-bit and
64-bit builds
Change-Id: I76c29d8d5d0fb4b5e9d9518077652370ffe9e871
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| ed6b9dff563c5e22f040ff37e12c0d771e0478ae |
|
21-Nov-2014 |
Andreas Gampe <agampe@google.com> |
Frameworks/base: Consistency in core/jni
Make consistent use of core_jni_helpers for registration.
Translate some #ifdefs into const bools.
Change-Id: I37639aa053dd50f003a552cbd8550dddecc811c5
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 987f79f60bb1f0a4bcd3ef22e57301c743f0b94f |
|
19-Nov-2014 |
Andreas Gampe <agampe@google.com> |
Frameworks/base: Replace LOG_FATAL_IF in core/jni
Do not use LOG_FATAL_IF in JNI setup. This is one-time on startup
and important enough to always check.
Add a header with common helper definitions. Move to inlined functions
instead of macros to clean up the code.
Change-Id: Ib12d0eed61b110c45d748e80ec36c563e9dec7e5
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 0f0b4919667f418b249c497f5ad3e83fdf4437e5 |
|
12-Nov-2014 |
Andreas Gampe <agampe@google.com> |
Frameworks/base: Wall Werror in core/jni
Turn on -Wall -Werror in core/jni. Fix warnings.
Clang TODO: For GCC we need to turn off Wunused-but-set-variable in
the GL bindings. However, Clang doesn't have that warning and thus
complains about an unknown pragma. It is necessary to make the
pragma #ifdef-ed on the compiler being GCC.
Change-Id: I14cab48d45c2771eef0432082356c47ed44a3d7f
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 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_InputEventReceiver.cpp
|
| 62ce65d6edbc2c34c63b0e2f2fef9cb08e28c783 |
|
25-Oct-2013 |
Michael Wright <michaelwr@google.com> |
Speculatively schedule input consumption
With the new tuned vsync offset, vsyncs are likely to occur shortly
after the input is received, meaning we will empty the input queue,
and thus won't schedule input consumption until more input is
received. If an application then speculatively posts draw commands to
the main looper faster than 60 hz, it will eventually end up blocking
in eglSwapBuffers. Since we're blocking in eglSwapBuffers, we won't
even schedule consumption until after the current frame (8-16ms), and
it's entirely likely we won't actually get around to consuming input
until after the next frame (another 16 ms of latency). This means we
can often go 16-32ms without processing any input events, causing
very noticeable amounts of jank.
Rather than waiting for the next input event to schedule input
consumption, speculatively schedule it every frame as long as we've
consumed some motion batch during this frame.
Bug: 11398045
Change-Id: I25e46308e00e9f9de00a1d8906f6b0e0f2e845b4
/frameworks/base/core/jni/android_view_InputEventReceiver.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_InputEventReceiver.cpp
|
| 56513492ea6d4a72584cbc01979f7b3fa3c2807f |
|
22-May-2013 |
Jeff Brown <jeffbrown@google.com> |
Add a queue of pending finished input events.
Although in practice an application or IME is unlikely to fill up
the input channel with finish events, it can happen when events are
being delivered very rapidly. Handle this situation by queuing
up the pending finish events until the socket becomes writable again.
Bug: 9034301
Change-Id: I938a62a75d12106a19cff2d016ba7af0db877ecf
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 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
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 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
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 80a1de1007ddc62e1af2a4746008f499145aeaab |
|
01-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Use sp<LooperCallback> to fix race causing dangling pointer.
Bug: 6559630
Change-Id: I9b9c76577779841006f9c024a80685ba8b7cd0e1
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 771526c88f5cc4b56a41cb12aa06a28d377a07d5 |
|
28-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Resample touch events on frame boundaries.
Bug: 6375101
Change-Id: I8774e366306bb2b6b4e42b913525bf25b0380ec3
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 3bdcdd8531781569d501e7023c22e25e2bae0dd1 |
|
11-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Be more careful about exceptions in input callbacks.
consumeEvents() may be called reentrantly so we need to be
careful when handling exceptions. When called directly
through JNI, the exception should be allowed to bubble up
to the caller. When called from a Looper callback, the
exception should be recorded on the MessageQueue and bubbled
when the call to nativePollOnce() returns.
Bug: 6312938
Change-Id: Ief5e315802f586aa85af7eef1bd6e9bea4ce24ab
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 603b44589682db3ff33ade172facb0c5e309f1be |
|
07-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Ensure that apps crash if they throw exceptions.
Previously, if an app threw an uncaught exception in an input,
vsync or native activity callback, it would log the exception then
continue limping merrily along. In the case of input, it
could result in an ANR occurring because we had not drained
all of the pending input events and marked them as finished
(we only marked the most recent one finished).
Bug: 6304124
Change-Id: I87d76f7fd605e1a8af1237c66d8d62973080277e
/frameworks/base/core/jni/android_view_InputEventReceiver.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_InputEventReceiver.cpp
|
| 9806a2307f3e47e847ad5e62e302eab36d3eb3e4 |
|
17-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Ignore broken input channel when finishing input event.
There are occasional races during application shut down where the
input dispatcher will close an input channel before the application
has finished its last event. So just ignore EPIPE.
Also tweak the logging for failed input event injection to make
it clearer which pid was trying to perform the injection.
Bug: 6013004
Change-Id: I7bbb01441d41762b03eafd4d39dcf0323e1cadf3
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| b503f1eea1b2ab699e3325450a08f3f62aa0c403 |
|
17-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Don't throw on EPIPE in consumeBatchedInputEvents.
Bug: 6014825
Change-Id: I59bd98a1fba5d86f9793fd6e9d9f0a271ac1c789
/frameworks/base/core/jni/android_view_InputEventReceiver.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_InputEventReceiver.cpp
|
| 072ec96a4900d4616574733646ee46311cb5d2cb |
|
07-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Implement batching of input events on the consumer side.
To support this feature, the input dispatcher now allows input
events to be acknowledged out-of-order. As a result, the
consumer can choose to defer handling an input event from one
device (because it is building a big batch) while continuing
to handle input events from other devices.
The InputEventReceiver now sends a notification when a batch
is pending. The ViewRoot handles this notification by scheduling
a draw on the next sync. When the draw happens, the InputEventReceiver
is instructed to consume all pending batched input events, the
input event queue is fully processed (as much as possible),
and then the ViewRoot performs traversals as usual.
With these changes in place, the input dispatch latency is
consistently less than one frame as long as the application itself
isn't stalled. Input events are delivered to the application
as soon as possible and are handled as soon as possible. In practice,
it is no longer possible for an application to build up a huge
backlog of touch events.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
/frameworks/base/core/jni/android_view_InputEventReceiver.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_InputEventReceiver.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_InputEventReceiver.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_InputEventReceiver.cpp
|
| 5baa3a62a97544669fba6d65a11c07f252e654dd |
|
20-Dec-2011 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGD(_IF) to (IF_)ALOGD(_IF) DO NOT MERGE
See https://android-git.corp.google.com/g/156016
Bug: 5449033
Change-Id: I4c4e33bb9df3e39e11cd985e193e6fbab4635298
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 0a0a1248cfc03940174cbd9af677bafd7280a3bc |
|
02-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Add a new class to receive vsync events.
Change-Id: I4e384336d2813752a6d65fda6a77e86113a4510c
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|
| 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
/frameworks/base/core/jni/android_view_InputEventReceiver.cpp
|