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
|