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_InputQueue.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_InputQueue.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_InputQueue.cpp
|
a44dd26a75e24cc021802288fb81f4761e47be6b |
|
11-Apr-2013 |
Michael Wright <michaelwr@google.com> |
Rewrite input handling for native applications Bug: 8473020 Change-Id: Ic4353d8924ab877bec21aff8c2dba9fe725bf906
/frameworks/base/core/jni/android_view_InputQueue.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_InputQueue.cpp
|
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 optimization. This change restores order from chaos and greatly simplifies the invariants related to input event dispatch within the application. Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
/frameworks/base/core/jni/android_view_InputQueue.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_InputQueue.cpp
|
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
/frameworks/base/core/jni/android_view_InputQueue.cpp
|
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
/frameworks/base/core/jni/android_view_InputQueue.cpp
|
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
/frameworks/base/core/jni/android_view_InputQueue.cpp
|
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 elsewhere. 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
/frameworks/base/core/jni/android_view_InputQueue.cpp
|
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
/frameworks/base/core/jni/android_view_InputQueue.cpp
|
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
/frameworks/base/core/jni/android_view_InputQueue.cpp
|
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
/frameworks/base/core/jni/android_view_InputQueue.cpp
|
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
/frameworks/base/core/jni/android_view_InputQueue.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_InputQueue.cpp
|