drgreen/android_frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
android_frameworks_base/services/input/InputDispatcher.cpp

4759 lines
186 KiB
C++
Raw Normal View History

Mouse pointer integration. Added support for loading the pointer icon from a resource. Moved the system server related bits of the input manager out of libui and into libinput since they do not need to be linked into applications. Change-Id: Iec11e0725b3add2b905c51f8ea2c3b4b0d1a2d67
2011-01-02 16:37:43 -08:00
/*
* Copyright (C) 2010 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
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
2010-04-22 18:58:52 -07:00
#define LOG_TAG "InputDispatcher"
//#define LOG_NDEBUG 0
// Log detailed debug messages about each inbound event notification to the dispatcher.
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
2010-06-22 01:27:15 -07:00
#define DEBUG_INBOUND_EVENT_DETAILS 0
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
2010-04-22 18:58:52 -07:00
// Log detailed debug messages about each outbound event processed by the dispatcher.
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
2010-06-22 01:27:15 -07:00
#define DEBUG_OUTBOUND_EVENT_DETAILS 0
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
2010-04-22 18:58:52 -07:00
// Log debug messages about batching.
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
2010-06-22 01:27:15 -07:00
#define DEBUG_BATCHING 0
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
2010-04-22 18:58:52 -07:00
// Log debug messages about the dispatch cycle.
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
2010-06-22 01:27:15 -07:00
#define DEBUG_DISPATCH_CYCLE 0
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
2010-04-22 18:58:52 -07:00
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
2010-06-15 01:31:58 -07:00
// Log debug messages about registrations.
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
2010-06-22 01:27:15 -07:00
#define DEBUG_REGISTRATION 0
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
2010-06-15 01:31:58 -07:00
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
2010-04-22 18:58:52 -07:00
// Log debug messages about performance statistics.
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
2010-06-22 01:27:15 -07:00
#define DEBUG_PERFORMANCE_STATISTICS 0
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
2010-04-22 18:58:52 -07:00
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
// Log debug messages about input event injection.
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
2010-06-22 01:27:15 -07:00
#define DEBUG_INJECTION 0
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
// Log debug messages about input event throttling.
#define DEBUG_THROTTLING 0
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Log debug messages about input focus tracking.
#define DEBUG_FOCUS 0
// Log debug messages about the app switch latency optimization.
#define DEBUG_APP_SWITCH 0
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Log debug messages about hover events.
#define DEBUG_HOVER 0
Mouse pointer integration. Added support for loading the pointer icon from a resource. Moved the system server related bits of the input manager out of libui and into libinput since they do not need to be linked into applications. Change-Id: Iec11e0725b3add2b905c51f8ea2c3b4b0d1a2d67
2011-01-02 16:37:43 -08:00
#include "InputDispatcher.h"
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
2010-04-22 18:58:52 -07:00
#include <cutils/log.h>
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#include <ui/PowerManager.h>
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
2010-04-22 18:58:52 -07:00
#include <stddef.h>
#include <unistd.h>
#include <errno.h>
#include <limits.h>
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
#define INDENT " "
#define INDENT2 " "
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
2010-04-22 18:58:52 -07:00
namespace android {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Default input dispatching timeout if there is no focused application or paused window
// from which to determine an appropriate dispatching timeout.
const nsecs_t DEFAULT_INPUT_DISPATCHING_TIMEOUT = 5000 * 1000000LL; // 5 sec
// Amount of time to allow for all pending events to be processed when an app switch
// key is on the way. This is used to preempt input dispatch and drop input events
// when an application takes too long to respond and the user has pressed an app switch key.
const nsecs_t APP_SWITCH_TIMEOUT = 500 * 1000000LL; // 0.5sec
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
// Amount of time to allow for an event to be dispatched (measured since its eventTime)
// before considering it stale and dropping it.
const nsecs_t STALE_EVENT_TIMEOUT = 10000 * 1000000LL; // 10sec
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
// Motion samples that are received within this amount of time are simply coalesced
// when batched instead of being appended. This is done because some drivers update
// the location of pointers one at a time instead of all at once.
// For example, when there are 10 fingers down, the input dispatcher may receive 10
// samples in quick succession with only one finger's location changed in each sample.
//
// This value effectively imposes an upper bound on the touch sampling rate.
// Touch sensors typically have a 50Hz - 200Hz sampling rate, so we expect distinct
// samples to become available 5-20ms apart but individual finger reports can trickle
// in over a period of 2-4ms or so.
//
// Empirical testing shows that a 2ms coalescing interval (500Hz) is not enough,
// a 3ms coalescing interval (333Hz) works well most of the time and doesn't introduce
// significant quantization noise on current hardware.
const nsecs_t MOTION_SAMPLE_COALESCE_INTERVAL = 3 * 1000000LL; // 3ms, 333Hz
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
2010-04-22 18:58:52 -07:00
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
static inline nsecs_t now() {
return systemTime(SYSTEM_TIME_MONOTONIC);
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
static inline const char* toString(bool value) {
return value ? "true" : "false";
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
static inline int32_t getMotionEventActionPointerIndex(int32_t action) {
return (action & AMOTION_EVENT_ACTION_POINTER_INDEX_MASK)
>> AMOTION_EVENT_ACTION_POINTER_INDEX_SHIFT;
}
static bool isValidKeyAction(int32_t action) {
switch (action) {
case AKEY_EVENT_ACTION_DOWN:
case AKEY_EVENT_ACTION_UP:
return true;
default:
return false;
}
}
static bool validateKeyEvent(int32_t action) {
if (! isValidKeyAction(action)) {
LOGE("Key event has invalid action code 0x%x", action);
return false;
}
return true;
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
static bool isValidMotionAction(int32_t action, size_t pointerCount) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
switch (action & AMOTION_EVENT_ACTION_MASK) {
case AMOTION_EVENT_ACTION_DOWN:
case AMOTION_EVENT_ACTION_UP:
case AMOTION_EVENT_ACTION_CANCEL:
case AMOTION_EVENT_ACTION_MOVE:
case AMOTION_EVENT_ACTION_OUTSIDE:
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
case AMOTION_EVENT_ACTION_HOVER_ENTER:
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
case AMOTION_EVENT_ACTION_HOVER_MOVE:
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
case AMOTION_EVENT_ACTION_HOVER_EXIT:
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
2011-02-24 20:55:35 -08:00
case AMOTION_EVENT_ACTION_SCROLL:
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
return true;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
case AMOTION_EVENT_ACTION_POINTER_DOWN:
case AMOTION_EVENT_ACTION_POINTER_UP: {
int32_t index = getMotionEventActionPointerIndex(action);
return index >= 0 && size_t(index) < pointerCount;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
default:
return false;
}
}
static bool validateMotionEvent(int32_t action, size_t pointerCount,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
const PointerProperties* pointerProperties) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
if (! isValidMotionAction(action, pointerCount)) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
LOGE("Motion event has invalid action code 0x%x", action);
return false;
}
if (pointerCount < 1 || pointerCount > MAX_POINTERS) {
LOGE("Motion event has invalid pointer count %d; value must be between 1 and %d.",
pointerCount, MAX_POINTERS);
return false;
}
Add unit tests for native input and fix bugs identified. Fixed a bug where we would lose the first touch point when swiping out of the virtual key area. Fixed a bug where we would not send an ACTION_MOVE event in cases where individual pointers went down/up and the remaining pointers actually moved. This is important since many applications do not handle pointer movements during ACTION_POINTER_DOWN or ACTION_POINTER_UP. In the case of ACTION_POINTER_UP the movement was completely lost since all pointers were dispatched using their old location rather than the new location. Improved motion event validation to check for duplicate pointer ids. Added an input source constant that was missing from the NDK api but defined in the framework api. Added a timestamp when reporting added/removed devices in EventHub. Bug: 3070082 Change-Id: I3206a030f43b7616e2f48006e5a9d522c4d92e56
2010-10-20 15:33:38 -07:00
BitSet32 pointerIdBits;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
for (size_t i = 0; i < pointerCount; i++) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
int32_t id = pointerProperties[i].id;
Add unit tests for native input and fix bugs identified. Fixed a bug where we would lose the first touch point when swiping out of the virtual key area. Fixed a bug where we would not send an ACTION_MOVE event in cases where individual pointers went down/up and the remaining pointers actually moved. This is important since many applications do not handle pointer movements during ACTION_POINTER_DOWN or ACTION_POINTER_UP. In the case of ACTION_POINTER_UP the movement was completely lost since all pointers were dispatched using their old location rather than the new location. Improved motion event validation to check for duplicate pointer ids. Added an input source constant that was missing from the NDK api but defined in the framework api. Added a timestamp when reporting added/removed devices in EventHub. Bug: 3070082 Change-Id: I3206a030f43b7616e2f48006e5a9d522c4d92e56
2010-10-20 15:33:38 -07:00
if (id < 0 || id > MAX_POINTER_ID) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
LOGE("Motion event has invalid pointer id %d; value must be between 0 and %d",
Add unit tests for native input and fix bugs identified. Fixed a bug where we would lose the first touch point when swiping out of the virtual key area. Fixed a bug where we would not send an ACTION_MOVE event in cases where individual pointers went down/up and the remaining pointers actually moved. This is important since many applications do not handle pointer movements during ACTION_POINTER_DOWN or ACTION_POINTER_UP. In the case of ACTION_POINTER_UP the movement was completely lost since all pointers were dispatched using their old location rather than the new location. Improved motion event validation to check for duplicate pointer ids. Added an input source constant that was missing from the NDK api but defined in the framework api. Added a timestamp when reporting added/removed devices in EventHub. Bug: 3070082 Change-Id: I3206a030f43b7616e2f48006e5a9d522c4d92e56
2010-10-20 15:33:38 -07:00
id, MAX_POINTER_ID);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
return false;
}
Add unit tests for native input and fix bugs identified. Fixed a bug where we would lose the first touch point when swiping out of the virtual key area. Fixed a bug where we would not send an ACTION_MOVE event in cases where individual pointers went down/up and the remaining pointers actually moved. This is important since many applications do not handle pointer movements during ACTION_POINTER_DOWN or ACTION_POINTER_UP. In the case of ACTION_POINTER_UP the movement was completely lost since all pointers were dispatched using their old location rather than the new location. Improved motion event validation to check for duplicate pointer ids. Added an input source constant that was missing from the NDK api but defined in the framework api. Added a timestamp when reporting added/removed devices in EventHub. Bug: 3070082 Change-Id: I3206a030f43b7616e2f48006e5a9d522c4d92e56
2010-10-20 15:33:38 -07:00
if (pointerIdBits.hasBit(id)) {
LOGE("Motion event has duplicate pointer id %d", id);
return false;
}
pointerIdBits.markBit(id);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
return true;
}
Support non-rectangular input regions. This enables the system bar to carve out a region through which events will be sent to the IME behind it. Bug: 3238092 Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
2011-01-16 14:06:57 -08:00
static void dumpRegion(String8& dump, const SkRegion& region) {
if (region.isEmpty()) {
dump.append("<empty>");
return;
}
bool first = true;
for (SkRegion::Iterator it(region); !it.done(); it.next()) {
if (first) {
first = false;
} else {
dump.append("|");
}
const SkIRect& rect = it.rect();
dump.appendFormat("[%d,%d][%d,%d]", rect.fLeft, rect.fTop, rect.fRight, rect.fBottom);
}
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
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
2010-04-22 18:58:52 -07:00
// --- InputDispatcher ---
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
2010-06-15 01:31:58 -07:00
InputDispatcher::InputDispatcher(const sp<InputDispatcherPolicyInterface>& policy) :
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mPolicy(policy),
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
mPendingEvent(NULL), mAppSwitchSawKeyDown(false), mAppSwitchDueTime(LONG_LONG_MAX),
mNextUnblockedEvent(NULL),
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
mDispatchEnabled(true), mDispatchFrozen(false), mInputFilterEnabled(false),
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mCurrentInputTargetsValid(false),
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mInputTargetWaitCause(INPUT_TARGET_WAIT_CAUSE_NONE) {
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
2010-09-13 23:17:30 -07:00
mLooper = new Looper(false);
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
2010-04-22 18:58:52 -07:00
mKeyRepeatState.lastKeyEntry = NULL;
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
2010-06-15 01:31:58 -07:00
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
policy->getDispatcherConfiguration(&mConfig);
mThrottleState.minTimeBetweenEvents = 1000000000LL / mConfig.maxEventsPerSecond;
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
mThrottleState.lastDeviceId = -1;
#if DEBUG_THROTTLING
mThrottleState.originalSampleCount = 0;
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
LOGD("Throttling - Max events per second = %d", mConfig.maxEventsPerSecond);
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
#endif
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
2010-04-22 18:58:52 -07:00
}
InputDispatcher::~InputDispatcher() {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
{ // acquire lock
AutoMutex _l(mLock);
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
resetKeyRepeatLocked();
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
releasePendingEventLocked();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
drainInboundQueueLocked();
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
2010-04-22 18:58:52 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
while (mConnectionsByReceiveFd.size() != 0) {
unregisterInputChannel(mConnectionsByReceiveFd.valueAt(0)->inputChannel);
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
2010-04-22 18:58:52 -07:00
}
}
void InputDispatcher::dispatchOnce() {
nsecs_t nextWakeupTime = LONG_LONG_MAX;
{ // acquire lock
AutoMutex _l(mLock);
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
dispatchOnceInnerLocked(&nextWakeupTime);
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (runCommandsLockedInterruptible()) {
nextWakeupTime = LONG_LONG_MIN; // force next poll to wake up immediately
}
} // release lock
// Wait for callback or timeout or wake. (make sure we round up, not down)
nsecs_t currentTime = now();
Refactor how timeouts are calculated. Added a timeout mechanism to EventHub and InputReader so that InputMappers can request timeouts to perform delayed processing of input when needed. Change-Id: Iec2045baaf4e67690b15eef3c09a58d5cac76897
2011-03-17 01:34:19 -07:00
int timeoutMillis = toMillisecondTimeoutDelay(currentTime, nextWakeupTime);
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
2010-09-13 23:17:30 -07:00
mLooper->pollOnce(timeoutMillis);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
void InputDispatcher::dispatchOnceInnerLocked(nsecs_t* nextWakeupTime) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
nsecs_t currentTime = now();
// Reset the key repeat timer whenever we disallow key events, even if the next event
// is not a key. This is to ensure that we abort a key repeat if the device is just coming
// out of sleep.
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
if (!mPolicy->isKeyRepeatEnabled()) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
resetKeyRepeatLocked();
}
// If dispatching is frozen, do not process timeouts or try to deliver any new events.
if (mDispatchFrozen) {
#if DEBUG_FOCUS
LOGD("Dispatch frozen. Waiting some more.");
#endif
return;
}
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Optimize latency of app switches.
// Essentially we start a short timeout when an app switch key (HOME / ENDCALL) has
// been pressed. When it expires, we preempt dispatch and drop all other pending events.
bool isAppSwitchDue = mAppSwitchDueTime <= currentTime;
if (mAppSwitchDueTime < *nextWakeupTime) {
*nextWakeupTime = mAppSwitchDueTime;
}
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Ready to start a new event.
// If we don't already have a pending event, go grab one.
if (! mPendingEvent) {
if (mInboundQueue.isEmpty()) {
if (isAppSwitchDue) {
// The inbound queue is empty so the app switch key we were waiting
// for will never arrive. Stop waiting for it.
resetPendingAppSwitchLocked(false);
isAppSwitchDue = false;
}
// Synthesize a key repeat if appropriate.
if (mKeyRepeatState.lastKeyEntry) {
if (currentTime >= mKeyRepeatState.nextRepeatTime) {
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
mPendingEvent = synthesizeKeyRepeatLocked(currentTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
} else {
if (mKeyRepeatState.nextRepeatTime < *nextWakeupTime) {
*nextWakeupTime = mKeyRepeatState.nextRepeatTime;
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
2010-04-22 18:58:52 -07:00
}
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2011-08-30 20:34:48 -07:00
// Nothing to do if there is no pending event.
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (! mPendingEvent) {
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
2011-08-30 20:34:48 -07:00
if (mActiveConnections.isEmpty()) {
dispatchIdleLocked();
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
return;
}
} else {
// Inbound queue has at least one entry.
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
EventEntry* entry = mInboundQueue.head;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Throttle the entry if it is a move event and there are no
// other events behind it in the queue. Due to movement batching, additional
// samples may be appended to this event by the time the throttling timeout
// expires.
// TODO Make this smarter and consider throttling per device independently.
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
if (entry->type == EventEntry::TYPE_MOTION
&& !isAppSwitchDue
&& mDispatchEnabled
&& (entry->policyFlags & POLICY_FLAG_PASS_TO_USER)
&& !entry->isInjected()) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
MotionEntry* motionEntry = static_cast<MotionEntry*>(entry);
int32_t deviceId = motionEntry->deviceId;
uint32_t source = motionEntry->source;
if (! isAppSwitchDue
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
&& !motionEntry->next // exactly one event, no successors
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
&& (motionEntry->action == AMOTION_EVENT_ACTION_MOVE
|| motionEntry->action == AMOTION_EVENT_ACTION_HOVER_MOVE)
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
&& deviceId == mThrottleState.lastDeviceId
&& source == mThrottleState.lastSource) {
nsecs_t nextTime = mThrottleState.lastEventTime
+ mThrottleState.minTimeBetweenEvents;
if (currentTime < nextTime) {
// Throttle it!
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
#if DEBUG_THROTTLING
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
LOGD("Throttling - Delaying motion event for "
Improve support for external keyboards. Use Vendor ID, Product ID and optionally the Version to locate keymaps and configuration files for external devices. Moved virtual key definition parsing to native code so that EventHub can identify touch screens with virtual keys and load the appropriate key layout file. Cleaned up a lot of old code in EventHub. Fixed a regression in ViewRoot's fallback event handling. Fixed a minor bug in FileMap that caused it to try to munmap or close invalid handled when released if the attempt to map the file failed. Added a couple of new String8 conveniences for formatting strings. Modified Tokenizer to fall back to open+read when mmap fails since we can't mmap sysfs files as needed to open the virtual key definition files in /sys/board_properties/. Change-Id: I6ca5e5f9547619fd082ddac47e87ce185da69ee6
2010-12-02 13:50:46 -08:00
"device %d, source 0x%08x by up to %0.3fms.",
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
deviceId, source, (nextTime - currentTime) * 0.000001);
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (nextTime < *nextWakeupTime) {
*nextWakeupTime = nextTime;
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (mThrottleState.originalSampleCount == 0) {
mThrottleState.originalSampleCount =
motionEntry->countSamples();
}
return;
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
#if DEBUG_THROTTLING
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (mThrottleState.originalSampleCount != 0) {
uint32_t count = motionEntry->countSamples();
LOGD("Throttling - Motion event sample count grew by %d from %d to %d.",
count - mThrottleState.originalSampleCount,
mThrottleState.originalSampleCount, count);
mThrottleState.originalSampleCount = 0;
}
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
#endif
Set last event time to previous event batch delivery time to apps Determination of the last event time. Currently, uses the time that the first event in the previous batch that was sent from hardware. This produces inconsistent timing intervals for event delivery to apps. Now, use the time that the previous batch was delivered to the application. Original Author: Stephen Moore <steve.moore@motorola.com> Signed-off-by: makarand.karvekar <makarand.karvekar@motorola.com> Change-Id: I2a3701915702d622dc04fbf4bbd4918a9ebe8856
2011-03-02 15:41:03 -06:00
mThrottleState.lastEventTime = currentTime;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mThrottleState.lastDeviceId = deviceId;
mThrottleState.lastSource = source;
}
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mInboundQueue.dequeue(entry);
mPendingEvent = entry;
}
Fix bug where home presses were not poking user activity. We now poke user activity twice: once upon dequeueing an event for dispatch and then again just before we dispatch it. The second poke is to compensate for the fact that it can take a few seconds to identify the dispatch target (if the application is responding slowly) but we want to keep the display from going to sleep for X amount of time after the app gets a chance to actually receive the event. This mirrors pre-Gingerbread behavior. Removed some unnecessary code that filters user activity pokes when sending events to KeyGuard. We don't need this because KeyGuard already tells the power manager to disable user activity. Bug: 3101397 Change-Id: I8c3a77601fdef8f584e84cfdd11aa79da0ff51db
2010-10-18 13:21:23 -07:00
// Poke user activity for this event.
if (mPendingEvent->policyFlags & POLICY_FLAG_PASS_TO_USER) {
pokeUserActivityLocked(mPendingEvent);
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Now we have an event to dispatch.
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
// All events are eventually dequeued and processed this way, even if we intend to drop them.
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(mPendingEvent != NULL);
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
bool done = false;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
DropReason dropReason = DROP_REASON_NOT_DROPPED;
if (!(mPendingEvent->policyFlags & POLICY_FLAG_PASS_TO_USER)) {
dropReason = DROP_REASON_POLICY;
} else if (!mDispatchEnabled) {
dropReason = DROP_REASON_DISABLED;
}
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
if (mNextUnblockedEvent == mPendingEvent) {
mNextUnblockedEvent = NULL;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
switch (mPendingEvent->type) {
case EventEntry::TYPE_CONFIGURATION_CHANGED: {
ConfigurationChangedEntry* typedEntry =
static_cast<ConfigurationChangedEntry*>(mPendingEvent);
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
done = dispatchConfigurationChangedLocked(currentTime, typedEntry);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
dropReason = DROP_REASON_NOT_DROPPED; // configuration changes are never dropped
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
break;
}
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
2010-04-22 18:58:52 -07:00
Input system bug fixes, particularly for stylus. Bug: 5049148 Finished stylus support, including support for indirect stylus and mouse tools. Added TILT axis. When stylus tilt X/Y is available, it is transformed into an orientation and tilt inclination which is a more convenient representation and a simpler extension to the exiting API. Touch devices now only report touch data using a single input source. Previously touch devices in pointer mode would report both absolute touch pad data and cooked pointer gestures. Now we just pick one. The touch device switches modes as needed when the focused application enables/disables pointer gestures. This change greatly simplifies the code and reduces the load on the input dispatcher. Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE would be zero whenever the stylus was in direct contact. It appears that the correct way to determine whether the stylus is in direct contact (rather than hovering) is by checking for a non-zero reported pressure. Added code to read the initial state of tool buttons and axis values when the input devices are initialized or reset. This fixes problems where the input mapper state might have the wrong initial state. Moved responsibility for cancelling pending inputs (keys down, touches, etc.) to the InputDispatcher by sending it a device reset notification. This frees the InputReader from having to synthesize events during reset, which was cumbersome and somewhat brittle to begin with. Consolidated more of the common accumulator logic from SingleTouchInputMapper and MultiTouchInputMapper into TouchInputMapper. Improved the PointerLocation output. Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
2011-08-18 11:20:58 -07:00
case EventEntry::TYPE_DEVICE_RESET: {
DeviceResetEntry* typedEntry =
static_cast<DeviceResetEntry*>(mPendingEvent);
done = dispatchDeviceResetLocked(currentTime, typedEntry);
dropReason = DROP_REASON_NOT_DROPPED; // device resets are never dropped
break;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
case EventEntry::TYPE_KEY: {
KeyEntry* typedEntry = static_cast<KeyEntry*>(mPendingEvent);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
if (isAppSwitchDue) {
if (isAppSwitchKeyEventLocked(typedEntry)) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
resetPendingAppSwitchLocked(true);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
isAppSwitchDue = false;
} else if (dropReason == DROP_REASON_NOT_DROPPED) {
dropReason = DROP_REASON_APP_SWITCH;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
if (dropReason == DROP_REASON_NOT_DROPPED
&& isStaleEventLocked(currentTime, typedEntry)) {
dropReason = DROP_REASON_STALE;
}
if (dropReason == DROP_REASON_NOT_DROPPED && mNextUnblockedEvent) {
dropReason = DROP_REASON_BLOCKED;
}
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
done = dispatchKeyLocked(currentTime, typedEntry, &dropReason, nextWakeupTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
break;
}
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
case EventEntry::TYPE_MOTION: {
MotionEntry* typedEntry = static_cast<MotionEntry*>(mPendingEvent);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
if (dropReason == DROP_REASON_NOT_DROPPED && isAppSwitchDue) {
dropReason = DROP_REASON_APP_SWITCH;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
if (dropReason == DROP_REASON_NOT_DROPPED
&& isStaleEventLocked(currentTime, typedEntry)) {
dropReason = DROP_REASON_STALE;
}
if (dropReason == DROP_REASON_NOT_DROPPED && mNextUnblockedEvent) {
dropReason = DROP_REASON_BLOCKED;
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
done = dispatchMotionLocked(currentTime, typedEntry,
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
&dropReason, nextWakeupTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
break;
}
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
2010-06-15 01:31:58 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
default:
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(false);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
break;
}
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
if (done) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
if (dropReason != DROP_REASON_NOT_DROPPED) {
dropInboundEventLocked(mPendingEvent, dropReason);
}
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
releasePendingEventLocked();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
*nextWakeupTime = LONG_LONG_MIN; // force next poll to wake up immediately
}
}
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
2010-06-15 01:31:58 -07:00
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
2011-08-30 20:34:48 -07:00
void InputDispatcher::dispatchIdleLocked() {
#if DEBUG_FOCUS
LOGD("Dispatcher idle. There are no pending events or active connections.");
#endif
// Reset targets when idle, to release input channels and other resources
// they are holding onto.
resetTargetsLocked();
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
bool InputDispatcher::enqueueInboundEventLocked(EventEntry* entry) {
bool needWake = mInboundQueue.isEmpty();
mInboundQueue.enqueueAtTail(entry);
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
switch (entry->type) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
case EventEntry::TYPE_KEY: {
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
// Optimize app switch latency.
// If the application takes too long to catch up then we drop all events preceding
// the app switch key.
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
KeyEntry* keyEntry = static_cast<KeyEntry*>(entry);
if (isAppSwitchKeyEventLocked(keyEntry)) {
if (keyEntry->action == AKEY_EVENT_ACTION_DOWN) {
mAppSwitchSawKeyDown = true;
} else if (keyEntry->action == AKEY_EVENT_ACTION_UP) {
if (mAppSwitchSawKeyDown) {
#if DEBUG_APP_SWITCH
LOGD("App switch is pending!");
#endif
mAppSwitchDueTime = keyEntry->eventTime + APP_SWITCH_TIMEOUT;
mAppSwitchSawKeyDown = false;
needWake = true;
}
}
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
break;
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
2010-06-15 01:31:58 -07:00
}
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
case EventEntry::TYPE_MOTION: {
// Optimize case where the current application is unresponsive and the user
// decides to touch a window in a different application.
// If the application takes too long to catch up then we drop all events preceding
// the touch into the other window.
MotionEntry* motionEntry = static_cast<MotionEntry*>(entry);
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
2011-02-24 20:55:35 -08:00
if (motionEntry->action == AMOTION_EVENT_ACTION_DOWN
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
&& (motionEntry->source & AINPUT_SOURCE_CLASS_POINTER)
&& mInputTargetWaitCause == INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
&& mInputTargetWaitApplicationHandle != NULL) {
Add support for arbitrary axes in MotionEvents. This change makes it possible to extend the set of axes that are reported in MotionEvents by defining new axis constants. The MotionEvent object is now backed by its C++ counterpart to avoid having to maintain multiple representations of the same data. Change-Id: Ibe93c90d4b390d43c176cce48d558d20869ee608
2011-02-14 17:03:18 -08:00
int32_t x = int32_t(motionEntry->firstSample.pointerCoords[0].
Fix a regression with MotionEvent parceling. Also added some more unit tests. Change-Id: I413654294d1a998eec056884e6df5eaa50f3daf4
2011-02-17 13:01:34 -08:00
getAxisValue(AMOTION_EVENT_AXIS_X));
Add support for arbitrary axes in MotionEvents. This change makes it possible to extend the set of axes that are reported in MotionEvents by defining new axis constants. The MotionEvent object is now backed by its C++ counterpart to avoid having to maintain multiple representations of the same data. Change-Id: Ibe93c90d4b390d43c176cce48d558d20869ee608
2011-02-14 17:03:18 -08:00
int32_t y = int32_t(motionEntry->firstSample.pointerCoords[0].
Fix a regression with MotionEvent parceling. Also added some more unit tests. Change-Id: I413654294d1a998eec056884e6df5eaa50f3daf4
2011-02-17 13:01:34 -08:00
getAxisValue(AMOTION_EVENT_AXIS_Y));
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> touchedWindowHandle = findTouchedWindowAtLocked(x, y);
if (touchedWindowHandle != NULL
&& touchedWindowHandle->inputApplicationHandle
!= mInputTargetWaitApplicationHandle) {
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
// User touched a different application than the one we are waiting on.
// Flag the event, and start pruning the input queue.
mNextUnblockedEvent = motionEntry;
needWake = true;
}
}
break;
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
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
2010-06-15 01:31:58 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
return needWake;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> InputDispatcher::findTouchedWindowAtLocked(int32_t x, int32_t y) {
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
// Traverse windows from front to back to find touched window.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
size_t numWindows = mWindowHandles.size();
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
for (size_t i = 0; i < numWindows; i++) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> windowHandle = mWindowHandles.itemAt(i);
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
2011-08-30 20:34:48 -07:00
const InputWindowInfo* windowInfo = windowHandle->getInfo();
int32_t flags = windowInfo->layoutParamsFlags;
if (windowInfo->visible) {
if (!(flags & InputWindowInfo::FLAG_NOT_TOUCHABLE)) {
bool isTouchModal = (flags & (InputWindowInfo::FLAG_NOT_FOCUSABLE
| InputWindowInfo::FLAG_NOT_TOUCH_MODAL)) == 0;
if (isTouchModal || windowInfo->touchableRegionContainsPoint(x, y)) {
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
// Found window.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
return windowHandle;
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
}
}
}
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
2011-08-30 20:34:48 -07:00
if (flags & InputWindowInfo::FLAG_SYSTEM_ERROR) {
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
// Error window is on top but not visible, so touch is dropped.
return NULL;
}
}
return NULL;
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
void InputDispatcher::dropInboundEventLocked(EventEntry* entry, DropReason dropReason) {
const char* reason;
switch (dropReason) {
case DROP_REASON_POLICY:
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
#if DEBUG_INBOUND_EVENT_DETAILS
Improve the input policy handling a bit. Fixed some issues with Monkeys turning off their own screens. Ook ook! Added some more comments to explain what's going on. Change-Id: Id2bc0466161a642a73ef7ef97725d1c81e984b12
2010-10-11 23:32:49 -07:00
LOGD("Dropped event because policy consumed it.");
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
#endif
Improve the input policy handling a bit. Fixed some issues with Monkeys turning off their own screens. Ook ook! Added some more comments to explain what's going on. Change-Id: Id2bc0466161a642a73ef7ef97725d1c81e984b12
2010-10-11 23:32:49 -07:00
reason = "inbound event was dropped because the policy consumed it";
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
break;
case DROP_REASON_DISABLED:
LOGI("Dropped event because input dispatch is disabled.");
reason = "inbound event was dropped because input dispatch is disabled";
break;
case DROP_REASON_APP_SWITCH:
LOGI("Dropped event because of pending overdue app switch.");
reason = "inbound event was dropped because of pending overdue app switch";
break;
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
case DROP_REASON_BLOCKED:
LOGI("Dropped event because the current application is not responding and the user "
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
"has started interacting with a different application.");
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
reason = "inbound event was dropped because the current application is not responding "
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
"and the user has started interacting with a different application";
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
break;
case DROP_REASON_STALE:
LOGI("Dropped event because it is stale.");
reason = "inbound event was dropped because it is stale";
break;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
default:
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(false);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
return;
}
switch (entry->type) {
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
case EventEntry::TYPE_KEY: {
CancelationOptions options(CancelationOptions::CANCEL_NON_POINTER_EVENTS, reason);
synthesizeCancelationEventsForAllConnectionsLocked(options);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
break;
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
case EventEntry::TYPE_MOTION: {
MotionEntry* motionEntry = static_cast<MotionEntry*>(entry);
if (motionEntry->source & AINPUT_SOURCE_CLASS_POINTER) {
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
CancelationOptions options(CancelationOptions::CANCEL_POINTER_EVENTS, reason);
synthesizeCancelationEventsForAllConnectionsLocked(options);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
} else {
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
CancelationOptions options(CancelationOptions::CANCEL_NON_POINTER_EVENTS, reason);
synthesizeCancelationEventsForAllConnectionsLocked(options);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
break;
}
}
}
bool InputDispatcher::isAppSwitchKeyCode(int32_t keyCode) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
return keyCode == AKEYCODE_HOME || keyCode == AKEYCODE_ENDCALL;
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
bool InputDispatcher::isAppSwitchKeyEventLocked(KeyEntry* keyEntry) {
return ! (keyEntry->flags & AKEY_EVENT_FLAG_CANCELED)
&& isAppSwitchKeyCode(keyEntry->keyCode)
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
&& (keyEntry->policyFlags & POLICY_FLAG_TRUSTED)
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
&& (keyEntry->policyFlags & POLICY_FLAG_PASS_TO_USER);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
bool InputDispatcher::isAppSwitchPendingLocked() {
return mAppSwitchDueTime != LONG_LONG_MAX;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
void InputDispatcher::resetPendingAppSwitchLocked(bool handled) {
mAppSwitchDueTime = LONG_LONG_MAX;
#if DEBUG_APP_SWITCH
if (handled) {
LOGD("App switch has arrived.");
} else {
LOGD("App switch was abandoned.");
}
#endif
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
2010-04-22 18:58:52 -07:00
}
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
bool InputDispatcher::isStaleEventLocked(nsecs_t currentTime, EventEntry* entry) {
return currentTime - entry->eventTime >= STALE_EVENT_TIMEOUT;
}
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
2010-06-15 01:31:58 -07:00
bool InputDispatcher::runCommandsLockedInterruptible() {
if (mCommandQueue.isEmpty()) {
return false;
}
do {
CommandEntry* commandEntry = mCommandQueue.dequeueAtHead();
Command command = commandEntry->command;
(this->*command)(commandEntry); // commands are implicitly 'LockedInterruptible'
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
commandEntry->connection.clear();
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
delete commandEntry;
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
2010-06-15 01:31:58 -07:00
} while (! mCommandQueue.isEmpty());
return true;
}
InputDispatcher::CommandEntry* InputDispatcher::postCommandLocked(Command command) {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
CommandEntry* commandEntry = new CommandEntry(command);
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
2010-06-15 01:31:58 -07:00
mCommandQueue.enqueueAtTail(commandEntry);
return commandEntry;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::drainInboundQueueLocked() {
while (! mInboundQueue.isEmpty()) {
EventEntry* entry = mInboundQueue.dequeueAtHead();
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
releaseInboundEventLocked(entry);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
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
2010-06-15 01:31:58 -07:00
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
void InputDispatcher::releasePendingEventLocked() {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (mPendingEvent) {
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
releaseInboundEventLocked(mPendingEvent);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mPendingEvent = NULL;
}
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
2010-04-22 18:58:52 -07:00
}
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
void InputDispatcher::releaseInboundEventLocked(EventEntry* entry) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
InjectionState* injectionState = entry->injectionState;
if (injectionState && injectionState->injectionResult == INPUT_EVENT_INJECTION_PENDING) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_DISPATCH_CYCLE
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
LOGD("Injected inbound event was dropped.");
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
2010-04-22 18:58:52 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
setInjectionResultLocked(entry, INPUT_EVENT_INJECTION_FAILED);
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
2010-04-22 18:58:52 -07:00
}
Fix blocked event handling in InputDispatcher. Bug: 5161854 The InputDispatcher contains code to recover from ANRs more quickly when the user touches a different application. When triggered, it sets mNextUnblockedEvent to the next event it should dispatch (to the next application). All prior events are dropped. This change fixes a bug where mNextUnblockedEvent could potentially never be reset back to NULL if the inbound queue was drained for some reason. Change-Id: I21be2f02c9fc770bd260ea414db8bb184df89ada
2011-08-15 12:55:32 -07:00
if (entry == mNextUnblockedEvent) {
mNextUnblockedEvent = NULL;
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
entry->release();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::resetKeyRepeatLocked() {
if (mKeyRepeatState.lastKeyEntry) {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
mKeyRepeatState.lastKeyEntry->release();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mKeyRepeatState.lastKeyEntry = NULL;
}
}
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
InputDispatcher::KeyEntry* InputDispatcher::synthesizeKeyRepeatLocked(nsecs_t currentTime) {
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
2010-06-22 01:27:15 -07:00
KeyEntry* entry = mKeyRepeatState.lastKeyEntry;
// Reuse the repeated key entry if it is otherwise unreferenced.
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
uint32_t policyFlags = (entry->policyFlags & POLICY_FLAG_RAW_MASK)
| POLICY_FLAG_PASS_TO_USER | POLICY_FLAG_TRUSTED;
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
2010-04-22 18:58:52 -07:00
if (entry->refCount == 1) {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
entry->recycle();
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
entry->eventTime = currentTime;
entry->policyFlags = policyFlags;
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
2010-04-22 18:58:52 -07:00
entry->repeatCount += 1;
} else {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
KeyEntry* newEntry = new KeyEntry(currentTime,
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
2010-07-14 18:48:53 -07:00
entry->deviceId, entry->source, policyFlags,
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
entry->action, entry->flags, entry->keyCode, entry->scanCode,
More native input dispatch work. Removed old input dispatch code. Refactored the policy callbacks. Pushed a tiny bit of the power manager state down to native. Fixed long press on MENU. Made the virtual key detection and cancelation a bit more precise. Change-Id: I5d8c1062f7ea0ab3b54c6fadb058c4d5f5a9e02e
2010-07-02 15:37:36 -07:00
entry->metaState, entry->repeatCount + 1, entry->downTime);
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
2010-04-22 18:58:52 -07:00
mKeyRepeatState.lastKeyEntry = newEntry;
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
entry->release();
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
2010-04-22 18:58:52 -07:00
entry = newEntry;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
entry->syntheticRepeat = true;
// Increment reference count since we keep a reference to the event in
// mKeyRepeatState.lastKeyEntry in addition to the one we return.
entry->refCount += 1;
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
2010-04-22 18:58:52 -07:00
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
mKeyRepeatState.nextRepeatTime = currentTime + mConfig.keyRepeatDelay;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
return entry;
}
bool InputDispatcher::dispatchConfigurationChangedLocked(
nsecs_t currentTime, ConfigurationChangedEntry* entry) {
#if DEBUG_OUTBOUND_EVENT_DETAILS
LOGD("dispatchConfigurationChanged - eventTime=%lld", entry->eventTime);
#endif
// Reset key repeating in case a keyboard device was added or removed or something.
resetKeyRepeatLocked();
// Enqueue a command to run outside the lock to tell the policy that the configuration changed.
CommandEntry* commandEntry = postCommandLocked(
& InputDispatcher::doNotifyConfigurationChangedInterruptible);
commandEntry->eventTime = entry->eventTime;
return true;
}
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
2010-04-22 18:58:52 -07:00
Input system bug fixes, particularly for stylus. Bug: 5049148 Finished stylus support, including support for indirect stylus and mouse tools. Added TILT axis. When stylus tilt X/Y is available, it is transformed into an orientation and tilt inclination which is a more convenient representation and a simpler extension to the exiting API. Touch devices now only report touch data using a single input source. Previously touch devices in pointer mode would report both absolute touch pad data and cooked pointer gestures. Now we just pick one. The touch device switches modes as needed when the focused application enables/disables pointer gestures. This change greatly simplifies the code and reduces the load on the input dispatcher. Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE would be zero whenever the stylus was in direct contact. It appears that the correct way to determine whether the stylus is in direct contact (rather than hovering) is by checking for a non-zero reported pressure. Added code to read the initial state of tool buttons and axis values when the input devices are initialized or reset. This fixes problems where the input mapper state might have the wrong initial state. Moved responsibility for cancelling pending inputs (keys down, touches, etc.) to the InputDispatcher by sending it a device reset notification. This frees the InputReader from having to synthesize events during reset, which was cumbersome and somewhat brittle to begin with. Consolidated more of the common accumulator logic from SingleTouchInputMapper and MultiTouchInputMapper into TouchInputMapper. Improved the PointerLocation output. Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
2011-08-18 11:20:58 -07:00
bool InputDispatcher::dispatchDeviceResetLocked(
nsecs_t currentTime, DeviceResetEntry* entry) {
#if DEBUG_OUTBOUND_EVENT_DETAILS
LOGD("dispatchDeviceReset - eventTime=%lld, deviceId=%d", entry->eventTime, entry->deviceId);
#endif
CancelationOptions options(CancelationOptions::CANCEL_ALL_EVENTS,
"device was reset");
options.deviceId = entry->deviceId;
synthesizeCancelationEventsForAllConnectionsLocked(options);
return true;
}
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
bool InputDispatcher::dispatchKeyLocked(nsecs_t currentTime, KeyEntry* entry,
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
DropReason* dropReason, nsecs_t* nextWakeupTime) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Preprocessing.
if (! entry->dispatchInProgress) {
if (entry->repeatCount == 0
&& entry->action == AKEY_EVENT_ACTION_DOWN
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
&& (entry->policyFlags & POLICY_FLAG_TRUSTED)
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
&& (!(entry->policyFlags & POLICY_FLAG_DISABLE_KEY_REPEAT))) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (mKeyRepeatState.lastKeyEntry
&& mKeyRepeatState.lastKeyEntry->keyCode == entry->keyCode) {
// We have seen two identical key downs in a row which indicates that the device
// driver is automatically generating key repeats itself. We take note of the
// repeat here, but we disable our own next key repeat timer since it is clear that
// we will not need to synthesize key repeats ourselves.
entry->repeatCount = mKeyRepeatState.lastKeyEntry->repeatCount + 1;
resetKeyRepeatLocked();
mKeyRepeatState.nextRepeatTime = LONG_LONG_MAX; // don't generate repeats ourselves
} else {
// Not a repeat. Save key down state in case we do see a repeat later.
resetKeyRepeatLocked();
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
mKeyRepeatState.nextRepeatTime = entry->eventTime + mConfig.keyRepeatTimeout;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
mKeyRepeatState.lastKeyEntry = entry;
entry->refCount += 1;
} else if (! entry->syntheticRepeat) {
resetKeyRepeatLocked();
}
Only set KeyEvent long press flag when repeat count equals 1. This fixes a Gingerbread regression. Bug: 3507021 Change-Id: I8c2acb35be718fea7e996175c1407e84315d17ef
2011-03-02 20:34:30 -08:00
if (entry->repeatCount == 1) {
entry->flags |= AKEY_EVENT_FLAG_LONG_PRESS;
} else {
entry->flags &= ~AKEY_EVENT_FLAG_LONG_PRESS;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
entry->dispatchInProgress = true;
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
resetTargetsLocked();
Fix a key repeating bug. This change fixes a bug in the dispatcher where the window manager policy would incorrectly receive a key repeat count of 0 in the case where the key repeat was generated by the hardware or driver. Long-press on HOME was broken as a result. Bug: 3159581 Change-Id: If0f02662313f5b879a4e566fbb461389e274a550
2010-11-02 17:58:22 -07:00
logOutboundKeyDetailsLocked("dispatchKey - ", entry);
}
Improve screenshot chord debouncing. Bug: 5011907 Introduce a 150ms delay in handling volume down keys while waiting to see if a power key will follow. Don't trigger the screenshot chord if both volume up and volume down are pressed together. Don't trigger the long-press power menu if volume keys are also pressed. Require the user to press both keys in the chord within the debounce time and continue long-pressing them in order to trigger the screenshot action. Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
2011-10-12 13:57:59 -07:00
// Handle case where the policy asked us to try again later last time.
if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER) {
if (currentTime < entry->interceptKeyWakeupTime) {
if (entry->interceptKeyWakeupTime < *nextWakeupTime) {
*nextWakeupTime = entry->interceptKeyWakeupTime;
}
return false; // wait until next wakeup
}
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_UNKNOWN;
entry->interceptKeyWakeupTime = 0;
}
Fix a key repeating bug. This change fixes a bug in the dispatcher where the window manager policy would incorrectly receive a key repeat count of 0 in the case where the key repeat was generated by the hardware or driver. Long-press on HOME was broken as a result. Bug: 3159581 Change-Id: If0f02662313f5b879a4e566fbb461389e274a550
2010-11-02 17:58:22 -07:00
// Give the policy a chance to intercept the key.
if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_UNKNOWN) {
if (entry->policyFlags & POLICY_FLAG_PASS_TO_USER) {
CommandEntry* commandEntry = postCommandLocked(
& InputDispatcher::doInterceptKeyBeforeDispatchingLockedInterruptible);
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mFocusedWindowHandle != NULL) {
commandEntry->inputWindowHandle = mFocusedWindowHandle;
Fix a key repeating bug. This change fixes a bug in the dispatcher where the window manager policy would incorrectly receive a key repeat count of 0 in the case where the key repeat was generated by the hardware or driver. Long-press on HOME was broken as a result. Bug: 3159581 Change-Id: If0f02662313f5b879a4e566fbb461389e274a550
2010-11-02 17:58:22 -07:00
}
commandEntry->keyEntry = entry;
entry->refCount += 1;
return false; // wait for the command to run
} else {
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_CONTINUE;
}
} else if (entry->interceptKeyResult == KeyEntry::INTERCEPT_KEY_RESULT_SKIP) {
if (*dropReason == DROP_REASON_NOT_DROPPED) {
*dropReason = DROP_REASON_POLICY;
}
}
// Clean up if dropping the event.
if (*dropReason != DROP_REASON_NOT_DROPPED) {
resetTargetsLocked();
setInjectionResultLocked(entry, *dropReason == DROP_REASON_POLICY
? INPUT_EVENT_INJECTION_SUCCEEDED : INPUT_EVENT_INJECTION_FAILED);
return true;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
// Identify targets.
if (! mCurrentInputTargetsValid) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t injectionResult = findFocusedWindowTargetsLocked(currentTime,
entry, nextWakeupTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (injectionResult == INPUT_EVENT_INJECTION_PENDING) {
return false;
}
setInjectionResultLocked(entry, injectionResult);
if (injectionResult != INPUT_EVENT_INJECTION_SUCCEEDED) {
return true;
}
addMonitoringTargetsLocked();
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
commitTargetsLocked();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
// Dispatch the key.
dispatchEventToCurrentInputTargetsLocked(currentTime, entry, false);
return true;
}
void InputDispatcher::logOutboundKeyDetailsLocked(const char* prefix, const KeyEntry* entry) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Improve support for external keyboards. Use Vendor ID, Product ID and optionally the Version to locate keymaps and configuration files for external devices. Moved virtual key definition parsing to native code so that EventHub can identify touch screens with virtual keys and load the appropriate key layout file. Cleaned up a lot of old code in EventHub. Fixed a regression in ViewRoot's fallback event handling. Fixed a minor bug in FileMap that caused it to try to munmap or close invalid handled when released if the attempt to map the file failed. Added a couple of new String8 conveniences for formatting strings. Modified Tokenizer to fall back to open+read when mmap fails since we can't mmap sysfs files as needed to open the virtual key definition files in /sys/board_properties/. Change-Id: I6ca5e5f9547619fd082ddac47e87ce185da69ee6
2010-12-02 13:50:46 -08:00
LOGD("%seventTime=%lld, deviceId=%d, source=0x%x, policyFlags=0x%x, "
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
2010-04-22 18:58:52 -07:00
"action=0x%x, flags=0x%x, keyCode=0x%x, scanCode=0x%x, metaState=0x%x, "
Fix a key repeating bug. This change fixes a bug in the dispatcher where the window manager policy would incorrectly receive a key repeat count of 0 in the case where the key repeat was generated by the hardware or driver. Long-press on HOME was broken as a result. Bug: 3159581 Change-Id: If0f02662313f5b879a4e566fbb461389e274a550
2010-11-02 17:58:22 -07:00
"repeatCount=%d, downTime=%lld",
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
prefix,
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
2010-07-14 18:48:53 -07:00
entry->eventTime, entry->deviceId, entry->source, entry->policyFlags,
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
2010-04-22 18:58:52 -07:00
entry->action, entry->flags, entry->keyCode, entry->scanCode, entry->metaState,
Fix a key repeating bug. This change fixes a bug in the dispatcher where the window manager policy would incorrectly receive a key repeat count of 0 in the case where the key repeat was generated by the hardware or driver. Long-press on HOME was broken as a result. Bug: 3159581 Change-Id: If0f02662313f5b879a4e566fbb461389e274a550
2010-11-02 17:58:22 -07:00
entry->repeatCount, entry->downTime);
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
2010-04-22 18:58:52 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
bool InputDispatcher::dispatchMotionLocked(
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
nsecs_t currentTime, MotionEntry* entry, DropReason* dropReason, nsecs_t* nextWakeupTime) {
Fix a key repeating bug. This change fixes a bug in the dispatcher where the window manager policy would incorrectly receive a key repeat count of 0 in the case where the key repeat was generated by the hardware or driver. Long-press on HOME was broken as a result. Bug: 3159581 Change-Id: If0f02662313f5b879a4e566fbb461389e274a550
2010-11-02 17:58:22 -07:00
// Preprocessing.
if (! entry->dispatchInProgress) {
entry->dispatchInProgress = true;
resetTargetsLocked();
logOutboundMotionDetailsLocked("dispatchMotion - ", entry);
}
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
// Clean up if dropping the event.
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
if (*dropReason != DROP_REASON_NOT_DROPPED) {
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
resetTargetsLocked();
Improve the input policy handling a bit. Fixed some issues with Monkeys turning off their own screens. Ook ook! Added some more comments to explain what's going on. Change-Id: Id2bc0466161a642a73ef7ef97725d1c81e984b12
2010-10-11 23:32:49 -07:00
setInjectionResultLocked(entry, *dropReason == DROP_REASON_POLICY
? INPUT_EVENT_INJECTION_SUCCEEDED : INPUT_EVENT_INJECTION_FAILED);
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
return true;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
bool isPointerEvent = entry->source & AINPUT_SOURCE_CLASS_POINTER;
// Identify targets.
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
bool conflictingPointerActions = false;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (! mCurrentInputTargetsValid) {
int32_t injectionResult;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
const MotionSample* splitBatchAfterSample = NULL;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (isPointerEvent) {
// Pointer event. (eg. touchscreen)
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionResult = findTouchedWindowTargetsLocked(currentTime,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
entry, nextWakeupTime, &conflictingPointerActions, &splitBatchAfterSample);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
} else {
// Non touch event. (eg. trackball)
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionResult = findFocusedWindowTargetsLocked(currentTime,
entry, nextWakeupTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
if (injectionResult == INPUT_EVENT_INJECTION_PENDING) {
return false;
}
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
setInjectionResultLocked(entry, injectionResult);
if (injectionResult != INPUT_EVENT_INJECTION_SUCCEEDED) {
return true;
}
addMonitoringTargetsLocked();
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
commitTargetsLocked();
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Unbatch the event if necessary by splitting it into two parts after the
// motion sample indicated by splitBatchAfterSample.
if (splitBatchAfterSample && splitBatchAfterSample->next) {
#if DEBUG_BATCHING
uint32_t originalSampleCount = entry->countSamples();
#endif
MotionSample* nextSample = splitBatchAfterSample->next;
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
MotionEntry* nextEntry = new MotionEntry(nextSample->eventTime,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
entry->deviceId, entry->source, entry->policyFlags,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
entry->action, entry->flags,
entry->metaState, entry->buttonState, entry->edgeFlags,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
entry->xPrecision, entry->yPrecision, entry->downTime,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
entry->pointerCount, entry->pointerProperties, nextSample->pointerCoords);
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
if (nextSample != entry->lastSample) {
nextEntry->firstSample.next = nextSample->next;
nextEntry->lastSample = entry->lastSample;
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
delete nextSample;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
entry->lastSample = const_cast<MotionSample*>(splitBatchAfterSample);
entry->lastSample->next = NULL;
if (entry->injectionState) {
nextEntry->injectionState = entry->injectionState;
entry->injectionState->refCount += 1;
}
#if DEBUG_BATCHING
LOGD("Split batch of %d samples into two parts, first part has %d samples, "
"second part has %d samples.", originalSampleCount,
entry->countSamples(), nextEntry->countSamples());
#endif
mInboundQueue.enqueueAtHead(nextEntry);
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
// Dispatch the motion.
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
if (conflictingPointerActions) {
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
CancelationOptions options(CancelationOptions::CANCEL_POINTER_EVENTS,
"conflicting pointer actions");
synthesizeCancelationEventsForAllConnectionsLocked(options);
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
dispatchEventToCurrentInputTargetsLocked(currentTime, entry, false);
return true;
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
2010-04-22 18:58:52 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::logOutboundMotionDetailsLocked(const char* prefix, const MotionEntry* entry) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Improve support for external keyboards. Use Vendor ID, Product ID and optionally the Version to locate keymaps and configuration files for external devices. Moved virtual key definition parsing to native code so that EventHub can identify touch screens with virtual keys and load the appropriate key layout file. Cleaned up a lot of old code in EventHub. Fixed a regression in ViewRoot's fallback event handling. Fixed a minor bug in FileMap that caused it to try to munmap or close invalid handled when released if the attempt to map the file failed. Added a couple of new String8 conveniences for formatting strings. Modified Tokenizer to fall back to open+read when mmap fails since we can't mmap sysfs files as needed to open the virtual key definition files in /sys/board_properties/. Change-Id: I6ca5e5f9547619fd082ddac47e87ce185da69ee6
2010-12-02 13:50:46 -08:00
LOGD("%seventTime=%lld, deviceId=%d, source=0x%x, policyFlags=0x%x, "
Add support for secure views. Added the MotionEvent.FLAG_WINDOW_IS_OBSCURED flag which is set by the input manager whenever another visible window is partly or wholly obscured the target of a touch event so that applications can filter touches accordingly. Added a "filterTouchesWhenObscured" attribute to View which can be used to enable filtering of touches when the view's window is obscured. Change-Id: I936d9c85013fd2d77fb296a600528d30a29027d2
2010-09-01 17:01:00 -07:00
"action=0x%x, flags=0x%x, "
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
"metaState=0x%x, buttonState=0x%x, "
"edgeFlags=0x%x, xPrecision=%f, yPrecision=%f, downTime=%lld",
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
prefix,
Add support for secure views. Added the MotionEvent.FLAG_WINDOW_IS_OBSCURED flag which is set by the input manager whenever another visible window is partly or wholly obscured the target of a touch event so that applications can filter touches accordingly. Added a "filterTouchesWhenObscured" attribute to View which can be used to enable filtering of touches when the view's window is obscured. Change-Id: I936d9c85013fd2d77fb296a600528d30a29027d2
2010-09-01 17:01:00 -07:00
entry->eventTime, entry->deviceId, entry->source, entry->policyFlags,
entry->action, entry->flags,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
entry->metaState, entry->buttonState,
entry->edgeFlags, entry->xPrecision, entry->yPrecision,
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
2010-04-22 18:58:52 -07:00
entry->downTime);
// Print the most recent sample that we have available, this may change due to batching.
size_t sampleCount = 1;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
const MotionSample* sample = & entry->firstSample;
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
2010-04-22 18:58:52 -07:00
for (; sample->next != NULL; sample = sample->next) {
sampleCount += 1;
}
for (uint32_t i = 0; i < entry->pointerCount; i++) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
LOGD(" Pointer %d: id=%d, toolType=%d, "
"x=%f, y=%f, pressure=%f, size=%f, "
Add support for secure views. Added the MotionEvent.FLAG_WINDOW_IS_OBSCURED flag which is set by the input manager whenever another visible window is partly or wholly obscured the target of a touch event so that applications can filter touches accordingly. Added a "filterTouchesWhenObscured" attribute to View which can be used to enable filtering of touches when the view's window is obscured. Change-Id: I936d9c85013fd2d77fb296a600528d30a29027d2
2010-09-01 17:01:00 -07:00
"touchMajor=%f, touchMinor=%f, toolMajor=%f, toolMinor=%f, "
Input device calibration and capabilities. Finished the input device capability API. Added a mechanism for calibrating touch devices to obtain more accurate information about the touch contact area. Improved pointer location to show new coordinates and capabilities. Optimized pointer location display and formatting to avoid allocating large numbers of temporary objects. The GC churn was causing the application to stutter very badly when more than a couple of fingers were down). Added more diagnostics. Change-Id: Ie25380278ed6f16c5b04cd9df848015850383498
2010-08-30 03:02:23 -07:00
"orientation=%f",
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
i, entry->pointerProperties[i].id,
entry->pointerProperties[i].toolType,
Fix a regression with MotionEvent parceling. Also added some more unit tests. Change-Id: I413654294d1a998eec056884e6df5eaa50f3daf4
2011-02-17 13:01:34 -08:00
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_X),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_Y),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_PRESSURE),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_SIZE),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOUCH_MAJOR),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOUCH_MINOR),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOOL_MAJOR),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOOL_MINOR),
sample->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_ORIENTATION));
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
2010-04-22 18:58:52 -07:00
}
// Keep in mind that due to batching, it is possible for the number of samples actually
// dispatched to change before the application finally consumed them.
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
2010-07-14 18:48:53 -07:00
if (entry->action == AMOTION_EVENT_ACTION_MOVE) {
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
2010-04-22 18:58:52 -07:00
LOGD(" ... Total movement samples currently batched %d ...", sampleCount);
}
#endif
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::dispatchEventToCurrentInputTargetsLocked(nsecs_t currentTime,
EventEntry* eventEntry, bool resumeWithAppendedMotionSample) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_DISPATCH_CYCLE
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
LOGD("dispatchEventToCurrentInputTargets - "
"resumeWithAppendedMotionSample=%s",
toString(resumeWithAppendedMotionSample));
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
2010-04-22 18:58:52 -07:00
#endif
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(eventEntry->dispatchInProgress); // should already have been set to true
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
2010-06-15 01:31:58 -07:00
Fix bug where home presses were not poking user activity. We now poke user activity twice: once upon dequeueing an event for dispatch and then again just before we dispatch it. The second poke is to compensate for the fact that it can take a few seconds to identify the dispatch target (if the application is responding slowly) but we want to keep the display from going to sleep for X amount of time after the app gets a chance to actually receive the event. This mirrors pre-Gingerbread behavior. Removed some unnecessary code that filters user activity pokes when sending events to KeyGuard. We don't need this because KeyGuard already tells the power manager to disable user activity. Bug: 3101397 Change-Id: I8c3a77601fdef8f584e84cfdd11aa79da0ff51db
2010-10-18 13:21:23 -07:00
pokeUserActivityLocked(eventEntry);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
for (size_t i = 0; i < mCurrentInputTargets.size(); i++) {
const InputTarget& inputTarget = mCurrentInputTargets.itemAt(i);
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
2010-04-22 18:58:52 -07:00
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
ssize_t connectionIndex = getConnectionIndexLocked(inputTarget.inputChannel);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (connectionIndex >= 0) {
sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);
prepareDispatchCycleLocked(currentTime, connection, eventEntry, & inputTarget,
resumeWithAppendedMotionSample);
} else {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#if DEBUG_FOCUS
LOGD("Dropping event delivery to target with channel '%s' because it "
"is no longer registered with the input dispatcher.",
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
inputTarget.inputChannel->getName().string());
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
}
Fix app switch latency optimization. This optimization was broken due to recent changes in how ANRs are handled. Change-Id: Ic99248a12755fadac8d4893e7d305b773e038d3d
2010-09-16 14:07:33 -07:00
void InputDispatcher::resetTargetsLocked() {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mCurrentInputTargetsValid = false;
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
2010-04-22 18:58:52 -07:00
mCurrentInputTargets.clear();
Reset input dispatcher targets when focus changes apps. This fixes an issue where an ANR can occur in a newly focused application through no fault of its own, simply because the previous app took a little while to transfer focus to the new app. Bug: 4584620 Change-Id: If3227eb68d92a09a108e9de7f0afcbd9a5dbdead
2011-07-27 11:50:51 -07:00
resetANRTimeoutsLocked();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-04-22 18:58:52 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
void InputDispatcher::commitTargetsLocked() {
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
2010-06-15 01:31:58 -07:00
mCurrentInputTargetsValid = true;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
int32_t InputDispatcher::handleTargetsNotReadyLocked(nsecs_t currentTime,
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
const EventEntry* entry,
const sp<InputApplicationHandle>& applicationHandle,
const sp<InputWindowHandle>& windowHandle,
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
nsecs_t* nextWakeupTime) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (applicationHandle == NULL && windowHandle == NULL) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (mInputTargetWaitCause != INPUT_TARGET_WAIT_CAUSE_SYSTEM_NOT_READY) {
#if DEBUG_FOCUS
LOGD("Waiting for system to become ready for input.");
#endif
mInputTargetWaitCause = INPUT_TARGET_WAIT_CAUSE_SYSTEM_NOT_READY;
mInputTargetWaitStartTime = currentTime;
mInputTargetWaitTimeoutTime = LONG_LONG_MAX;
mInputTargetWaitTimeoutExpired = false;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mInputTargetWaitApplicationHandle.clear();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
} else {
if (mInputTargetWaitCause != INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY) {
#if DEBUG_FOCUS
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
LOGD("Waiting for application to become ready for input: %s",
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
getApplicationWindowLabelLocked(applicationHandle, windowHandle).string());
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
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
2011-08-30 20:34:48 -07:00
nsecs_t timeout;
if (windowHandle != NULL) {
timeout = windowHandle->getDispatchingTimeout(DEFAULT_INPUT_DISPATCHING_TIMEOUT);
} else if (applicationHandle != NULL) {
timeout = applicationHandle->getDispatchingTimeout(
DEFAULT_INPUT_DISPATCHING_TIMEOUT);
} else {
timeout = DEFAULT_INPUT_DISPATCHING_TIMEOUT;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mInputTargetWaitCause = INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY;
mInputTargetWaitStartTime = currentTime;
mInputTargetWaitTimeoutTime = currentTime + timeout;
mInputTargetWaitTimeoutExpired = false;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mInputTargetWaitApplicationHandle.clear();
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (windowHandle != NULL) {
mInputTargetWaitApplicationHandle = windowHandle->inputApplicationHandle;
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mInputTargetWaitApplicationHandle == NULL && applicationHandle != NULL) {
mInputTargetWaitApplicationHandle = applicationHandle;
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
if (mInputTargetWaitTimeoutExpired) {
return INPUT_EVENT_INJECTION_TIMED_OUT;
}
if (currentTime >= mInputTargetWaitTimeoutTime) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
onANRLocked(currentTime, applicationHandle, windowHandle,
entry->eventTime, mInputTargetWaitStartTime);
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
2010-06-15 01:31:58 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Force poll loop to wake up immediately on next iteration once we get the
// ANR response back from the policy.
*nextWakeupTime = LONG_LONG_MIN;
return INPUT_EVENT_INJECTION_PENDING;
} else {
// Force poll loop to wake up when timeout is due.
if (mInputTargetWaitTimeoutTime < *nextWakeupTime) {
*nextWakeupTime = mInputTargetWaitTimeoutTime;
}
return INPUT_EVENT_INJECTION_PENDING;
}
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
void InputDispatcher::resumeAfterTargetsNotReadyTimeoutLocked(nsecs_t newTimeout,
const sp<InputChannel>& inputChannel) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (newTimeout > 0) {
// Extend the timeout.
mInputTargetWaitTimeoutTime = now() + newTimeout;
} else {
// Give up.
mInputTargetWaitTimeoutExpired = true;
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Release the touch targets.
mTouchState.reset();
Fix input dispatcher regression on launcher drag&drop. Change-Id: I40e937bd712cd2ed6cceac95dfd1b8c8e070724f
2010-09-16 12:31:46 -07:00
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
// Input state will not be realistic. Mark it out of sync.
Fix NPE when handling certain kinds of ANRs. Change-Id: Iccef1852e52c84f6f49d30c491431460a10b33d3
2010-09-16 11:02:16 -07:00
if (inputChannel.get()) {
ssize_t connectionIndex = getConnectionIndexLocked(inputChannel);
if (connectionIndex >= 0) {
sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);
Fix race condition in fallback key processing. Need to ensure that the channel is still valid before proceeding. Bug: 3271482 Change-Id: Ia6863cbedd9b53cbc5c9c8815e9ea90bef3d2218
2010-12-09 18:10:30 -08:00
if (connection->status == Connection::STATUS_NORMAL) {
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
CancelationOptions options(CancelationOptions::CANCEL_ALL_EVENTS,
Fix race condition in fallback key processing. Need to ensure that the channel is still valid before proceeding. Bug: 3271482 Change-Id: Ia6863cbedd9b53cbc5c9c8815e9ea90bef3d2218
2010-12-09 18:10:30 -08:00
"application not responding");
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
synthesizeCancelationEventsForConnectionLocked(connection, options);
Fix race condition in fallback key processing. Need to ensure that the channel is still valid before proceeding. Bug: 3271482 Change-Id: Ia6863cbedd9b53cbc5c9c8815e9ea90bef3d2218
2010-12-09 18:10:30 -08:00
}
Fix NPE when handling certain kinds of ANRs. Change-Id: Iccef1852e52c84f6f49d30c491431460a10b33d3
2010-09-16 11:02:16 -07:00
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
}
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
2010-06-22 01:27:15 -07:00
}
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
2010-04-22 18:58:52 -07:00
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
nsecs_t InputDispatcher::getTimeSpentWaitingForApplicationLocked(
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
nsecs_t currentTime) {
if (mInputTargetWaitCause == INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY) {
return currentTime - mInputTargetWaitStartTime;
}
return 0;
}
void InputDispatcher::resetANRTimeoutsLocked() {
#if DEBUG_FOCUS
LOGD("Resetting ANR timeouts.");
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
2010-04-22 18:58:52 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Reset input target wait timeout.
mInputTargetWaitCause = INPUT_TARGET_WAIT_CAUSE_NONE;
Reset input dispatcher targets when focus changes apps. This fixes an issue where an ANR can occur in a newly focused application through no fault of its own, simply because the previous app took a little while to transfer focus to the new app. Bug: 4584620 Change-Id: If3227eb68d92a09a108e9de7f0afcbd9a5dbdead
2011-07-27 11:50:51 -07:00
mInputTargetWaitApplicationHandle.clear();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-04-22 18:58:52 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t InputDispatcher::findFocusedWindowTargetsLocked(nsecs_t currentTime,
const EventEntry* entry, nsecs_t* nextWakeupTime) {
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
2010-04-22 18:58:52 -07:00
mCurrentInputTargets.clear();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
int32_t injectionResult;
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
2010-06-15 01:31:58 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// If there is no currently focused window and no focused application
// then drop the event.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mFocusedWindowHandle == NULL) {
if (mFocusedApplicationHandle != NULL) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
LOGD("Waiting because there is no focused window but there is a "
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
"focused application that may eventually add a window: %s.",
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
getApplicationWindowLabelLocked(mFocusedApplicationHandle, NULL).string());
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mFocusedApplicationHandle, NULL, nextWakeupTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
goto Unresponsive;
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
LOGI("Dropping event because there is no focused window or focused application.");
injectionResult = INPUT_EVENT_INJECTION_FAILED;
goto Failed;
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
2010-06-22 01:27:15 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Check permissions.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (! checkInjectionPermission(mFocusedWindowHandle, entry->injectionState)) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
injectionResult = INPUT_EVENT_INJECTION_PERMISSION_DENIED;
goto Failed;
}
// If the currently focused window is paused then keep waiting.
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
2011-08-30 20:34:48 -07:00
if (mFocusedWindowHandle->getInfo()->paused) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
LOGD("Waiting because focused window is paused.");
#endif
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mFocusedApplicationHandle, mFocusedWindowHandle, nextWakeupTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
goto Unresponsive;
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
// If the currently focused window is still working on previous events then keep waiting.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (! isWindowFinishedWithPreviousInputLocked(mFocusedWindowHandle)) {
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
#if DEBUG_FOCUS
LOGD("Waiting because focused window still processing previous input.");
#endif
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mFocusedApplicationHandle, mFocusedWindowHandle, nextWakeupTime);
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
goto Unresponsive;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Success! Output targets.
injectionResult = INPUT_EVENT_INJECTION_SUCCEEDED;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
addWindowTargetLocked(mFocusedWindowHandle,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS, BitSet32(0));
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Done.
Failed:
Unresponsive:
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
nsecs_t timeSpentWaitingForApplication = getTimeSpentWaitingForApplicationLocked(currentTime);
updateDispatchStatisticsLocked(currentTime, entry,
injectionResult, timeSpentWaitingForApplication);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
LOGD("findFocusedWindow finished: injectionResult=%d, "
"timeSpendWaitingForApplication=%0.1fms",
injectionResult, timeSpentWaitingForApplication / 1000000.0);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
return injectionResult;
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
2010-04-22 18:58:52 -07:00
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t InputDispatcher::findTouchedWindowTargetsLocked(nsecs_t currentTime,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
const MotionEntry* entry, nsecs_t* nextWakeupTime, bool* outConflictingPointerActions,
const MotionSample** outSplitBatchAfterSample) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
enum InjectionPermission {
INJECTION_PERMISSION_UNKNOWN,
INJECTION_PERMISSION_GRANTED,
INJECTION_PERMISSION_DENIED
};
mCurrentInputTargets.clear();
nsecs_t startTime = now();
// For security reasons, we defer updating the touch state until we are sure that
// event injection will be allowed.
//
// FIXME In the original code, screenWasOff could never be set to true.
// The reason is that the POLICY_FLAG_WOKE_HERE
// and POLICY_FLAG_BRIGHT_HERE flags were set only when preprocessing raw
// EV_KEY, EV_REL and EV_ABS events. As it happens, the touch event was
// actually enqueued using the policyFlags that appeared in the final EV_SYN
// events upon which no preprocessing took place. So policyFlags was always 0.
// In the new native input dispatcher we're a bit more careful about event
// preprocessing so the touches we receive can actually have non-zero policyFlags.
// Unfortunately we obtain undesirable behavior.
//
// Here's what happens:
//
// When the device dims in anticipation of going to sleep, touches
// in windows which have FLAG_TOUCHABLE_WHEN_WAKING cause
// the device to brighten and reset the user activity timer.
// Touches on other windows (such as the launcher window)
// are dropped. Then after a moment, the device goes to sleep. Oops.
//
// Also notice how screenWasOff was being initialized using POLICY_FLAG_BRIGHT_HERE
// instead of POLICY_FLAG_WOKE_HERE...
//
bool screenWasOff = false; // original policy: policyFlags & POLICY_FLAG_BRIGHT_HERE;
int32_t action = entry->action;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t maskedAction = action & AMOTION_EVENT_ACTION_MASK;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Update the touch state as needed based on the properties of the touch event.
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t injectionResult = INPUT_EVENT_INJECTION_PENDING;
InjectionPermission injectionPermission = INJECTION_PERMISSION_UNKNOWN;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> newHoverWindowHandle;
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
bool isSplit = mTouchState.split;
Query input device for initial slot index. This fixes a problem where touches can get stuck because the driver and the framework have different ideas of what the initial slot index is. The framework assumed it was slot 0 but it could in principle be any slot, such as slot 1. When that happened, the framework would start tracking the first touch as slot 0, but it might never receive an "up" for that slot. Change-Id: Idaffc4534b275d66b9d4360987b28dc2d0f63218
2011-06-30 23:53:07 -07:00
bool switchedDevice = mTouchState.deviceId >= 0
&& (mTouchState.deviceId != entry->deviceId
|| mTouchState.source != entry->source);
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
bool isHoverAction = (maskedAction == AMOTION_EVENT_ACTION_HOVER_MOVE
|| maskedAction == AMOTION_EVENT_ACTION_HOVER_ENTER
|| maskedAction == AMOTION_EVENT_ACTION_HOVER_EXIT);
bool newGesture = (maskedAction == AMOTION_EVENT_ACTION_DOWN
|| maskedAction == AMOTION_EVENT_ACTION_SCROLL
|| isHoverAction);
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
bool wrongDevice = false;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
if (newGesture) {
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
bool down = maskedAction == AMOTION_EVENT_ACTION_DOWN;
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
if (switchedDevice && mTouchState.down && !down) {
#if DEBUG_FOCUS
LOGD("Dropping event because a pointer for a different device is already down.");
#endif
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
mTempTouchState.copyFrom(mTouchState);
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
injectionResult = INPUT_EVENT_INJECTION_FAILED;
switchedDevice = false;
wrongDevice = true;
goto Failed;
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
mTempTouchState.reset();
mTempTouchState.down = down;
mTempTouchState.deviceId = entry->deviceId;
mTempTouchState.source = entry->source;
isSplit = false;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
} else {
mTempTouchState.copyFrom(mTouchState);
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
2011-02-19 05:07:28 -08:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
if (newGesture || (isSplit && maskedAction == AMOTION_EVENT_ACTION_POINTER_DOWN)) {
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
2011-02-24 20:55:35 -08:00
/* Case 1: New splittable pointer going down, or need target for hover or scroll. */
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
const MotionSample* sample = &entry->firstSample;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t pointerIndex = getMotionEventActionPointerIndex(action);
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
int32_t x = int32_t(sample->pointerCoords[pointerIndex].
Fix a regression with MotionEvent parceling. Also added some more unit tests. Change-Id: I413654294d1a998eec056884e6df5eaa50f3daf4
2011-02-17 13:01:34 -08:00
getAxisValue(AMOTION_EVENT_AXIS_X));
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
int32_t y = int32_t(sample->pointerCoords[pointerIndex].
Fix a regression with MotionEvent parceling. Also added some more unit tests. Change-Id: I413654294d1a998eec056884e6df5eaa50f3daf4
2011-02-17 13:01:34 -08:00
getAxisValue(AMOTION_EVENT_AXIS_Y));
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> newTouchedWindowHandle;
sp<InputWindowHandle> topErrorWindowHandle;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
bool isTouchModal = false;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Traverse windows from front to back to find touched window and outside targets.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
size_t numWindows = mWindowHandles.size();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
for (size_t i = 0; i < numWindows; i++) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> windowHandle = mWindowHandles.itemAt(i);
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
2011-08-30 20:34:48 -07:00
const InputWindowInfo* windowInfo = windowHandle->getInfo();
int32_t flags = windowInfo->layoutParamsFlags;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
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
2011-08-30 20:34:48 -07:00
if (flags & InputWindowInfo::FLAG_SYSTEM_ERROR) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (topErrorWindowHandle == NULL) {
topErrorWindowHandle = windowHandle;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
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
2011-08-30 20:34:48 -07:00
if (windowInfo->visible) {
if (! (flags & InputWindowInfo::FLAG_NOT_TOUCHABLE)) {
isTouchModal = (flags & (InputWindowInfo::FLAG_NOT_FOCUSABLE
| InputWindowInfo::FLAG_NOT_TOUCH_MODAL)) == 0;
if (isTouchModal || windowInfo->touchableRegionContainsPoint(x, y)) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (! screenWasOff
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
2011-08-30 20:34:48 -07:00
|| (flags & InputWindowInfo::FLAG_TOUCHABLE_WHEN_WAKING)) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
newTouchedWindowHandle = windowHandle;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
break; // found touched window, exit window loop
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
if (maskedAction == AMOTION_EVENT_ACTION_DOWN
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
2011-08-30 20:34:48 -07:00
&& (flags & InputWindowInfo::FLAG_WATCH_OUTSIDE_TOUCH)) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
int32_t outsideTargetFlags = InputTarget::FLAG_DISPATCH_AS_OUTSIDE;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (isWindowObscuredAtPointLocked(windowHandle, x, y)) {
Make secure views tolerate IME overlays. Change-Id: I3cf09b9d91045f4d9c558b4aace482a7b0bbd3d8
2010-10-05 12:26:23 -07:00
outsideTargetFlags |= InputTarget::FLAG_WINDOW_IS_OBSCURED;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(
windowHandle, outsideTargetFlags, BitSet32(0));
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
}
// If there is an error window but it is not taking focus (typically because
// it is invisible) then wait for it. Any other focused window may in
// fact be in ANR state.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (topErrorWindowHandle != NULL && newTouchedWindowHandle != topErrorWindowHandle) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
LOGD("Waiting because system error window is pending.");
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
2010-04-22 18:58:52 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
NULL, NULL, nextWakeupTime);
injectionPermission = INJECTION_PERMISSION_UNKNOWN;
goto Unresponsive;
}
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
2010-04-22 18:58:52 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Figure out whether splitting will be allowed for this window.
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
2011-08-30 20:34:48 -07:00
if (newTouchedWindowHandle != NULL
&& newTouchedWindowHandle->getInfo()->supportsSplitTouch()) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// New window supports splitting.
isSplit = true;
} else if (isSplit) {
// New window does not support splitting but we have already split events.
// Assign the pointer to the first foreground window we find.
// (May be NULL which is why we put this code block before the next check.)
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
newTouchedWindowHandle = mTempTouchState.getFirstForegroundWindowHandle();
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// If we did not find a touched window then fail.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (newTouchedWindowHandle == NULL) {
if (mFocusedApplicationHandle != NULL) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
LOGD("Waiting because there is no touched window but there is a "
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
"focused application that may eventually add a new window: %s.",
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
getApplicationWindowLabelLocked(mFocusedApplicationHandle, NULL).string());
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mFocusedApplicationHandle, NULL, nextWakeupTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
goto Unresponsive;
}
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
2010-06-15 01:31:58 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
LOGI("Dropping event because there is no touched window or focused application.");
injectionResult = INPUT_EVENT_INJECTION_FAILED;
goto Failed;
}
Make secure views tolerate IME overlays. Change-Id: I3cf09b9d91045f4d9c558b4aace482a7b0bbd3d8
2010-10-05 12:26:23 -07:00
// Set target flags.
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
int32_t targetFlags = InputTarget::FLAG_FOREGROUND | InputTarget::FLAG_DISPATCH_AS_IS;
Make secure views tolerate IME overlays. Change-Id: I3cf09b9d91045f4d9c558b4aace482a7b0bbd3d8
2010-10-05 12:26:23 -07:00
if (isSplit) {
targetFlags |= InputTarget::FLAG_SPLIT;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (isWindowObscuredAtPointLocked(newTouchedWindowHandle, x, y)) {
Make secure views tolerate IME overlays. Change-Id: I3cf09b9d91045f4d9c558b4aace482a7b0bbd3d8
2010-10-05 12:26:23 -07:00
targetFlags |= InputTarget::FLAG_WINDOW_IS_OBSCURED;
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Update hover state.
if (isHoverAction) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
newHoverWindowHandle = newTouchedWindowHandle;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Ensure all subsequent motion samples are also within the touched window.
// Set *outSplitBatchAfterSample to the sample before the first one that is not
// within the touched window.
if (!isTouchModal) {
while (sample->next) {
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
2011-08-30 20:34:48 -07:00
if (!newHoverWindowHandle->getInfo()->touchableRegionContainsPoint(
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
sample->next->pointerCoords[0].getAxisValue(AMOTION_EVENT_AXIS_X),
sample->next->pointerCoords[0].getAxisValue(AMOTION_EVENT_AXIS_Y))) {
*outSplitBatchAfterSample = sample;
break;
}
sample = sample->next;
}
}
} else if (maskedAction == AMOTION_EVENT_ACTION_SCROLL) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
newHoverWindowHandle = mLastHoverWindowHandle;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Update the temporary touch state.
BitSet32 pointerIds;
if (isSplit) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
uint32_t pointerId = entry->pointerProperties[pointerIndex].id;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
pointerIds.markBit(pointerId);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(newTouchedWindowHandle, targetFlags, pointerIds);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
} else {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
/* Case 2: Pointer move, up, cancel or non-splittable pointer down. */
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// If the pointer is not currently down, then ignore the event.
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
if (! mTempTouchState.down) {
Fix focused application handle. Fix a bug where we were always setting the focused application handle to NULL. This broke ANR processing while starting applications and caused input events to be dropped while starting applications. Bug: 4174573 Change-Id: Icd7b8c4c49ed73c41978f3ff076c2e5cd839a802
2011-03-25 11:58:46 -07:00
#if DEBUG_FOCUS
Tweak log messages a bit. Change-Id: Ifadf78c1ab8db49106216c70086f98860795c65f
2010-10-25 17:37:46 -07:00
LOGD("Dropping event because the pointer is not down or we previously "
"dropped the pointer down event.");
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
injectionResult = INPUT_EVENT_INJECTION_FAILED;
goto Failed;
}
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
// Check whether touches should slip outside of the current foreground window.
if (maskedAction == AMOTION_EVENT_ACTION_MOVE
&& entry->pointerCount == 1
&& mTempTouchState.isSlippery()) {
const MotionSample* sample = &entry->firstSample;
int32_t x = int32_t(sample->pointerCoords[0].getAxisValue(AMOTION_EVENT_AXIS_X));
int32_t y = int32_t(sample->pointerCoords[0].getAxisValue(AMOTION_EVENT_AXIS_Y));
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> oldTouchedWindowHandle =
mTempTouchState.getFirstForegroundWindowHandle();
sp<InputWindowHandle> newTouchedWindowHandle = findTouchedWindowAtLocked(x, y);
if (oldTouchedWindowHandle != newTouchedWindowHandle
&& newTouchedWindowHandle != NULL) {
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
#if DEBUG_FOCUS
LOGD("Touch is slipping out of window %s into window %s.",
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
2011-08-30 20:34:48 -07:00
oldTouchedWindowHandle->getName().string(),
newTouchedWindowHandle->getName().string());
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
#endif
// Make a slippery exit from the old window.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(oldTouchedWindowHandle,
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
InputTarget::FLAG_DISPATCH_AS_SLIPPERY_EXIT, BitSet32(0));
// Make a slippery entrance into the new window.
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
2011-08-30 20:34:48 -07:00
if (newTouchedWindowHandle->getInfo()->supportsSplitTouch()) {
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
isSplit = true;
}
int32_t targetFlags = InputTarget::FLAG_FOREGROUND
| InputTarget::FLAG_DISPATCH_AS_SLIPPERY_ENTER;
if (isSplit) {
targetFlags |= InputTarget::FLAG_SPLIT;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (isWindowObscuredAtPointLocked(newTouchedWindowHandle, x, y)) {
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
targetFlags |= InputTarget::FLAG_WINDOW_IS_OBSCURED;
}
BitSet32 pointerIds;
if (isSplit) {
pointerIds.markBit(entry->pointerProperties[0].id);
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(newTouchedWindowHandle, targetFlags, pointerIds);
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
// Split the batch here so we send exactly one sample.
*outSplitBatchAfterSample = &entry->firstSample;
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (newHoverWindowHandle != mLastHoverWindowHandle) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Split the batch here so we send exactly one sample as part of ENTER or EXIT.
*outSplitBatchAfterSample = &entry->firstSample;
// Let the previous window know that the hover sequence is over.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mLastHoverWindowHandle != NULL) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
#if DEBUG_HOVER
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
2011-08-30 20:34:48 -07:00
LOGD("Sending hover exit event to window %s.",
mLastHoverWindowHandle->getName().string());
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
#endif
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(mLastHoverWindowHandle,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
InputTarget::FLAG_DISPATCH_AS_HOVER_EXIT, BitSet32(0));
}
// Let the new window know that the hover sequence is starting.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (newHoverWindowHandle != NULL) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
#if DEBUG_HOVER
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
2011-08-30 20:34:48 -07:00
LOGD("Sending hover enter event to window %s.",
newHoverWindowHandle->getName().string());
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
#endif
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(newHoverWindowHandle,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
InputTarget::FLAG_DISPATCH_AS_HOVER_ENTER, BitSet32(0));
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Check permission to inject into all touched foreground windows and ensure there
// is at least one touched foreground window.
{
bool haveForegroundWindow = false;
for (size_t i = 0; i < mTempTouchState.windows.size(); i++) {
const TouchedWindow& touchedWindow = mTempTouchState.windows[i];
if (touchedWindow.targetFlags & InputTarget::FLAG_FOREGROUND) {
haveForegroundWindow = true;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (! checkInjectionPermission(touchedWindow.windowHandle,
entry->injectionState)) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionResult = INPUT_EVENT_INJECTION_PERMISSION_DENIED;
injectionPermission = INJECTION_PERMISSION_DENIED;
goto Failed;
}
}
}
if (! haveForegroundWindow) {
Fix focused application handle. Fix a bug where we were always setting the focused application handle to NULL. This broke ANR processing while starting applications and caused input events to be dropped while starting applications. Bug: 4174573 Change-Id: Icd7b8c4c49ed73c41978f3ff076c2e5cd839a802
2011-03-25 11:58:46 -07:00
#if DEBUG_FOCUS
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
LOGD("Dropping event because there is no touched foreground window to receive it.");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
injectionResult = INPUT_EVENT_INJECTION_FAILED;
goto Failed;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Permission granted to injection into all touched foreground windows.
injectionPermission = INJECTION_PERMISSION_GRANTED;
}
No position information for outside touches When a window registers to listen for outside touches, it doesn't need the position information for touches that land outside of its activity for normal use cases. This patch uses the foreground window's UID as a filter to determine whether to pass the position information. This will allow applications to continue to rely on touch information for inputs that were directed at one of its other windows. Bug: 4541250 Change-Id: If16eb1ec8404b797d991859eef55ac0a20a355a3
2011-06-02 15:16:05 -07:00
// Check whether windows listening for outside touches are owned by the same UID. If it is
// set the policy flag that we will not reveal coordinate information to this window.
if (maskedAction == AMOTION_EVENT_ACTION_DOWN) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> foregroundWindowHandle =
mTempTouchState.getFirstForegroundWindowHandle();
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
2011-08-30 20:34:48 -07:00
const int32_t foregroundWindowUid = foregroundWindowHandle->getInfo()->ownerUid;
No position information for outside touches When a window registers to listen for outside touches, it doesn't need the position information for touches that land outside of its activity for normal use cases. This patch uses the foreground window's UID as a filter to determine whether to pass the position information. This will allow applications to continue to rely on touch information for inputs that were directed at one of its other windows. Bug: 4541250 Change-Id: If16eb1ec8404b797d991859eef55ac0a20a355a3
2011-06-02 15:16:05 -07:00
for (size_t i = 0; i < mTempTouchState.windows.size(); i++) {
const TouchedWindow& touchedWindow = mTempTouchState.windows[i];
if (touchedWindow.targetFlags & InputTarget::FLAG_DISPATCH_AS_OUTSIDE) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> inputWindowHandle = touchedWindow.windowHandle;
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
2011-08-30 20:34:48 -07:00
if (inputWindowHandle->getInfo()->ownerUid != foregroundWindowUid) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(inputWindowHandle,
No position information for outside touches When a window registers to listen for outside touches, it doesn't need the position information for touches that land outside of its activity for normal use cases. This patch uses the foreground window's UID as a filter to determine whether to pass the position information. This will allow applications to continue to rely on touch information for inputs that were directed at one of its other windows. Bug: 4541250 Change-Id: If16eb1ec8404b797d991859eef55ac0a20a355a3
2011-06-02 15:16:05 -07:00
InputTarget::FLAG_ZERO_COORDS, BitSet32(0));
}
}
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Ensure all touched foreground windows are ready for new input.
for (size_t i = 0; i < mTempTouchState.windows.size(); i++) {
const TouchedWindow& touchedWindow = mTempTouchState.windows[i];
if (touchedWindow.targetFlags & InputTarget::FLAG_FOREGROUND) {
// If the touched window is paused then keep waiting.
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
2011-08-30 20:34:48 -07:00
if (touchedWindow.windowHandle->getInfo()->paused) {
Fix focused application handle. Fix a bug where we were always setting the focused application handle to NULL. This broke ANR processing while starting applications and caused input events to be dropped while starting applications. Bug: 4174573 Change-Id: Icd7b8c4c49ed73c41978f3ff076c2e5cd839a802
2011-03-25 11:58:46 -07:00
#if DEBUG_FOCUS
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
LOGD("Waiting because touched window is paused.");
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
#endif
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
NULL, touchedWindow.windowHandle, nextWakeupTime);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
goto Unresponsive;
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// If the touched window is still working on previous events then keep waiting.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (! isWindowFinishedWithPreviousInputLocked(touchedWindow.windowHandle)) {
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
#if DEBUG_FOCUS
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
LOGD("Waiting because touched window still processing previous input.");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
NULL, touchedWindow.windowHandle, nextWakeupTime);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
goto Unresponsive;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// If this is the first pointer going down and the touched window has a wallpaper
// then also add the touched wallpaper windows so they are locked in for the duration
// of the touch gesture.
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
2011-02-24 20:55:35 -08:00
// We do not collect wallpapers during HOVER_MOVE or SCROLL because the wallpaper
// engine only supports touch events. We would need to add a mechanism similar
// to View.onGenericMotionEvent to enable wallpapers to handle these events.
if (maskedAction == AMOTION_EVENT_ACTION_DOWN) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> foregroundWindowHandle =
mTempTouchState.getFirstForegroundWindowHandle();
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
2011-08-30 20:34:48 -07:00
if (foregroundWindowHandle->getInfo()->hasWallpaper) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
for (size_t i = 0; i < mWindowHandles.size(); i++) {
sp<InputWindowHandle> windowHandle = mWindowHandles.itemAt(i);
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
2011-08-30 20:34:48 -07:00
if (windowHandle->getInfo()->layoutParamsType
== InputWindowInfo::TYPE_WALLPAPER) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTempTouchState.addOrUpdateWindow(windowHandle,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
InputTarget::FLAG_WINDOW_IS_OBSCURED
| InputTarget::FLAG_DISPATCH_AS_IS,
BitSet32(0));
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Success! Output targets.
injectionResult = INPUT_EVENT_INJECTION_SUCCEEDED;
for (size_t i = 0; i < mTempTouchState.windows.size(); i++) {
const TouchedWindow& touchedWindow = mTempTouchState.windows.itemAt(i);
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
addWindowTargetLocked(touchedWindow.windowHandle, touchedWindow.targetFlags,
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
touchedWindow.pointerIds);
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Drop the outside or hover touch windows since we will not care about them
// in the next iteration.
mTempTouchState.filterNonAsIsTouchWindows();
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Failed:
// Check injection permission once and for all.
if (injectionPermission == INJECTION_PERMISSION_UNKNOWN) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
if (checkInjectionPermission(NULL, entry->injectionState)) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
injectionPermission = INJECTION_PERMISSION_GRANTED;
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
2010-04-22 18:58:52 -07:00
} else {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
injectionPermission = INJECTION_PERMISSION_DENIED;
}
}
// Update final pieces of touch state if the injector had permission.
if (injectionPermission == INJECTION_PERMISSION_GRANTED) {
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
if (!wrongDevice) {
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
if (switchedDevice) {
#if DEBUG_FOCUS
LOGD("Conflicting pointer actions: Switched to a different device.");
#endif
*outConflictingPointerActions = true;
}
if (isHoverAction) {
// Started hovering, therefore no longer down.
if (mTouchState.down) {
#if DEBUG_FOCUS
LOGD("Conflicting pointer actions: Hover received while pointer was down.");
#endif
*outConflictingPointerActions = true;
}
mTouchState.reset();
if (maskedAction == AMOTION_EVENT_ACTION_HOVER_ENTER
|| maskedAction == AMOTION_EVENT_ACTION_HOVER_MOVE) {
mTouchState.deviceId = entry->deviceId;
mTouchState.source = entry->source;
}
} else if (maskedAction == AMOTION_EVENT_ACTION_UP
|| maskedAction == AMOTION_EVENT_ACTION_CANCEL) {
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
// All pointers up or canceled.
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
2011-02-24 20:55:35 -08:00
mTouchState.reset();
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
} else if (maskedAction == AMOTION_EVENT_ACTION_DOWN) {
// First pointer went down.
if (mTouchState.down) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#if DEBUG_FOCUS
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
LOGD("Conflicting pointer actions: Down received while already down.");
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
*outConflictingPointerActions = true;
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
}
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
2011-02-24 20:55:35 -08:00
mTouchState.copyFrom(mTempTouchState);
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
} else if (maskedAction == AMOTION_EVENT_ACTION_POINTER_UP) {
// One pointer went up.
if (isSplit) {
int32_t pointerIndex = getMotionEventActionPointerIndex(action);
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
uint32_t pointerId = entry->pointerProperties[pointerIndex].id;
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
for (size_t i = 0; i < mTempTouchState.windows.size(); ) {
TouchedWindow& touchedWindow = mTempTouchState.windows.editItemAt(i);
if (touchedWindow.targetFlags & InputTarget::FLAG_SPLIT) {
touchedWindow.pointerIds.clearBit(pointerId);
if (touchedWindow.pointerIds.isEmpty()) {
mTempTouchState.windows.removeAt(i);
continue;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
i += 1;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
}
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
2011-02-24 20:55:35 -08:00
mTouchState.copyFrom(mTempTouchState);
} else if (maskedAction == AMOTION_EVENT_ACTION_SCROLL) {
// Discard temporary touch state since it was only valid for this action.
} else {
// Save changes to touch state as-is for all other actions.
mTouchState.copyFrom(mTempTouchState);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Update hover state.
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mLastHoverWindowHandle = newHoverWindowHandle;
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
} else {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
#if DEBUG_FOCUS
LOGD("Not updating touch focus because injection was denied.");
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Unresponsive:
Drop all dispatcher state when dispatcher is disabled. This patch makes the dispatcher drop all of its state when it is disabled (when the screen turns off). This ensures that the dispatcher does not get stuck thinking a pointer is still down if the screen turned off while the user was touching the display (such as a fat touch while hitting the power button). Bug: 3098344 Change-Id: If50ef5804870aa1acd3179fd4b40e3cda58dd39d
2010-10-27 18:43:51 -07:00
// Reset temporary touch state to ensure we release unnecessary references to input channels.
mTempTouchState.reset();
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
nsecs_t timeSpentWaitingForApplication = getTimeSpentWaitingForApplicationLocked(currentTime);
updateDispatchStatisticsLocked(currentTime, entry,
injectionResult, timeSpentWaitingForApplication);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
LOGD("findTouchedWindow finished: injectionResult=%d, injectionPermission=%d, "
"timeSpentWaitingForApplication=%0.1fms",
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
injectionResult, injectionPermission, timeSpentWaitingForApplication / 1000000.0);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
return injectionResult;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
void InputDispatcher::addWindowTargetLocked(const sp<InputWindowHandle>& windowHandle,
int32_t targetFlags, BitSet32 pointerIds) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mCurrentInputTargets.push();
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
2011-08-30 20:34:48 -07:00
const InputWindowInfo* windowInfo = windowHandle->getInfo();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
InputTarget& target = mCurrentInputTargets.editTop();
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
2011-08-30 20:34:48 -07:00
target.inputChannel = windowInfo->inputChannel;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
target.flags = targetFlags;
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
2011-08-30 20:34:48 -07:00
target.xOffset = - windowInfo->frameLeft;
target.yOffset = - windowInfo->frameTop;
target.scaleFactor = windowInfo->scaleFactor;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
target.pointerIds = pointerIds;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
void InputDispatcher::addMonitoringTargetsLocked() {
for (size_t i = 0; i < mMonitoringChannels.size(); i++) {
mCurrentInputTargets.push();
InputTarget& target = mCurrentInputTargets.editTop();
target.inputChannel = mMonitoringChannels[i];
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
target.flags = InputTarget::FLAG_DISPATCH_AS_IS;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
target.xOffset = 0;
target.yOffset = 0;
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
target.pointerIds.clear();
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
target.scaleFactor = 1.0f;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
bool InputDispatcher::checkInjectionPermission(const sp<InputWindowHandle>& windowHandle,
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
const InjectionState* injectionState) {
if (injectionState
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
2011-08-30 20:34:48 -07:00
&& (windowHandle == NULL
|| windowHandle->getInfo()->ownerUid != injectionState->injectorUid)
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
&& !hasInjectionPermission(injectionState->injectorPid, injectionState->injectorUid)) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (windowHandle != NULL) {
LOGW("Permission denied: injecting event from pid %d uid %d to window %s "
"owned by uid %d",
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
injectionState->injectorPid, injectionState->injectorUid,
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
2011-08-30 20:34:48 -07:00
windowHandle->getName().string(),
windowHandle->getInfo()->ownerUid);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
} else {
LOGW("Permission denied: injecting event from pid %d uid %d",
injectionState->injectorPid, injectionState->injectorUid);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
return false;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
return true;
}
Make secure views tolerate IME overlays. Change-Id: I3cf09b9d91045f4d9c558b4aace482a7b0bbd3d8
2010-10-05 12:26:23 -07:00
bool InputDispatcher::isWindowObscuredAtPointLocked(
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
const sp<InputWindowHandle>& windowHandle, int32_t x, int32_t y) const {
size_t numWindows = mWindowHandles.size();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
for (size_t i = 0; i < numWindows; i++) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> otherHandle = mWindowHandles.itemAt(i);
if (otherHandle == windowHandle) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
break;
}
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
2011-08-30 20:34:48 -07:00
const InputWindowInfo* otherInfo = otherHandle->getInfo();
if (otherInfo->visible && ! otherInfo->isTrustedOverlay()
&& otherInfo->frameContainsPoint(x, y)) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
return true;
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
2010-04-22 18:58:52 -07:00
}
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
return false;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
bool InputDispatcher::isWindowFinishedWithPreviousInputLocked(
const sp<InputWindowHandle>& windowHandle) {
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
2011-08-30 20:34:48 -07:00
ssize_t connectionIndex = getConnectionIndexLocked(windowHandle->getInputChannel());
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
if (connectionIndex >= 0) {
sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);
return connection->outboundQueue.isEmpty();
} else {
return true;
}
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
String8 InputDispatcher::getApplicationWindowLabelLocked(
const sp<InputApplicationHandle>& applicationHandle,
const sp<InputWindowHandle>& windowHandle) {
if (applicationHandle != NULL) {
if (windowHandle != NULL) {
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
2011-08-30 20:34:48 -07:00
String8 label(applicationHandle->getName());
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
label.append(" - ");
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
2011-08-30 20:34:48 -07:00
label.append(windowHandle->getName());
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
return label;
} else {
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
2011-08-30 20:34:48 -07:00
return applicationHandle->getName();
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
} else if (windowHandle != NULL) {
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
2011-08-30 20:34:48 -07:00
return windowHandle->getName();
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
} else {
return String8("<unknown application or window>");
}
}
Fix bug where home presses were not poking user activity. We now poke user activity twice: once upon dequeueing an event for dispatch and then again just before we dispatch it. The second poke is to compensate for the fact that it can take a few seconds to identify the dispatch target (if the application is responding slowly) but we want to keep the display from going to sleep for X amount of time after the app gets a chance to actually receive the event. This mirrors pre-Gingerbread behavior. Removed some unnecessary code that filters user activity pokes when sending events to KeyGuard. We don't need this because KeyGuard already tells the power manager to disable user activity. Bug: 3101397 Change-Id: I8c3a77601fdef8f584e84cfdd11aa79da0ff51db
2010-10-18 13:21:23 -07:00
void InputDispatcher::pokeUserActivityLocked(const EventEntry* eventEntry) {
Wake screen from external HID peripherals. Added some plumbing to enable the policy to intercept motion events when the screen is off to handle wakeup if needed. Added a basic concept of an external device to limit the scope of the wakeup policy to external devices only. The wakeup policy for internal devices should be based on explicit rules such as policy flags in key layout files. Moved isTouchEvent to native. Ensure the dispatcher sends the right event type to userActivity for non-touch pointer events like HOVER_MOVE and SCROLL. Bug: 3193114 Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
2011-03-02 19:23:13 -08:00
int32_t eventType = POWER_MANAGER_OTHER_EVENT;
Fix policy issues when screen is off. Rewrote interceptKeyBeforeQueueing to make the handling more systematic. Behavior should be identical except: - We never pass keys to applications when the screen is off and the keyguard is not showing (the proximity sensor turned off the screen). Previously we passed all non-wake keys through in this case which caused a bug on Crespo where the screen would come back on if a soft key was held at the time of power off because the resulting key up event would sneak in just before the keyguard was shown. It would then be passed through to the dispatcher which would poke user activity and wake up the screen. - We propagate the key flags when broadcasting media keys which ensures that recipients can tell when the key is canceled. - We ignore endcall or power if canceled (shouldn't happen anyways). Changed the input dispatcher to not poke user activity for canceled events since they are synthetic and should not wake the device. Changed the lock screen so that it does not poke the wake lock when the grab handle is released. This fixes a bug where the screen would come back on immediately if the power went off while the user was holding one of the grab handles because the sliding tab would receive an up event after screen turned off and release the grab handles. Fixed a couple of issues where media keys were being handled inconsistently or not at all, particularly in the case of the new PAUSE, PLAY and RECORD keys. Bug: 3144874 Change-Id: Ie630f5fb6f128cfdf94845f9428067045f42892c
2010-10-29 21:50:21 -07:00
switch (eventEntry->type) {
case EventEntry::TYPE_MOTION: {
Fix bug where home presses were not poking user activity. We now poke user activity twice: once upon dequeueing an event for dispatch and then again just before we dispatch it. The second poke is to compensate for the fact that it can take a few seconds to identify the dispatch target (if the application is responding slowly) but we want to keep the display from going to sleep for X amount of time after the app gets a chance to actually receive the event. This mirrors pre-Gingerbread behavior. Removed some unnecessary code that filters user activity pokes when sending events to KeyGuard. We don't need this because KeyGuard already tells the power manager to disable user activity. Bug: 3101397 Change-Id: I8c3a77601fdef8f584e84cfdd11aa79da0ff51db
2010-10-18 13:21:23 -07:00
const MotionEntry* motionEntry = static_cast<const MotionEntry*>(eventEntry);
Fix policy issues when screen is off. Rewrote interceptKeyBeforeQueueing to make the handling more systematic. Behavior should be identical except: - We never pass keys to applications when the screen is off and the keyguard is not showing (the proximity sensor turned off the screen). Previously we passed all non-wake keys through in this case which caused a bug on Crespo where the screen would come back on if a soft key was held at the time of power off because the resulting key up event would sneak in just before the keyguard was shown. It would then be passed through to the dispatcher which would poke user activity and wake up the screen. - We propagate the key flags when broadcasting media keys which ensures that recipients can tell when the key is canceled. - We ignore endcall or power if canceled (shouldn't happen anyways). Changed the input dispatcher to not poke user activity for canceled events since they are synthetic and should not wake the device. Changed the lock screen so that it does not poke the wake lock when the grab handle is released. This fixes a bug where the screen would come back on immediately if the power went off while the user was holding one of the grab handles because the sliding tab would receive an up event after screen turned off and release the grab handles. Fixed a couple of issues where media keys were being handled inconsistently or not at all, particularly in the case of the new PAUSE, PLAY and RECORD keys. Bug: 3144874 Change-Id: Ie630f5fb6f128cfdf94845f9428067045f42892c
2010-10-29 21:50:21 -07:00
if (motionEntry->action == AMOTION_EVENT_ACTION_CANCEL) {
return;
}
Wake screen from external HID peripherals. Added some plumbing to enable the policy to intercept motion events when the screen is off to handle wakeup if needed. Added a basic concept of an external device to limit the scope of the wakeup policy to external devices only. The wakeup policy for internal devices should be based on explicit rules such as policy flags in key layout files. Moved isTouchEvent to native. Ensure the dispatcher sends the right event type to userActivity for non-touch pointer events like HOVER_MOVE and SCROLL. Bug: 3193114 Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
2011-03-02 19:23:13 -08:00
if (MotionEvent::isTouchEvent(motionEntry->source, motionEntry->action)) {
The CHEEK_TOUCH stuff never worked. Remove it. Bug: 3104906 Change-Id: Ia37236ba1775fc3ec8c111e2e0b85b105e0dea6a
2010-11-08 09:48:20 -08:00
eventType = POWER_MANAGER_TOUCH_EVENT;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Fix policy issues when screen is off. Rewrote interceptKeyBeforeQueueing to make the handling more systematic. Behavior should be identical except: - We never pass keys to applications when the screen is off and the keyguard is not showing (the proximity sensor turned off the screen). Previously we passed all non-wake keys through in this case which caused a bug on Crespo where the screen would come back on if a soft key was held at the time of power off because the resulting key up event would sneak in just before the keyguard was shown. It would then be passed through to the dispatcher which would poke user activity and wake up the screen. - We propagate the key flags when broadcasting media keys which ensures that recipients can tell when the key is canceled. - We ignore endcall or power if canceled (shouldn't happen anyways). Changed the input dispatcher to not poke user activity for canceled events since they are synthetic and should not wake the device. Changed the lock screen so that it does not poke the wake lock when the grab handle is released. This fixes a bug where the screen would come back on immediately if the power went off while the user was holding one of the grab handles because the sliding tab would receive an up event after screen turned off and release the grab handles. Fixed a couple of issues where media keys were being handled inconsistently or not at all, particularly in the case of the new PAUSE, PLAY and RECORD keys. Bug: 3144874 Change-Id: Ie630f5fb6f128cfdf94845f9428067045f42892c
2010-10-29 21:50:21 -07:00
break;
}
case EventEntry::TYPE_KEY: {
const KeyEntry* keyEntry = static_cast<const KeyEntry*>(eventEntry);
if (keyEntry->flags & AKEY_EVENT_FLAG_CANCELED) {
return;
}
Wake screen from external HID peripherals. Added some plumbing to enable the policy to intercept motion events when the screen is off to handle wakeup if needed. Added a basic concept of an external device to limit the scope of the wakeup policy to external devices only. The wakeup policy for internal devices should be based on explicit rules such as policy flags in key layout files. Moved isTouchEvent to native. Ensure the dispatcher sends the right event type to userActivity for non-touch pointer events like HOVER_MOVE and SCROLL. Bug: 3193114 Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
2011-03-02 19:23:13 -08:00
eventType = POWER_MANAGER_BUTTON_EVENT;
Fix policy issues when screen is off. Rewrote interceptKeyBeforeQueueing to make the handling more systematic. Behavior should be identical except: - We never pass keys to applications when the screen is off and the keyguard is not showing (the proximity sensor turned off the screen). Previously we passed all non-wake keys through in this case which caused a bug on Crespo where the screen would come back on if a soft key was held at the time of power off because the resulting key up event would sneak in just before the keyguard was shown. It would then be passed through to the dispatcher which would poke user activity and wake up the screen. - We propagate the key flags when broadcasting media keys which ensures that recipients can tell when the key is canceled. - We ignore endcall or power if canceled (shouldn't happen anyways). Changed the input dispatcher to not poke user activity for canceled events since they are synthetic and should not wake the device. Changed the lock screen so that it does not poke the wake lock when the grab handle is released. This fixes a bug where the screen would come back on immediately if the power went off while the user was holding one of the grab handles because the sliding tab would receive an up event after screen turned off and release the grab handles. Fixed a couple of issues where media keys were being handled inconsistently or not at all, particularly in the case of the new PAUSE, PLAY and RECORD keys. Bug: 3144874 Change-Id: Ie630f5fb6f128cfdf94845f9428067045f42892c
2010-10-29 21:50:21 -07:00
break;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
CommandEntry* commandEntry = postCommandLocked(
& InputDispatcher::doPokeUserActivityLockedInterruptible);
Fix bug where home presses were not poking user activity. We now poke user activity twice: once upon dequeueing an event for dispatch and then again just before we dispatch it. The second poke is to compensate for the fact that it can take a few seconds to identify the dispatch target (if the application is responding slowly) but we want to keep the display from going to sleep for X amount of time after the app gets a chance to actually receive the event. This mirrors pre-Gingerbread behavior. Removed some unnecessary code that filters user activity pokes when sending events to KeyGuard. We don't need this because KeyGuard already tells the power manager to disable user activity. Bug: 3101397 Change-Id: I8c3a77601fdef8f584e84cfdd11aa79da0ff51db
2010-10-18 13:21:23 -07:00
commandEntry->eventTime = eventEntry->eventTime;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
commandEntry->userActivityEventType = eventType;
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
2010-04-22 18:58:52 -07:00
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
void InputDispatcher::prepareDispatchCycleLocked(nsecs_t currentTime,
const sp<Connection>& connection, EventEntry* eventEntry, const InputTarget* inputTarget,
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
2010-04-22 18:58:52 -07:00
bool resumeWithAppendedMotionSample) {
#if DEBUG_DISPATCH_CYCLE
Clean up InputDispatcher debugging. Change-Id: I020e834bfb541a1f274e26a72705f96f4307dddf
2011-08-23 18:35:04 -07:00
LOGD("channel '%s' ~ prepareDispatchCycle - flags=0x%08x, "
"xOffset=%f, yOffset=%f, scaleFactor=%f, "
Add initial support for cursor-based pointing devices. Some parts stubbed out but you can plug in a mouse and move a green cursor around to interact with the UI. Change-Id: I80d597a7f11d3bd92041890f74b3c77326975e6e
2010-12-23 17:50:18 -08:00
"pointerIds=0x%x, "
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
"resumeWithAppendedMotionSample=%s",
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
connection->getInputChannelName(), inputTarget->flags,
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
2010-04-22 18:58:52 -07:00
inputTarget->xOffset, inputTarget->yOffset,
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
inputTarget->scaleFactor, inputTarget->pointerIds.value,
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
toString(resumeWithAppendedMotionSample));
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
2010-04-22 18:58:52 -07:00
#endif
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Make sure we are never called for streaming when splitting across multiple windows.
bool isSplit = inputTarget->flags & InputTarget::FLAG_SPLIT;
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(! (resumeWithAppendedMotionSample && isSplit));
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
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
2010-04-22 18:58:52 -07:00
// Skip this event if the connection status is not normal.
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
// We don't want to enqueue additional outbound events if the connection is broken.
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
2010-04-22 18:58:52 -07:00
if (connection->status != Connection::STATUS_NORMAL) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#if DEBUG_DISPATCH_CYCLE
LOGD("channel '%s' ~ Dropping event because the channel status is %s",
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
connection->getInputChannelName(), connection->getStatusLabel());
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
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
2010-04-22 18:58:52 -07:00
return;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// Split a motion event if needed.
if (isSplit) {
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(eventEntry->type == EventEntry::TYPE_MOTION);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
MotionEntry* originalMotionEntry = static_cast<MotionEntry*>(eventEntry);
if (inputTarget->pointerIds.count() != originalMotionEntry->pointerCount) {
MotionEntry* splitMotionEntry = splitMotionEvent(
originalMotionEntry, inputTarget->pointerIds);
Fix crashes caused by some input devices. The touch screen sometimes reports more than 10 pointers even though that's all we asked for. When this happens, we start dropping events with more than 10 pointers. This confuses applications and causes them to crash. Raised the limit to 16 pointers. Bug: 3331247 The default behavior was to identify all touch devices as touch screens. External devices that are plugged in are more likely to be touch pads not attached to a screen. Changed the default to be a touch pad and renamed some internal constants to avoid confusion. A certain mouse happens to also behave like a touch pad. That caused problems because we would see multiple concurrent traces of motion events coming from the same input device so we would batch them up. Added code to ensure that we don't batch events unless they come from the same *source* in addition to coming from the same *device*. Due to batching or misbehaving drivers, it's possible for the set of pointer ids to be different from what we expect when it comes time to split motion events across windows. As a result, we can generate motion events with 0 pointers. When we try to deliver those events, we cause an error in the InputTransport so we tear down the InputChannel and kill the application. Added code to check out assumption about pointer ids and drop the event gracefully instead. Patched up the tests to take into account the change in default behavior for identifying touch screens and touch pads. Change-Id: Ic364bd4cb4cc6335d4a1213a26d6bdadc7e33505
2011-01-25 16:02:22 -08:00
if (!splitMotionEntry) {
return; // split event was dropped
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
#if DEBUG_FOCUS
LOGD("channel '%s' ~ Split motion event.",
connection->getInputChannelName());
logOutboundMotionDetailsLocked(" ", splitMotionEntry);
#endif
eventEntry = splitMotionEntry;
}
}
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
2010-04-22 18:58:52 -07:00
// Resume the dispatch cycle with a freshly appended motion sample.
// First we check that the last dispatch entry in the outbound queue is for the same
// motion event to which we appended the motion sample. If we find such a dispatch
// entry, and if it is currently in progress then we try to stream the new sample.
bool wasEmpty = connection->outboundQueue.isEmpty();
if (! wasEmpty && resumeWithAppendedMotionSample) {
DispatchEntry* motionEventDispatchEntry =
connection->findQueuedDispatchEntryForEvent(eventEntry);
if (motionEventDispatchEntry) {
// If the dispatch entry is not in progress, then we must be busy dispatching an
// earlier event. Not a problem, the motion event is on the outbound queue and will
// be dispatched later.
if (! motionEventDispatchEntry->inProgress) {
#if DEBUG_BATCHING
LOGD("channel '%s' ~ Not streaming because the motion event has "
"not yet been dispatched. "
"(Waiting for earlier events to be consumed.)",
connection->getInputChannelName());
#endif
return;
}
// If the dispatch entry is in progress but it already has a tail of pending
// motion samples, then it must mean that the shared memory buffer filled up.
// Not a problem, when this dispatch cycle is finished, we will eventually start
// a new dispatch cycle to process the tail and that tail includes the newly
// appended motion sample.
if (motionEventDispatchEntry->tailMotionSample) {
#if DEBUG_BATCHING
LOGD("channel '%s' ~ Not streaming because no new samples can "
"be appended to the motion event in this dispatch cycle. "
"(Waiting for next dispatch cycle to start.)",
connection->getInputChannelName());
#endif
return;
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
// If the motion event was modified in flight, then we cannot stream the sample.
if ((motionEventDispatchEntry->targetFlags & InputTarget::FLAG_DISPATCH_MASK)
!= InputTarget::FLAG_DISPATCH_AS_IS) {
#if DEBUG_BATCHING
LOGD("channel '%s' ~ Not streaming because the motion event was not "
"being dispatched as-is. "
"(Waiting for next dispatch cycle to start.)",
connection->getInputChannelName());
#endif
return;
}
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
2010-04-22 18:58:52 -07:00
// The dispatch entry is in progress and is still potentially open for streaming.
// Try to stream the new motion sample. This might fail if the consumer has already
// consumed the motion event (or if the channel is broken).
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
MotionEntry* motionEntry = static_cast<MotionEntry*>(eventEntry);
MotionSample* appendedMotionSample = motionEntry->lastSample;
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
status_t status;
if (motionEventDispatchEntry->scaleFactor == 1.0f) {
status = connection->inputPublisher.appendMotionSample(
appendedMotionSample->eventTime, appendedMotionSample->pointerCoords);
} else {
PointerCoords scaledCoords[MAX_POINTERS];
for (size_t i = 0; i < motionEntry->pointerCount; i++) {
scaledCoords[i] = appendedMotionSample->pointerCoords[i];
scaledCoords[i].scale(motionEventDispatchEntry->scaleFactor);
}
status = connection->inputPublisher.appendMotionSample(
appendedMotionSample->eventTime, scaledCoords);
}
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
2010-04-22 18:58:52 -07:00
if (status == OK) {
#if DEBUG_BATCHING
LOGD("channel '%s' ~ Successfully streamed new motion sample.",
connection->getInputChannelName());
#endif
return;
}
#if DEBUG_BATCHING
if (status == NO_MEMORY) {
LOGD("channel '%s' ~ Could not append motion sample to currently "
"dispatched move event because the shared memory buffer is full. "
"(Waiting for next dispatch cycle to start.)",
connection->getInputChannelName());
} else if (status == status_t(FAILED_TRANSACTION)) {
LOGD("channel '%s' ~ Could not append motion sample to currently "
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
2010-06-22 01:27:15 -07:00
"dispatched move event because the event has already been consumed. "
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
2010-04-22 18:58:52 -07:00
"(Waiting for next dispatch cycle to start.)",
connection->getInputChannelName());
} else {
LOGD("channel '%s' ~ Could not append motion sample to currently "
"dispatched move event due to an error, status=%d. "
"(Waiting for next dispatch cycle to start.)",
connection->getInputChannelName(), status);
}
#endif
// Failed to stream. Start a new tail of pending motion samples to dispatch
// in the next cycle.
motionEventDispatchEntry->tailMotionSample = appendedMotionSample;
return;
}
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Enqueue dispatch entries for the requested modes.
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
resumeWithAppendedMotionSample, InputTarget::FLAG_DISPATCH_AS_HOVER_EXIT);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
resumeWithAppendedMotionSample, InputTarget::FLAG_DISPATCH_AS_OUTSIDE);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
resumeWithAppendedMotionSample, InputTarget::FLAG_DISPATCH_AS_HOVER_ENTER);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
resumeWithAppendedMotionSample, InputTarget::FLAG_DISPATCH_AS_IS);
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
resumeWithAppendedMotionSample, InputTarget::FLAG_DISPATCH_AS_SLIPPERY_EXIT);
enqueueDispatchEntryLocked(connection, eventEntry, inputTarget,
resumeWithAppendedMotionSample, InputTarget::FLAG_DISPATCH_AS_SLIPPERY_ENTER);
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// If the outbound queue was previously empty, start the dispatch cycle going.
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
if (wasEmpty && !connection->outboundQueue.isEmpty()) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
activateConnectionLocked(connection.get());
startDispatchCycleLocked(currentTime, connection);
}
}
void InputDispatcher::enqueueDispatchEntryLocked(
const sp<Connection>& connection, EventEntry* eventEntry, const InputTarget* inputTarget,
bool resumeWithAppendedMotionSample, int32_t dispatchMode) {
int32_t inputTargetFlags = inputTarget->flags;
if (!(inputTargetFlags & dispatchMode)) {
return;
}
inputTargetFlags = (inputTargetFlags & ~InputTarget::FLAG_DISPATCH_MASK) | dispatchMode;
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
2010-04-22 18:58:52 -07:00
// This is a new event.
// Enqueue a new dispatch entry onto the outbound queue for this connection.
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
DispatchEntry* dispatchEntry = new DispatchEntry(eventEntry, // increments ref
resolved conflicts for merge of 05be6d6f to master Change-Id: Ic6a6c5bb300f6f1d43f9ed550b284282b4f16212
2011-05-09 19:00:59 -07:00
inputTargetFlags, inputTarget->xOffset, inputTarget->yOffset,
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
inputTarget->scaleFactor);
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
if (dispatchEntry->hasForegroundTarget()) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
incrementPendingForegroundDispatchesLocked(eventEntry);
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
}
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
2010-04-22 18:58:52 -07:00
// Handle the case where we could not stream a new motion sample because the consumer has
// already consumed the motion event (otherwise the corresponding dispatch entry would
// still be in the outbound queue for this connection). We set the head motion sample
// to the list starting with the newly appended motion sample.
if (resumeWithAppendedMotionSample) {
#if DEBUG_BATCHING
LOGD("channel '%s' ~ Preparing a new dispatch cycle for additional motion samples "
"that cannot be streamed because the motion event has already been consumed.",
connection->getInputChannelName());
#endif
MotionSample* appendedMotionSample = static_cast<MotionEntry*>(eventEntry)->lastSample;
dispatchEntry->headMotionSample = appendedMotionSample;
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
// Apply target flags and update the connection's input state.
switch (eventEntry->type) {
case EventEntry::TYPE_KEY: {
KeyEntry* keyEntry = static_cast<KeyEntry*>(eventEntry);
dispatchEntry->resolvedAction = keyEntry->action;
dispatchEntry->resolvedFlags = keyEntry->flags;
if (!connection->inputState.trackKey(keyEntry,
dispatchEntry->resolvedAction, dispatchEntry->resolvedFlags)) {
#if DEBUG_DISPATCH_CYCLE
LOGD("channel '%s' ~ enqueueDispatchEntryLocked: skipping inconsistent key event",
connection->getInputChannelName());
#endif
return; // skip the inconsistent event
}
break;
}
case EventEntry::TYPE_MOTION: {
MotionEntry* motionEntry = static_cast<MotionEntry*>(eventEntry);
if (dispatchMode & InputTarget::FLAG_DISPATCH_AS_OUTSIDE) {
dispatchEntry->resolvedAction = AMOTION_EVENT_ACTION_OUTSIDE;
} else if (dispatchMode & InputTarget::FLAG_DISPATCH_AS_HOVER_EXIT) {
dispatchEntry->resolvedAction = AMOTION_EVENT_ACTION_HOVER_EXIT;
} else if (dispatchMode & InputTarget::FLAG_DISPATCH_AS_HOVER_ENTER) {
dispatchEntry->resolvedAction = AMOTION_EVENT_ACTION_HOVER_ENTER;
} else if (dispatchMode & InputTarget::FLAG_DISPATCH_AS_SLIPPERY_EXIT) {
dispatchEntry->resolvedAction = AMOTION_EVENT_ACTION_CANCEL;
} else if (dispatchMode & InputTarget::FLAG_DISPATCH_AS_SLIPPERY_ENTER) {
dispatchEntry->resolvedAction = AMOTION_EVENT_ACTION_DOWN;
} else {
dispatchEntry->resolvedAction = motionEntry->action;
}
if (dispatchEntry->resolvedAction == AMOTION_EVENT_ACTION_HOVER_MOVE
&& !connection->inputState.isHovering(
motionEntry->deviceId, motionEntry->source)) {
#if DEBUG_DISPATCH_CYCLE
LOGD("channel '%s' ~ enqueueDispatchEntryLocked: filling in missing hover enter event",
connection->getInputChannelName());
#endif
dispatchEntry->resolvedAction = AMOTION_EVENT_ACTION_HOVER_ENTER;
}
dispatchEntry->resolvedFlags = motionEntry->flags;
if (dispatchEntry->targetFlags & InputTarget::FLAG_WINDOW_IS_OBSCURED) {
dispatchEntry->resolvedFlags |= AMOTION_EVENT_FLAG_WINDOW_IS_OBSCURED;
}
if (!connection->inputState.trackMotion(motionEntry,
dispatchEntry->resolvedAction, dispatchEntry->resolvedFlags)) {
#if DEBUG_DISPATCH_CYCLE
LOGD("channel '%s' ~ enqueueDispatchEntryLocked: skipping inconsistent motion event",
connection->getInputChannelName());
#endif
return; // skip the inconsistent event
}
break;
}
}
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
2010-04-22 18:58:52 -07:00
// Enqueue the dispatch entry.
connection->outboundQueue.enqueueAtTail(dispatchEntry);
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
void InputDispatcher::startDispatchCycleLocked(nsecs_t currentTime,
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
const sp<Connection>& connection) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_DISPATCH_CYCLE
LOGD("channel '%s' ~ startDispatchCycle",
connection->getInputChannelName());
#endif
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(connection->status == Connection::STATUS_NORMAL);
LOG_ASSERT(! connection->outboundQueue.isEmpty());
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
2010-04-22 18:58:52 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
DispatchEntry* dispatchEntry = connection->outboundQueue.head;
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(! dispatchEntry->inProgress);
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Mark the dispatch entry as in progress.
dispatchEntry->inProgress = true;
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
2010-04-22 18:58:52 -07:00
// Publish the event.
status_t status;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
EventEntry* eventEntry = dispatchEntry->eventEntry;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
switch (eventEntry->type) {
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
2010-04-22 18:58:52 -07:00
case EventEntry::TYPE_KEY: {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
KeyEntry* keyEntry = static_cast<KeyEntry*>(eventEntry);
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
2010-04-22 18:58:52 -07:00
// Publish the key event.
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
status = connection->inputPublisher.publishKeyEvent(
keyEntry->deviceId, keyEntry->source,
dispatchEntry->resolvedAction, dispatchEntry->resolvedFlags,
keyEntry->keyCode, keyEntry->scanCode,
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
2010-04-22 18:58:52 -07:00
keyEntry->metaState, keyEntry->repeatCount, keyEntry->downTime,
keyEntry->eventTime);
if (status) {
LOGE("channel '%s' ~ Could not publish key event, "
"status=%d", connection->getInputChannelName(), status);
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
2011-08-30 20:34:48 -07:00
abortBrokenDispatchCycleLocked(currentTime, connection, true /*notify*/);
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
2010-04-22 18:58:52 -07:00
return;
}
break;
}
case EventEntry::TYPE_MOTION: {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
MotionEntry* motionEntry = static_cast<MotionEntry*>(eventEntry);
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
2010-04-22 18:58:52 -07:00
// If headMotionSample is non-NULL, then it points to the first new sample that we
// were unable to dispatch during the previous cycle so we resume dispatching from
// that point in the list of motion samples.
// Otherwise, we just start from the first sample of the motion event.
MotionSample* firstMotionSample = dispatchEntry->headMotionSample;
if (! firstMotionSample) {
firstMotionSample = & motionEntry->firstSample;
}
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
PointerCoords scaledCoords[MAX_POINTERS];
const PointerCoords* usingCoords = firstMotionSample->pointerCoords;
Fix trackball down and movement bugs. Bug: 2823788 Change-Id: Icb0c392b58f7e735614460b5eb87439cb73ac4f2
2010-07-16 17:21:06 -07:00
// Set the X and Y offset depending on the input source.
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
float xOffset, yOffset, scaleFactor;
No position information for outside touches When a window registers to listen for outside touches, it doesn't need the position information for touches that land outside of its activity for normal use cases. This patch uses the foreground window's UID as a filter to determine whether to pass the position information. This will allow applications to continue to rely on touch information for inputs that were directed at one of its other windows. Bug: 4541250 Change-Id: If16eb1ec8404b797d991859eef55ac0a20a355a3
2011-06-02 15:16:05 -07:00
if (motionEntry->source & AINPUT_SOURCE_CLASS_POINTER
&& !(dispatchEntry->targetFlags & InputTarget::FLAG_ZERO_COORDS)) {
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
scaleFactor = dispatchEntry->scaleFactor;
xOffset = dispatchEntry->xOffset * scaleFactor;
yOffset = dispatchEntry->yOffset * scaleFactor;
if (scaleFactor != 1.0f) {
for (size_t i = 0; i < motionEntry->pointerCount; i++) {
scaledCoords[i] = firstMotionSample->pointerCoords[i];
scaledCoords[i].scale(scaleFactor);
}
usingCoords = scaledCoords;
}
Fix trackball down and movement bugs. Bug: 2823788 Change-Id: Icb0c392b58f7e735614460b5eb87439cb73ac4f2
2010-07-16 17:21:06 -07:00
} else {
xOffset = 0.0f;
yOffset = 0.0f;
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
scaleFactor = 1.0f;
No position information for outside touches When a window registers to listen for outside touches, it doesn't need the position information for touches that land outside of its activity for normal use cases. This patch uses the foreground window's UID as a filter to determine whether to pass the position information. This will allow applications to continue to rely on touch information for inputs that were directed at one of its other windows. Bug: 4541250 Change-Id: If16eb1ec8404b797d991859eef55ac0a20a355a3
2011-06-02 15:16:05 -07:00
// We don't want the dispatch target to know.
if (dispatchEntry->targetFlags & InputTarget::FLAG_ZERO_COORDS) {
for (size_t i = 0; i < motionEntry->pointerCount; i++) {
scaledCoords[i].clear();
}
usingCoords = scaledCoords;
}
Fix trackball down and movement bugs. Bug: 2823788 Change-Id: Icb0c392b58f7e735614460b5eb87439cb73ac4f2
2010-07-16 17:21:06 -07:00
}
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
2010-04-22 18:58:52 -07:00
// Publish the motion event and the first motion sample.
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
status = connection->inputPublisher.publishMotionEvent(
motionEntry->deviceId, motionEntry->source,
dispatchEntry->resolvedAction, dispatchEntry->resolvedFlags,
motionEntry->edgeFlags, motionEntry->metaState, motionEntry->buttonState,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
xOffset, yOffset,
motionEntry->xPrecision, motionEntry->yPrecision,
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
2010-04-22 18:58:52 -07:00
motionEntry->downTime, firstMotionSample->eventTime,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
motionEntry->pointerCount, motionEntry->pointerProperties,
usingCoords);
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
2010-04-22 18:58:52 -07:00
if (status) {
LOGE("channel '%s' ~ Could not publish motion event, "
"status=%d", connection->getInputChannelName(), status);
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
2011-08-30 20:34:48 -07:00
abortBrokenDispatchCycleLocked(currentTime, connection, true /*notify*/);
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
2010-04-22 18:58:52 -07:00
return;
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
if (dispatchEntry->resolvedAction == AMOTION_EVENT_ACTION_MOVE
|| dispatchEntry->resolvedAction == AMOTION_EVENT_ACTION_HOVER_MOVE) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Append additional motion samples.
MotionSample* nextMotionSample = firstMotionSample->next;
for (; nextMotionSample != NULL; nextMotionSample = nextMotionSample->next) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
if (usingCoords == scaledCoords) {
No position information for outside touches When a window registers to listen for outside touches, it doesn't need the position information for touches that land outside of its activity for normal use cases. This patch uses the foreground window's UID as a filter to determine whether to pass the position information. This will allow applications to continue to rely on touch information for inputs that were directed at one of its other windows. Bug: 4541250 Change-Id: If16eb1ec8404b797d991859eef55ac0a20a355a3
2011-06-02 15:16:05 -07:00
if (!(dispatchEntry->targetFlags & InputTarget::FLAG_ZERO_COORDS)) {
for (size_t i = 0; i < motionEntry->pointerCount; i++) {
scaledCoords[i] = nextMotionSample->pointerCoords[i];
scaledCoords[i].scale(scaleFactor);
}
resolved conflicts for merge of 037b54cf to master Change-Id: I1bc2827596a349963d8aa2b63b3f7801f155668a
2011-05-11 10:59:54 -07:00
}
} else {
usingCoords = nextMotionSample->pointerCoords;
Fix scaling of batched motion events. Change-Id: I1e070c936f7b2e8f1bb7ebae62b1df0aa6998b82
2011-05-09 21:19:26 -07:00
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
status = connection->inputPublisher.appendMotionSample(
resolved conflicts for merge of 05be6d6f to master Change-Id: Ic6a6c5bb300f6f1d43f9ed550b284282b4f16212
2011-05-09 19:00:59 -07:00
nextMotionSample->eventTime, usingCoords);
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
if (status == NO_MEMORY) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_DISPATCH_CYCLE
LOGD("channel '%s' ~ Shared memory buffer full. Some motion samples will "
"be sent in the next dispatch cycle.",
connection->getInputChannelName());
#endif
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
break;
}
if (status != OK) {
LOGE("channel '%s' ~ Could not append motion sample "
"for a reason other than out of memory, status=%d",
connection->getInputChannelName(), status);
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
2011-08-30 20:34:48 -07:00
abortBrokenDispatchCycleLocked(currentTime, connection, true /*notify*/);
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
return;
}
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
2010-04-22 18:58:52 -07:00
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
// Remember the next motion sample that we could not dispatch, in case we ran out
// of space in the shared memory buffer.
dispatchEntry->tailMotionSample = nextMotionSample;
}
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
2010-04-22 18:58:52 -07:00
break;
}
default: {
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(false);
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
2010-04-22 18:58:52 -07:00
}
}
// Send the dispatch signal.
status = connection->inputPublisher.sendDispatchSignal();
if (status) {
LOGE("channel '%s' ~ Could not send dispatch signal, status=%d",
connection->getInputChannelName(), status);
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
2011-08-30 20:34:48 -07:00
abortBrokenDispatchCycleLocked(currentTime, connection, true /*notify*/);
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
2010-04-22 18:58:52 -07:00
return;
}
// Record information about the newly started dispatch cycle.
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
connection->lastEventTime = eventEntry->eventTime;
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
2010-04-22 18:58:52 -07:00
connection->lastDispatchTime = currentTime;
// Notify other system components.
onDispatchCycleStartedLocked(currentTime, connection);
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
void InputDispatcher::finishDispatchCycleLocked(nsecs_t currentTime,
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
2010-11-05 15:02:16 -07:00
const sp<Connection>& connection, bool handled) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_DISPATCH_CYCLE
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
2010-06-15 01:31:58 -07:00
LOGD("channel '%s' ~ finishDispatchCycle - %01.1fms since event, "
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
2010-11-05 15:02:16 -07:00
"%01.1fms since dispatch, handled=%s",
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
2010-04-22 18:58:52 -07:00
connection->getInputChannelName(),
connection->getEventLatencyMillis(currentTime),
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
2010-11-05 15:02:16 -07:00
connection->getDispatchLatencyMillis(currentTime),
toString(handled));
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
2010-04-22 18:58:52 -07:00
#endif
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
2010-06-15 01:31:58 -07:00
if (connection->status == Connection::STATUS_BROKEN
|| connection->status == Connection::STATUS_ZOMBIE) {
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
2010-04-22 18:58:52 -07:00
return;
}
// Reset the publisher since the event has been consumed.
// We do this now so that the publisher can release some of its internal resources
// while waiting for the next dispatch cycle to begin.
status_t status = connection->inputPublisher.reset();
if (status) {
LOGE("channel '%s' ~ Could not reset publisher, status=%d",
connection->getInputChannelName(), status);
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
2011-08-30 20:34:48 -07:00
abortBrokenDispatchCycleLocked(currentTime, connection, true /*notify*/);
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
2010-04-22 18:58:52 -07:00
return;
}
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
2010-11-05 15:02:16 -07:00
// Notify other system components and prepare to start the next dispatch cycle.
onDispatchCycleFinishedLocked(currentTime, connection, handled);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
void InputDispatcher::startNextDispatchCycleLocked(nsecs_t currentTime,
const sp<Connection>& connection) {
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
2010-04-22 18:58:52 -07:00
// Start the next dispatch cycle for this connection.
while (! connection->outboundQueue.isEmpty()) {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
DispatchEntry* dispatchEntry = connection->outboundQueue.head;
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
2010-04-22 18:58:52 -07:00
if (dispatchEntry->inProgress) {
// Finish or resume current event in progress.
if (dispatchEntry->tailMotionSample) {
// We have a tail of undispatched motion samples.
// Reuse the same DispatchEntry and start a new cycle.
dispatchEntry->inProgress = false;
dispatchEntry->headMotionSample = dispatchEntry->tailMotionSample;
dispatchEntry->tailMotionSample = NULL;
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
startDispatchCycleLocked(currentTime, connection);
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
2010-04-22 18:58:52 -07:00
return;
}
// Finished.
connection->outboundQueue.dequeueAtHead();
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
if (dispatchEntry->hasForegroundTarget()) {
decrementPendingForegroundDispatchesLocked(dispatchEntry->eventEntry);
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
delete dispatchEntry;
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
2010-04-22 18:58:52 -07:00
} else {
// If the head is not in progress, then we must have already dequeued the in
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
// progress event, which means we actually aborted it.
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
2010-04-22 18:58:52 -07:00
// So just start the next event for this connection.
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
startDispatchCycleLocked(currentTime, connection);
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
2010-04-22 18:58:52 -07:00
return;
}
}
// Outbound queue is empty, deactivate the connection.
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
deactivateConnectionLocked(connection.get());
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
2010-04-22 18:58:52 -07:00
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
void InputDispatcher::abortBrokenDispatchCycleLocked(nsecs_t currentTime,
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
2011-08-30 20:34:48 -07:00
const sp<Connection>& connection, bool notify) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_DISPATCH_CYCLE
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
2011-08-30 20:34:48 -07:00
LOGD("channel '%s' ~ abortBrokenDispatchCycle - notify=%s",
connection->getInputChannelName(), toString(notify));
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
2010-04-22 18:58:52 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// Clear the outbound queue.
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
drainOutboundQueueLocked(connection.get());
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
2010-04-22 18:58:52 -07:00
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
// The connection appears to be unrecoverably broken.
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
2010-06-15 01:31:58 -07:00
// Ignore already broken or zombie connections.
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
if (connection->status == Connection::STATUS_NORMAL) {
connection->status = Connection::STATUS_BROKEN;
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
2010-04-22 18:58:52 -07:00
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
2011-08-30 20:34:48 -07:00
if (notify) {
// Notify other system components.
onDispatchCycleBrokenLocked(currentTime, connection);
}
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
2010-04-22 18:58:52 -07:00
}
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
void InputDispatcher::drainOutboundQueueLocked(Connection* connection) {
while (! connection->outboundQueue.isEmpty()) {
DispatchEntry* dispatchEntry = connection->outboundQueue.dequeueAtHead();
if (dispatchEntry->hasForegroundTarget()) {
decrementPendingForegroundDispatchesLocked(dispatchEntry->eventEntry);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
delete dispatchEntry;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
deactivateConnectionLocked(connection);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-09-13 23:17:30 -07:00
int InputDispatcher::handleReceiveCallback(int receiveFd, int events, void* data) {
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
2010-04-22 18:58:52 -07:00
InputDispatcher* d = static_cast<InputDispatcher*>(data);
{ // acquire lock
AutoMutex _l(d->mLock);
ssize_t connectionIndex = d->mConnectionsByReceiveFd.indexOfKey(receiveFd);
if (connectionIndex < 0) {
LOGE("Received spurious receive callback for unknown input channel. "
"fd=%d, events=0x%x", receiveFd, events);
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
2010-09-13 23:17:30 -07:00
return 0; // remove the callback
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
2010-04-22 18:58:52 -07:00
}
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
2011-08-30 20:34:48 -07:00
bool notify;
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
2010-04-22 18:58:52 -07:00
sp<Connection> connection = d->mConnectionsByReceiveFd.valueAt(connectionIndex);
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
2011-08-30 20:34:48 -07:00
if (!(events & (ALOOPER_EVENT_ERROR | ALOOPER_EVENT_HANGUP))) {
if (!(events & ALOOPER_EVENT_INPUT)) {
LOGW("channel '%s' ~ Received spurious callback for unhandled poll event. "
"events=0x%x", connection->getInputChannelName(), events);
return 1;
}
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
2010-04-22 18:58:52 -07:00
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
2011-08-30 20:34:48 -07:00
bool handled = false;
status_t status = connection->inputPublisher.receiveFinishedSignal(&handled);
if (!status) {
nsecs_t currentTime = now();
d->finishDispatchCycleLocked(currentTime, connection, handled);
d->runCommandsLockedInterruptible();
return 1;
}
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
2010-04-22 18:58:52 -07:00
LOGE("channel '%s' ~ Failed to receive finished signal. status=%d",
connection->getInputChannelName(), status);
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
2011-08-30 20:34:48 -07:00
notify = true;
} else {
// Monitor channels are never explicitly unregistered.
// We do it automatically when the remote endpoint is closed so don't warn
// about them.
notify = !connection->monitor;
if (notify) {
LOGW("channel '%s' ~ Consumer closed input channel or an error occurred. "
"events=0x%x", connection->getInputChannelName(), events);
}
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
2010-04-22 18:58:52 -07:00
}
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
2011-08-30 20:34:48 -07:00
// Unregister the channel.
d->unregisterInputChannelLocked(connection->inputChannel, notify);
return 0; // remove the callback
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
2010-04-22 18:58:52 -07:00
} // release lock
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
void InputDispatcher::synthesizeCancelationEventsForAllConnectionsLocked(
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
const CancelationOptions& options) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
for (size_t i = 0; i < mConnectionsByReceiveFd.size(); i++) {
synthesizeCancelationEventsForConnectionLocked(
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
mConnectionsByReceiveFd.valueAt(i), options);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
}
void InputDispatcher::synthesizeCancelationEventsForInputChannelLocked(
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
const sp<InputChannel>& channel, const CancelationOptions& options) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
ssize_t index = getConnectionIndexLocked(channel);
if (index >= 0) {
synthesizeCancelationEventsForConnectionLocked(
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
mConnectionsByReceiveFd.valueAt(index), options);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
}
void InputDispatcher::synthesizeCancelationEventsForConnectionLocked(
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
const sp<Connection>& connection, const CancelationOptions& options) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
nsecs_t currentTime = now();
mTempCancelationEvents.clear();
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
connection->inputState.synthesizeCancelationEvents(currentTime,
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
mTempCancelationEvents, options);
if (! mTempCancelationEvents.isEmpty()
&& connection->status != Connection::STATUS_BROKEN) {
#if DEBUG_OUTBOUND_EVENT_DETAILS
LOGD("channel '%s' ~ Synthesized %d cancelation events to bring channel back in sync "
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
"with reality: %s, mode=%d.",
connection->getInputChannelName(), mTempCancelationEvents.size(),
options.reason, options.mode);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
for (size_t i = 0; i < mTempCancelationEvents.size(); i++) {
EventEntry* cancelationEventEntry = mTempCancelationEvents.itemAt(i);
switch (cancelationEventEntry->type) {
case EventEntry::TYPE_KEY:
logOutboundKeyDetailsLocked("cancel - ",
static_cast<KeyEntry*>(cancelationEventEntry));
break;
case EventEntry::TYPE_MOTION:
logOutboundMotionDetailsLocked("cancel - ",
static_cast<MotionEntry*>(cancelationEventEntry));
break;
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
InputTarget target;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> windowHandle = getWindowHandleLocked(connection->inputChannel);
if (windowHandle != NULL) {
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
2011-08-30 20:34:48 -07:00
const InputWindowInfo* windowInfo = windowHandle->getInfo();
target.xOffset = -windowInfo->frameLeft;
target.yOffset = -windowInfo->frameTop;
target.scaleFactor = windowInfo->scaleFactor;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
} else {
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
target.xOffset = 0;
target.yOffset = 0;
target.scaleFactor = 1.0f;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
target.inputChannel = connection->inputChannel;
target.flags = InputTarget::FLAG_DISPATCH_AS_IS;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
enqueueDispatchEntryLocked(connection, cancelationEventEntry, // increments ref
&target, false, InputTarget::FLAG_DISPATCH_AS_IS);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
cancelationEventEntry->release();
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
if (!connection->outboundQueue.head->inProgress) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
startDispatchCycleLocked(currentTime, connection);
}
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
InputDispatcher::MotionEntry*
InputDispatcher::splitMotionEvent(const MotionEntry* originalMotionEntry, BitSet32 pointerIds) {
Fix dispatcher crash when input monitoring enabled. Also ensure that we actually log assertion failures. Bug: 4203092 Change-Id: I5c14bc41b2255f876858121f5572e2de75cabcc3
2011-04-01 16:15:13 -07:00
LOG_ASSERT(pointerIds.value != 0);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
uint32_t splitPointerIndexMap[MAX_POINTERS];
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
PointerProperties splitPointerProperties[MAX_POINTERS];
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
PointerCoords splitPointerCoords[MAX_POINTERS];
uint32_t originalPointerCount = originalMotionEntry->pointerCount;
uint32_t splitPointerCount = 0;
for (uint32_t originalPointerIndex = 0; originalPointerIndex < originalPointerCount;
originalPointerIndex++) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
const PointerProperties& pointerProperties =
originalMotionEntry->pointerProperties[originalPointerIndex];
uint32_t pointerId = uint32_t(pointerProperties.id);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
if (pointerIds.hasBit(pointerId)) {
splitPointerIndexMap[splitPointerCount] = originalPointerIndex;
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
splitPointerProperties[splitPointerCount].copyFrom(pointerProperties);
Use touch pad gestures to manipulate the pointer. 1. Single finger tap performs a click. 2. Single finger movement moves the pointer (hovers). 3. Button press plus movement performs click or drag. While dragging, the pointer follows the finger that is moving fastest. This is important if there are additional fingers down on the touch pad for the purpose of applying force to an integrated button underneath. 4. Two fingers near each other moving in the same direction are coalesced as a swipe gesture under the pointer. 5. Two or more fingers moving in arbitrary directions are transformed into touches in the vicinity of the pointer. This makes scale/zoom and rotate gestures possible. Added a native VelocityTracker implementation to enable intelligent switching of the active pointer during drags. Change-Id: I5ada57e7f2bdb9b0a791843eb354a8c706b365dc
2011-03-09 17:39:48 -08:00
splitPointerCoords[splitPointerCount].copyFrom(
originalMotionEntry->firstSample.pointerCoords[originalPointerIndex]);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
splitPointerCount += 1;
}
}
Fix crashes caused by some input devices. The touch screen sometimes reports more than 10 pointers even though that's all we asked for. When this happens, we start dropping events with more than 10 pointers. This confuses applications and causes them to crash. Raised the limit to 16 pointers. Bug: 3331247 The default behavior was to identify all touch devices as touch screens. External devices that are plugged in are more likely to be touch pads not attached to a screen. Changed the default to be a touch pad and renamed some internal constants to avoid confusion. A certain mouse happens to also behave like a touch pad. That caused problems because we would see multiple concurrent traces of motion events coming from the same input device so we would batch them up. Added code to ensure that we don't batch events unless they come from the same *source* in addition to coming from the same *device*. Due to batching or misbehaving drivers, it's possible for the set of pointer ids to be different from what we expect when it comes time to split motion events across windows. As a result, we can generate motion events with 0 pointers. When we try to deliver those events, we cause an error in the InputTransport so we tear down the InputChannel and kill the application. Added code to check out assumption about pointer ids and drop the event gracefully instead. Patched up the tests to take into account the change in default behavior for identifying touch screens and touch pads. Change-Id: Ic364bd4cb4cc6335d4a1213a26d6bdadc7e33505
2011-01-25 16:02:22 -08:00
if (splitPointerCount != pointerIds.count()) {
// This is bad. We are missing some of the pointers that we expected to deliver.
// Most likely this indicates that we received an ACTION_MOVE events that has
// different pointer ids than we expected based on the previous ACTION_DOWN
// or ACTION_POINTER_DOWN events that caused us to decide to split the pointers
// in this way.
LOGW("Dropping split motion event because the pointer count is %d but "
"we expected there to be %d pointers. This probably means we received "
"a broken sequence of pointer ids from the input device.",
splitPointerCount, pointerIds.count());
return NULL;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t action = originalMotionEntry->action;
int32_t maskedAction = action & AMOTION_EVENT_ACTION_MASK;
if (maskedAction == AMOTION_EVENT_ACTION_POINTER_DOWN
|| maskedAction == AMOTION_EVENT_ACTION_POINTER_UP) {
int32_t originalPointerIndex = getMotionEventActionPointerIndex(action);
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
const PointerProperties& pointerProperties =
originalMotionEntry->pointerProperties[originalPointerIndex];
uint32_t pointerId = uint32_t(pointerProperties.id);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
if (pointerIds.hasBit(pointerId)) {
if (pointerIds.count() == 1) {
// The first/last pointer went down/up.
action = maskedAction == AMOTION_EVENT_ACTION_POINTER_DOWN
? AMOTION_EVENT_ACTION_DOWN : AMOTION_EVENT_ACTION_UP;
Fix pointer index when splitting secondary pointers. Change-Id: Ib01e810ea5b64501b1303000bbef0f0a1db2114e
2010-09-27 16:35:11 -07:00
} else {
// A secondary pointer went down/up.
uint32_t splitPointerIndex = 0;
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
while (pointerId != uint32_t(splitPointerProperties[splitPointerIndex].id)) {
Fix pointer index when splitting secondary pointers. Change-Id: Ib01e810ea5b64501b1303000bbef0f0a1db2114e
2010-09-27 16:35:11 -07:00
splitPointerIndex += 1;
}
action = maskedAction | (splitPointerIndex
<< AMOTION_EVENT_ACTION_POINTER_INDEX_SHIFT);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
} else {
// An unrelated pointer changed.
action = AMOTION_EVENT_ACTION_MOVE;
}
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
MotionEntry* splitMotionEntry = new MotionEntry(
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
originalMotionEntry->eventTime,
originalMotionEntry->deviceId,
originalMotionEntry->source,
originalMotionEntry->policyFlags,
action,
originalMotionEntry->flags,
originalMotionEntry->metaState,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
originalMotionEntry->buttonState,
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
originalMotionEntry->edgeFlags,
originalMotionEntry->xPrecision,
originalMotionEntry->yPrecision,
originalMotionEntry->downTime,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
splitPointerCount, splitPointerProperties, splitPointerCoords);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
for (MotionSample* originalMotionSample = originalMotionEntry->firstSample.next;
originalMotionSample != NULL; originalMotionSample = originalMotionSample->next) {
for (uint32_t splitPointerIndex = 0; splitPointerIndex < splitPointerCount;
splitPointerIndex++) {
uint32_t originalPointerIndex = splitPointerIndexMap[splitPointerIndex];
Use touch pad gestures to manipulate the pointer. 1. Single finger tap performs a click. 2. Single finger movement moves the pointer (hovers). 3. Button press plus movement performs click or drag. While dragging, the pointer follows the finger that is moving fastest. This is important if there are additional fingers down on the touch pad for the purpose of applying force to an integrated button underneath. 4. Two fingers near each other moving in the same direction are coalesced as a swipe gesture under the pointer. 5. Two or more fingers moving in arbitrary directions are transformed into touches in the vicinity of the pointer. This makes scale/zoom and rotate gestures possible. Added a native VelocityTracker implementation to enable intelligent switching of the active pointer during drags. Change-Id: I5ada57e7f2bdb9b0a791843eb354a8c706b365dc
2011-03-09 17:39:48 -08:00
splitPointerCoords[splitPointerIndex].copyFrom(
originalMotionSample->pointerCoords[originalPointerIndex]);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
splitMotionEntry->appendSample(originalMotionSample->eventTime, splitPointerCoords);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
if (originalMotionEntry->injectionState) {
splitMotionEntry->injectionState = originalMotionEntry->injectionState;
splitMotionEntry->injectionState->refCount += 1;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
return splitMotionEntry;
}
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
void InputDispatcher::notifyConfigurationChanged(const NotifyConfigurationChangedArgs* args) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_INBOUND_EVENT_DETAILS
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
LOGD("notifyConfigurationChanged - eventTime=%lld", args->eventTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
bool needWake;
{ // acquire lock
AutoMutex _l(mLock);
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
ConfigurationChangedEntry* newEntry = new ConfigurationChangedEntry(args->eventTime);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
needWake = enqueueInboundEventLocked(newEntry);
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
2010-04-22 18:58:52 -07:00
} // release lock
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (needWake) {
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
2010-09-13 23:17:30 -07:00
mLooper->wake();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-04-22 18:58:52 -07:00
}
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
void InputDispatcher::notifyKey(const NotifyKeyArgs* args) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_INBOUND_EVENT_DETAILS
Improve support for external keyboards. Use Vendor ID, Product ID and optionally the Version to locate keymaps and configuration files for external devices. Moved virtual key definition parsing to native code so that EventHub can identify touch screens with virtual keys and load the appropriate key layout file. Cleaned up a lot of old code in EventHub. Fixed a regression in ViewRoot's fallback event handling. Fixed a minor bug in FileMap that caused it to try to munmap or close invalid handled when released if the attempt to map the file failed. Added a couple of new String8 conveniences for formatting strings. Modified Tokenizer to fall back to open+read when mmap fails since we can't mmap sysfs files as needed to open the virtual key definition files in /sys/board_properties/. Change-Id: I6ca5e5f9547619fd082ddac47e87ce185da69ee6
2010-12-02 13:50:46 -08:00
LOGD("notifyKey - eventTime=%lld, deviceId=%d, source=0x%x, policyFlags=0x%x, action=0x%x, "
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
2010-04-22 18:58:52 -07:00
"flags=0x%x, keyCode=0x%x, scanCode=0x%x, metaState=0x%x, downTime=%lld",
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
args->eventTime, args->deviceId, args->source, args->policyFlags,
args->action, args->flags, args->keyCode, args->scanCode,
args->metaState, args->downTime);
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
2010-04-22 18:58:52 -07:00
#endif
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
if (!validateKeyEvent(args->action)) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
return;
}
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
2010-04-22 18:58:52 -07:00
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
uint32_t policyFlags = args->policyFlags;
int32_t flags = args->flags;
int32_t metaState = args->metaState;
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
if ((policyFlags & POLICY_FLAG_VIRTUAL) || (flags & AKEY_EVENT_FLAG_VIRTUAL_HARD_KEY)) {
policyFlags |= POLICY_FLAG_VIRTUAL;
flags |= AKEY_EVENT_FLAG_VIRTUAL_HARD_KEY;
}
Support POLICY_FLAG_ALT et. al. (DO NOT MERGE) Change-Id: Ida3b8300764623662052f80095973186cb9d4616
2011-03-07 16:40:47 -08:00
if (policyFlags & POLICY_FLAG_ALT) {
metaState |= AMETA_ALT_ON | AMETA_ALT_LEFT_ON;
}
if (policyFlags & POLICY_FLAG_ALT_GR) {
metaState |= AMETA_ALT_ON | AMETA_ALT_RIGHT_ON;
}
if (policyFlags & POLICY_FLAG_SHIFT) {
metaState |= AMETA_SHIFT_ON | AMETA_SHIFT_LEFT_ON;
}
if (policyFlags & POLICY_FLAG_CAPS_LOCK) {
metaState |= AMETA_CAPS_LOCK_ON;
}
if (policyFlags & POLICY_FLAG_FUNCTION) {
metaState |= AMETA_FUNCTION_ON;
}
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
policyFlags |= POLICY_FLAG_TRUSTED;
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
KeyEvent event;
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
event.initialize(args->deviceId, args->source, args->action,
flags, args->keyCode, args->scanCode, metaState, 0,
args->downTime, args->eventTime);
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
mPolicy->interceptKeyBeforeQueueing(&event, /*byref*/ policyFlags);
if (policyFlags & POLICY_FLAG_WOKE_HERE) {
flags |= AKEY_EVENT_FLAG_WOKE_HERE;
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
bool needWake;
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
2010-04-22 18:58:52 -07:00
{ // acquire lock
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
mLock.lock();
if (mInputFilterEnabled) {
mLock.unlock();
policyFlags |= POLICY_FLAG_FILTERED;
if (!mPolicy->filterInputEvent(&event, policyFlags)) {
return; // event was consumed by the filter
}
mLock.lock();
}
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
2010-04-22 18:58:52 -07:00
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
int32_t repeatCount = 0;
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
KeyEntry* newEntry = new KeyEntry(args->eventTime,
args->deviceId, args->source, policyFlags,
args->action, flags, args->keyCode, args->scanCode,
metaState, repeatCount, args->downTime);
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
needWake = enqueueInboundEventLocked(newEntry);
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
mLock.unlock();
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
2010-04-22 18:58:52 -07:00
} // release lock
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (needWake) {
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
2010-09-13 23:17:30 -07:00
mLooper->wake();
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
2010-04-22 18:58:52 -07:00
}
}
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
void InputDispatcher::notifyMotion(const NotifyMotionArgs* args) {
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
2010-04-22 18:58:52 -07:00
#if DEBUG_INBOUND_EVENT_DETAILS
Improve support for external keyboards. Use Vendor ID, Product ID and optionally the Version to locate keymaps and configuration files for external devices. Moved virtual key definition parsing to native code so that EventHub can identify touch screens with virtual keys and load the appropriate key layout file. Cleaned up a lot of old code in EventHub. Fixed a regression in ViewRoot's fallback event handling. Fixed a minor bug in FileMap that caused it to try to munmap or close invalid handled when released if the attempt to map the file failed. Added a couple of new String8 conveniences for formatting strings. Modified Tokenizer to fall back to open+read when mmap fails since we can't mmap sysfs files as needed to open the virtual key definition files in /sys/board_properties/. Change-Id: I6ca5e5f9547619fd082ddac47e87ce185da69ee6
2010-12-02 13:50:46 -08:00
LOGD("notifyMotion - eventTime=%lld, deviceId=%d, source=0x%x, policyFlags=0x%x, "
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
"action=0x%x, flags=0x%x, metaState=0x%x, buttonState=0x%x, edgeFlags=0x%x, "
Add support for secure views. Added the MotionEvent.FLAG_WINDOW_IS_OBSCURED flag which is set by the input manager whenever another visible window is partly or wholly obscured the target of a touch event so that applications can filter touches accordingly. Added a "filterTouchesWhenObscured" attribute to View which can be used to enable filtering of touches when the view's window is obscured. Change-Id: I936d9c85013fd2d77fb296a600528d30a29027d2
2010-09-01 17:01:00 -07:00
"xPrecision=%f, yPrecision=%f, downTime=%lld",
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
args->eventTime, args->deviceId, args->source, args->policyFlags,
args->action, args->flags, args->metaState, args->buttonState,
args->edgeFlags, args->xPrecision, args->yPrecision, args->downTime);
for (uint32_t i = 0; i < args->pointerCount; i++) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
LOGD(" Pointer %d: id=%d, toolType=%d, "
"x=%f, y=%f, pressure=%f, size=%f, "
Add support for secure views. Added the MotionEvent.FLAG_WINDOW_IS_OBSCURED flag which is set by the input manager whenever another visible window is partly or wholly obscured the target of a touch event so that applications can filter touches accordingly. Added a "filterTouchesWhenObscured" attribute to View which can be used to enable filtering of touches when the view's window is obscured. Change-Id: I936d9c85013fd2d77fb296a600528d30a29027d2
2010-09-01 17:01:00 -07:00
"touchMajor=%f, touchMinor=%f, toolMajor=%f, toolMinor=%f, "
Input device calibration and capabilities. Finished the input device capability API. Added a mechanism for calibrating touch devices to obtain more accurate information about the touch contact area. Improved pointer location to show new coordinates and capabilities. Optimized pointer location display and formatting to avoid allocating large numbers of temporary objects. The GC churn was causing the application to stutter very badly when more than a couple of fingers were down). Added more diagnostics. Change-Id: Ie25380278ed6f16c5b04cd9df848015850383498
2010-08-30 03:02:23 -07:00
"orientation=%f",
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
i, args->pointerProperties[i].id,
args->pointerProperties[i].toolType,
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_X),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_Y),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_PRESSURE),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_SIZE),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOUCH_MAJOR),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOUCH_MINOR),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOOL_MAJOR),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_TOOL_MINOR),
args->pointerCoords[i].getAxisValue(AMOTION_EVENT_AXIS_ORIENTATION));
}
#endif
if (!validateMotionEvent(args->action, args->pointerCount, args->pointerProperties)) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
return;
}
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
2010-04-22 18:58:52 -07:00
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
uint32_t policyFlags = args->policyFlags;
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
policyFlags |= POLICY_FLAG_TRUSTED;
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
mPolicy->interceptMotionBeforeQueueing(args->eventTime, /*byref*/ policyFlags);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
bool needWake;
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
2010-04-22 18:58:52 -07:00
{ // acquire lock
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
mLock.lock();
if (mInputFilterEnabled) {
mLock.unlock();
MotionEvent event;
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
event.initialize(args->deviceId, args->source, args->action, args->flags,
args->edgeFlags, args->metaState, args->buttonState, 0, 0,
args->xPrecision, args->yPrecision,
args->downTime, args->eventTime,
args->pointerCount, args->pointerProperties, args->pointerCoords);
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
policyFlags |= POLICY_FLAG_FILTERED;
if (!mPolicy->filterInputEvent(&event, policyFlags)) {
return; // event was consumed by the filter
}
mLock.lock();
}
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
2010-04-22 18:58:52 -07:00
// Attempt batching and streaming of move events.
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
if (args->action == AMOTION_EVENT_ACTION_MOVE
|| args->action == AMOTION_EVENT_ACTION_HOVER_MOVE) {
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
2010-04-22 18:58:52 -07:00
// BATCHING CASE
//
// Try to append a move sample to the tail of the inbound queue for this device.
// Give up if we encounter a non-move motion event for this device since that
// means we cannot append any new samples until a new motion event has started.
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
for (EventEntry* entry = mInboundQueue.tail; entry; entry = entry->prev) {
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
2010-04-22 18:58:52 -07:00
if (entry->type != EventEntry::TYPE_MOTION) {
// Keep looking for motion events.
continue;
}
MotionEntry* motionEntry = static_cast<MotionEntry*>(entry);
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
if (motionEntry->deviceId != args->deviceId
|| motionEntry->source != args->source) {
Input improvements and bug fixes. Associate each motion axis with the source from which it comes. It is possible for multiple sources of the same device to define the same axis. This fixes new API that was introduced in MR1. (Bug: 4066146) Fixed a bug that might cause a segfault when using a trackball. Only fade out the mouse pointer when touching the touch screen, ignore other touch pads. Changed the plural "sources" to "source" in several places in the InputReader where we intend to refer to a particular source rather than to a combination of sources. Improved the batching code to support batching events from different sources of the same device in parallel. (Bug: 3391564) Change-Id: I0189e18e464338f126f7bf94370b928e1b1695f2
2011-03-08 15:13:06 -08:00
// Keep looking for this device and source.
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
2010-04-22 18:58:52 -07:00
continue;
}
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
if (!motionEntry->canAppendSamples(args->action,
args->pointerCount, args->pointerProperties)) {
Input improvements and bug fixes. Associate each motion axis with the source from which it comes. It is possible for multiple sources of the same device to define the same axis. This fixes new API that was introduced in MR1. (Bug: 4066146) Fixed a bug that might cause a segfault when using a trackball. Only fade out the mouse pointer when touching the touch screen, ignore other touch pads. Changed the plural "sources" to "source" in several places in the InputReader where we intend to refer to a particular source rather than to a combination of sources. Improved the batching code to support batching events from different sources of the same device in parallel. (Bug: 3391564) Change-Id: I0189e18e464338f126f7bf94370b928e1b1695f2
2011-03-08 15:13:06 -08:00
// Last motion event in the queue for this device and source is
// not compatible for appending new samples. Stop here.
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
2010-04-22 18:58:52 -07:00
goto NoBatchingOrStreaming;
}
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
2010-06-15 01:31:58 -07:00
// Do the batching magic.
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
batchMotionLocked(motionEntry, args->eventTime,
args->metaState, args->pointerCoords,
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
"most recent motion event for this device and source in the inbound queue");
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
mLock.unlock();
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
2010-06-15 01:31:58 -07:00
return; // done!
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
2010-04-22 18:58:52 -07:00
}
Allow batching samples onto the pending motion event. This enlarges the window of opportunity for batching to encompass time spent for the window to become ready (while it is busy processing the last event). Change-Id: I3fb5a394ab1b85d6591192678168ca6e35dd9d53
2011-04-06 17:19:48 -07:00
// BATCHING ONTO PENDING EVENT CASE
//
// Try to append a move sample to the currently pending event, if there is one.
// We can do this as long as we are still waiting to find the targets for the
// event. Once the targets are locked-in we can only do streaming.
if (mPendingEvent
&& (!mPendingEvent->dispatchInProgress || !mCurrentInputTargetsValid)
&& mPendingEvent->type == EventEntry::TYPE_MOTION) {
MotionEntry* motionEntry = static_cast<MotionEntry*>(mPendingEvent);
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
if (motionEntry->deviceId == args->deviceId
&& motionEntry->source == args->source) {
if (!motionEntry->canAppendSamples(args->action,
args->pointerCount, args->pointerProperties)) {
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
// Pending motion event is for this device and source but it is
// not compatible for appending new samples. Stop here.
Allow batching samples onto the pending motion event. This enlarges the window of opportunity for batching to encompass time spent for the window to become ready (while it is busy processing the last event). Change-Id: I3fb5a394ab1b85d6591192678168ca6e35dd9d53
2011-04-06 17:19:48 -07:00
goto NoBatchingOrStreaming;
}
// Do the batching magic.
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
batchMotionLocked(motionEntry, args->eventTime,
args->metaState, args->pointerCoords,
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
"pending motion event");
Allow batching samples onto the pending motion event. This enlarges the window of opportunity for batching to encompass time spent for the window to become ready (while it is busy processing the last event). Change-Id: I3fb5a394ab1b85d6591192678168ca6e35dd9d53
2011-04-06 17:19:48 -07:00
mLock.unlock();
return; // done!
}
}
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
2010-04-22 18:58:52 -07:00
// STREAMING CASE
//
// There is no pending motion event (of any kind) for this device in the inbound queue.
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
// Search the outbound queue for the current foreground targets to find a dispatched
// motion event that is still in progress. If found, then, appen the new sample to
// that event and push it out to all current targets. The logic in
// prepareDispatchCycleLocked takes care of the case where some targets may
// already have consumed the motion event by starting a new dispatch cycle if needed.
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
2010-06-15 01:31:58 -07:00
if (mCurrentInputTargetsValid) {
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
for (size_t i = 0; i < mCurrentInputTargets.size(); i++) {
const InputTarget& inputTarget = mCurrentInputTargets[i];
if ((inputTarget.flags & InputTarget::FLAG_FOREGROUND) == 0) {
// Skip non-foreground targets. We only want to stream if there is at
// least one foreground target whose dispatch is still in progress.
continue;
}
ssize_t connectionIndex = getConnectionIndexLocked(inputTarget.inputChannel);
if (connectionIndex < 0) {
// Connection must no longer be valid.
continue;
}
sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);
if (connection->outboundQueue.isEmpty()) {
// This foreground target has an empty outbound queue.
continue;
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
2010-04-22 18:58:52 -07:00
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
DispatchEntry* dispatchEntry = connection->outboundQueue.head;
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
if (! dispatchEntry->inProgress
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
|| dispatchEntry->eventEntry->type != EventEntry::TYPE_MOTION
|| dispatchEntry->isSplit()) {
// No motion event is being dispatched, or it is being split across
// windows in which case we cannot stream.
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
continue;
}
MotionEntry* motionEntry = static_cast<MotionEntry*>(
dispatchEntry->eventEntry);
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
if (motionEntry->action != args->action
|| motionEntry->deviceId != args->deviceId
|| motionEntry->source != args->source
|| motionEntry->pointerCount != args->pointerCount
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
|| motionEntry->isInjected()) {
// The motion event is not compatible with this move.
continue;
}
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
if (args->action == AMOTION_EVENT_ACTION_HOVER_MOVE) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mLastHoverWindowHandle == NULL) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
#if DEBUG_BATCHING
LOGD("Not streaming hover move because there is no "
"last hovered window.");
#endif
goto NoBatchingOrStreaming;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> hoverWindowHandle = findTouchedWindowAtLocked(
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
args->pointerCoords[0].getAxisValue(AMOTION_EVENT_AXIS_X),
args->pointerCoords[0].getAxisValue(AMOTION_EVENT_AXIS_Y));
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mLastHoverWindowHandle != hoverWindowHandle) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
#if DEBUG_BATCHING
LOGD("Not streaming hover move because the last hovered window "
"is '%s' but the currently hovered window is '%s'.",
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
2011-08-30 20:34:48 -07:00
mLastHoverWindowHandle->getName().string(),
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
hoverWindowHandle != NULL
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
2011-08-30 20:34:48 -07:00
? hoverWindowHandle->getName().string() : "<null>");
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
#endif
goto NoBatchingOrStreaming;
}
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
// Hurray! This foreground target is currently dispatching a move event
// that we can stream onto. Append the motion sample and resume dispatch.
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
motionEntry->appendSample(args->eventTime, args->pointerCoords);
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
#if DEBUG_BATCHING
LOGD("Appended motion sample onto batch for most recently dispatched "
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
"motion event for this device and source in the outbound queues. "
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
"Attempting to stream the motion sample.");
#endif
nsecs_t currentTime = now();
dispatchEventToCurrentInputTargetsLocked(currentTime, motionEntry,
true /*resumeWithAppendedMotionSample*/);
runCommandsLockedInterruptible();
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
mLock.unlock();
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
return; // done!
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
2010-04-22 18:58:52 -07:00
}
}
NoBatchingOrStreaming:;
}
// Just enqueue a new motion event.
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
MotionEntry* newEntry = new MotionEntry(args->eventTime,
args->deviceId, args->source, policyFlags,
args->action, args->flags, args->metaState, args->buttonState,
args->edgeFlags, args->xPrecision, args->yPrecision, args->downTime,
args->pointerCount, args->pointerProperties, args->pointerCoords);
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
2010-04-22 18:58:52 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
needWake = enqueueInboundEventLocked(newEntry);
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
mLock.unlock();
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
2010-04-22 18:58:52 -07:00
} // release lock
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (needWake) {
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
2010-09-13 23:17:30 -07:00
mLooper->wake();
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
2010-04-22 18:58:52 -07:00
}
}
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
void InputDispatcher::batchMotionLocked(MotionEntry* entry, nsecs_t eventTime,
int32_t metaState, const PointerCoords* pointerCoords, const char* eventDescription) {
// Combine meta states.
entry->metaState |= metaState;
// Coalesce this sample if not enough time has elapsed since the last sample was
// initially appended to the batch.
MotionSample* lastSample = entry->lastSample;
long interval = eventTime - lastSample->eventTimeBeforeCoalescing;
if (interval <= MOTION_SAMPLE_COALESCE_INTERVAL) {
uint32_t pointerCount = entry->pointerCount;
for (uint32_t i = 0; i < pointerCount; i++) {
lastSample->pointerCoords[i].copyFrom(pointerCoords[i]);
}
lastSample->eventTime = eventTime;
#if DEBUG_BATCHING
LOGD("Coalesced motion into last sample of batch for %s, events were %0.3f ms apart",
eventDescription, interval * 0.000001f);
#endif
return;
}
// Append the sample.
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
entry->appendSample(eventTime, pointerCoords);
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
#if DEBUG_BATCHING
LOGD("Appended motion sample onto batch for %s, events were %0.3f ms apart",
eventDescription, interval * 0.000001f);
#endif
}
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
void InputDispatcher::notifySwitch(const NotifySwitchArgs* args) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#if DEBUG_INBOUND_EVENT_DETAILS
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
LOGD("notifySwitch - eventTime=%lld, policyFlags=0x%x, switchCode=%d, switchValue=%d",
args->eventTime, args->policyFlags,
args->switchCode, args->switchValue);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
uint32_t policyFlags = args->policyFlags;
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
policyFlags |= POLICY_FLAG_TRUSTED;
Refactor input reader to add stylus support. Bug: 5064702 Introduced the concept of an InputListener to further decouple the InputReader from the InputDispatcher. The InputListener exposes just the minimum interface that the InputReader needs to communicate with the outside world. The InputReader passes arguments to the InputListener by reference, which makes it easy to queue them up. Consolidated all of the InputReader locks into one simple global Mutex. The reason this wasn't done before was due to potential re-entrance in outbound calls to the InputDispatcher. To fix this, the InputReader now queues up all of the events it wants to send using a QueuedInputListener, then flushes them outside of the critical section after all of the event processing is finished. Removing all of the InputMapper locks greatly simplifies the implementation. Added tests for new stylus features such as buttons, tool types, and hovering. Added some helpers to BitSet32 to handle common code patterns like finding the first marked bit and clearing it. Fixed a bug in VelocityTracker where the wrong pointer trace could get cleared when handling ACTION_POINTER_DOWN. Oops. Changed PointerCoords so it no longer stores useless zero axis values. Removed editAxisValue because it is not very useful when all zero value axes are absent and therefore cannot be edited in place. Added dispatch of stylus hover events. Added support for distance and tool types. Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
2011-07-27 16:04:54 -07:00
mPolicy->notifySwitch(args->eventTime,
args->switchCode, args->switchValue, policyFlags);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Input system bug fixes, particularly for stylus. Bug: 5049148 Finished stylus support, including support for indirect stylus and mouse tools. Added TILT axis. When stylus tilt X/Y is available, it is transformed into an orientation and tilt inclination which is a more convenient representation and a simpler extension to the exiting API. Touch devices now only report touch data using a single input source. Previously touch devices in pointer mode would report both absolute touch pad data and cooked pointer gestures. Now we just pick one. The touch device switches modes as needed when the focused application enables/disables pointer gestures. This change greatly simplifies the code and reduces the load on the input dispatcher. Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE would be zero whenever the stylus was in direct contact. It appears that the correct way to determine whether the stylus is in direct contact (rather than hovering) is by checking for a non-zero reported pressure. Added code to read the initial state of tool buttons and axis values when the input devices are initialized or reset. This fixes problems where the input mapper state might have the wrong initial state. Moved responsibility for cancelling pending inputs (keys down, touches, etc.) to the InputDispatcher by sending it a device reset notification. This frees the InputReader from having to synthesize events during reset, which was cumbersome and somewhat brittle to begin with. Consolidated more of the common accumulator logic from SingleTouchInputMapper and MultiTouchInputMapper into TouchInputMapper. Improved the PointerLocation output. Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
2011-08-18 11:20:58 -07:00
void InputDispatcher::notifyDeviceReset(const NotifyDeviceResetArgs* args) {
#if DEBUG_INBOUND_EVENT_DETAILS
LOGD("notifyDeviceReset - eventTime=%lld, deviceId=%d",
args->eventTime, args->deviceId);
#endif
bool needWake;
{ // acquire lock
AutoMutex _l(mLock);
DeviceResetEntry* newEntry = new DeviceResetEntry(args->eventTime, args->deviceId);
needWake = enqueueInboundEventLocked(newEntry);
} // release lock
if (needWake) {
mLooper->wake();
}
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
int32_t InputDispatcher::injectInputEvent(const InputEvent* event,
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
int32_t injectorPid, int32_t injectorUid, int32_t syncMode, int32_t timeoutMillis,
uint32_t policyFlags) {
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
#if DEBUG_INBOUND_EVENT_DETAILS
LOGD("injectInputEvent - eventType=%d, injectorPid=%d, injectorUid=%d, "
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
"syncMode=%d, timeoutMillis=%d, policyFlags=0x%08x",
event->getType(), injectorPid, injectorUid, syncMode, timeoutMillis, policyFlags);
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
#endif
nsecs_t endTime = now() + milliseconds_to_nanoseconds(timeoutMillis);
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
policyFlags |= POLICY_FLAG_INJECTED;
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
2010-10-11 14:20:19 -07:00
if (hasInjectionPermission(injectorPid, injectorUid)) {
policyFlags |= POLICY_FLAG_TRUSTED;
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
EventEntry* injectedEntry;
switch (event->getType()) {
case AINPUT_EVENT_TYPE_KEY: {
const KeyEvent* keyEvent = static_cast<const KeyEvent*>(event);
int32_t action = keyEvent->getAction();
if (! validateKeyEvent(action)) {
return INPUT_EVENT_INJECTION_FAILED;
}
int32_t flags = keyEvent->getFlags();
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
if (flags & AKEY_EVENT_FLAG_VIRTUAL_HARD_KEY) {
policyFlags |= POLICY_FLAG_VIRTUAL;
}
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
if (!(policyFlags & POLICY_FLAG_FILTERED)) {
mPolicy->interceptKeyBeforeQueueing(keyEvent, /*byref*/ policyFlags);
}
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
if (policyFlags & POLICY_FLAG_WOKE_HERE) {
flags |= AKEY_EVENT_FLAG_WOKE_HERE;
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
mLock.lock();
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
injectedEntry = new KeyEntry(keyEvent->getEventTime(),
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
keyEvent->getDeviceId(), keyEvent->getSource(),
policyFlags, action, flags,
keyEvent->getKeyCode(), keyEvent->getScanCode(), keyEvent->getMetaState(),
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
keyEvent->getRepeatCount(), keyEvent->getDownTime());
break;
}
case AINPUT_EVENT_TYPE_MOTION: {
const MotionEvent* motionEvent = static_cast<const MotionEvent*>(event);
int32_t action = motionEvent->getAction();
size_t pointerCount = motionEvent->getPointerCount();
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
const PointerProperties* pointerProperties = motionEvent->getPointerProperties();
if (! validateMotionEvent(action, pointerCount, pointerProperties)) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
return INPUT_EVENT_INJECTION_FAILED;
}
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
if (!(policyFlags & POLICY_FLAG_FILTERED)) {
nsecs_t eventTime = motionEvent->getEventTime();
mPolicy->interceptMotionBeforeQueueing(eventTime, /*byref*/ policyFlags);
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
mLock.lock();
const nsecs_t* sampleEventTimes = motionEvent->getSampleEventTimes();
const PointerCoords* samplePointerCoords = motionEvent->getSamplePointerCoords();
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
MotionEntry* motionEntry = new MotionEntry(*sampleEventTimes,
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
motionEvent->getDeviceId(), motionEvent->getSource(), policyFlags,
action, motionEvent->getFlags(),
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
motionEvent->getMetaState(), motionEvent->getButtonState(),
motionEvent->getEdgeFlags(),
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
motionEvent->getXPrecision(), motionEvent->getYPrecision(),
motionEvent->getDownTime(), uint32_t(pointerCount),
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
pointerProperties, samplePointerCoords);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
for (size_t i = motionEvent->getHistorySize(); i > 0; i--) {
sampleEventTimes += 1;
samplePointerCoords += pointerCount;
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
motionEntry->appendSample(*sampleEventTimes, samplePointerCoords);
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
injectedEntry = motionEntry;
break;
}
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
default:
LOGW("Cannot inject event of type %d", event->getType());
return INPUT_EVENT_INJECTION_FAILED;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InjectionState* injectionState = new InjectionState(injectorPid, injectorUid);
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
if (syncMode == INPUT_EVENT_INJECTION_SYNC_NONE) {
injectionState->injectionIsAsync = true;
}
injectionState->refCount += 1;
injectedEntry->injectionState = injectionState;
bool needWake = enqueueInboundEventLocked(injectedEntry);
mLock.unlock();
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (needWake) {
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
2010-09-13 23:17:30 -07:00
mLooper->wake();
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
}
int32_t injectionResult;
{ // acquire lock
AutoMutex _l(mLock);
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
if (syncMode == INPUT_EVENT_INJECTION_SYNC_NONE) {
injectionResult = INPUT_EVENT_INJECTION_SUCCEEDED;
} else {
for (;;) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionResult = injectionState->injectionResult;
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
if (injectionResult != INPUT_EVENT_INJECTION_PENDING) {
break;
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
nsecs_t remainingTimeout = endTime - now();
if (remainingTimeout <= 0) {
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
#if DEBUG_INJECTION
LOGD("injectInputEvent - Timed out waiting for injection result "
"to become available.");
#endif
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
injectionResult = INPUT_EVENT_INJECTION_TIMED_OUT;
break;
}
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
mInjectionResultAvailableCondition.waitRelative(mLock, remainingTimeout);
}
if (injectionResult == INPUT_EVENT_INJECTION_SUCCEEDED
&& syncMode == INPUT_EVENT_INJECTION_SYNC_WAIT_FOR_FINISHED) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
while (injectionState->pendingForegroundDispatches != 0) {
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
#if DEBUG_INJECTION
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
LOGD("injectInputEvent - Waiting for %d pending foreground dispatches.",
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionState->pendingForegroundDispatches);
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
#endif
nsecs_t remainingTimeout = endTime - now();
if (remainingTimeout <= 0) {
#if DEBUG_INJECTION
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
LOGD("injectInputEvent - Timed out waiting for pending foreground "
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
"dispatches to finish.");
#endif
injectionResult = INPUT_EVENT_INJECTION_TIMED_OUT;
break;
}
mInjectionSyncFinishedCondition.waitRelative(mLock, remainingTimeout);
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
}
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
injectionState->release();
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
} // release lock
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
#if DEBUG_INJECTION
LOGD("injectInputEvent - Finished with result %d. "
"injectorPid=%d, injectorUid=%d",
injectionResult, injectorPid, injectorUid);
#endif
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
return injectionResult;
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
bool InputDispatcher::hasInjectionPermission(int32_t injectorPid, int32_t injectorUid) {
return injectorUid == 0
|| mPolicy->checkInjectEventsPermissionNonReentrant(injectorPid, injectorUid);
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
void InputDispatcher::setInjectionResultLocked(EventEntry* entry, int32_t injectionResult) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
InjectionState* injectionState = entry->injectionState;
if (injectionState) {
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
#if DEBUG_INJECTION
LOGD("Setting input event injection result to %d. "
"injectorPid=%d, injectorUid=%d",
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionResult, injectionState->injectorPid, injectionState->injectorUid);
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
#endif
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
if (injectionState->injectionIsAsync
&& !(entry->policyFlags & POLICY_FLAG_FILTERED)) {
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
// Log the outcome since the injector did not wait for the injection result.
switch (injectionResult) {
case INPUT_EVENT_INJECTION_SUCCEEDED:
Rename (IF_)LOGV(_IF) to (IF_)ALOGV(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/#/c/143865 Bug: 5449033 Change-Id: I0122812ed6ff6f5b59fe4a43ab8bff0577adde0a
2011-10-20 11:56:00 +01:00
ALOGV("Asynchronous input event injection succeeded.");
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
break;
case INPUT_EVENT_INJECTION_FAILED:
LOGW("Asynchronous input event injection failed.");
break;
case INPUT_EVENT_INJECTION_PERMISSION_DENIED:
LOGW("Asynchronous input event injection permission denied.");
break;
case INPUT_EVENT_INJECTION_TIMED_OUT:
LOGW("Asynchronous input event injection timed out.");
break;
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
injectionState->injectionResult = injectionResult;
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
mInjectionResultAvailableCondition.broadcast();
}
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
void InputDispatcher::incrementPendingForegroundDispatchesLocked(EventEntry* entry) {
InjectionState* injectionState = entry->injectionState;
if (injectionState) {
injectionState->pendingForegroundDispatches += 1;
DO NOT MERGE: Fix input event injection ANRs on UI thread. Added a new asynchronous injection mode and made the existing synchronization mechanism more robust. Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
2010-07-28 15:48:59 -07:00
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
void InputDispatcher::decrementPendingForegroundDispatchesLocked(EventEntry* entry) {
InjectionState* injectionState = entry->injectionState;
if (injectionState) {
injectionState->pendingForegroundDispatches -= 1;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
if (injectionState->pendingForegroundDispatches == 0) {
mInjectionSyncFinishedCondition.broadcast();
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> InputDispatcher::getWindowHandleLocked(
const sp<InputChannel>& inputChannel) const {
size_t numWindows = mWindowHandles.size();
for (size_t i = 0; i < numWindows; i++) {
const sp<InputWindowHandle>& windowHandle = mWindowHandles.itemAt(i);
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
2011-08-30 20:34:48 -07:00
if (windowHandle->getInputChannel() == inputChannel) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
return windowHandle;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
}
return NULL;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
bool InputDispatcher::hasWindowHandleLocked(
const sp<InputWindowHandle>& windowHandle) const {
size_t numWindows = mWindowHandles.size();
for (size_t i = 0; i < numWindows; i++) {
if (mWindowHandles.itemAt(i) == windowHandle) {
return true;
}
}
return false;
}
void InputDispatcher::setInputWindows(const Vector<sp<InputWindowHandle> >& inputWindowHandles) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
LOGD("setInputWindows");
#endif
{ // acquire lock
AutoMutex _l(mLock);
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
2011-08-30 20:34:48 -07:00
Vector<sp<InputWindowHandle> > oldWindowHandles = mWindowHandles;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mWindowHandles = inputWindowHandles;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> newFocusedWindowHandle;
bool foundHoveredWindow = false;
for (size_t i = 0; i < mWindowHandles.size(); i++) {
const sp<InputWindowHandle>& windowHandle = mWindowHandles.itemAt(i);
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
2011-08-30 20:34:48 -07:00
if (!windowHandle->updateInfo() || windowHandle->getInputChannel() == NULL) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mWindowHandles.removeAt(i--);
continue;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2011-08-30 20:34:48 -07:00
if (windowHandle->getInfo()->hasFocus) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
newFocusedWindowHandle = windowHandle;
}
if (windowHandle == mLastHoverWindowHandle) {
foundHoveredWindow = true;
}
}
if (!foundHoveredWindow) {
mLastHoverWindowHandle = NULL;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mFocusedWindowHandle != newFocusedWindowHandle) {
if (mFocusedWindowHandle != NULL) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#if DEBUG_FOCUS
LOGD("Focus left window: %s",
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
2011-08-30 20:34:48 -07:00
mFocusedWindowHandle->getName().string());
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
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
2011-08-30 20:34:48 -07:00
sp<InputChannel> focusedInputChannel = mFocusedWindowHandle->getInputChannel();
if (focusedInputChannel != NULL) {
Don't crash if a drag recipient throws an uncaught exception There turn out to be two distinct bugs leading to runtime restarts. The first, dating from at least Android 3.1, is that following certain kinds of app crashes we properly clean up the drag-state bookkeeping, but aren't prepared in the case of the drag-target timeout clock firing with a now- null drag state in effect. We now catch that edge condition and don't NPE (and note that there was already similar code around the separate timeout when an app is *starting* the drag process). The second bug is that some new-in-ICS code in the input channel management wasn't prepared for certain cases where the current touch window could have become unusable and its input channel torn down summarily in the case of the aforesaid app crash during drag. The code now makes sure that there really is an input channel that needs to be flushed / cancelled prior to attempting that operation. Fixes bug 5173534 Change-Id: Idaae158ecfb4b93456ab1425769b669962893c00
2011-08-16 16:09:33 -07:00
CancelationOptions options(CancelationOptions::CANCEL_NON_POINTER_EVENTS,
"focus left window");
synthesizeCancelationEventsForInputChannelLocked(
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
2011-08-30 20:34:48 -07:00
focusedInputChannel, options);
Don't crash if a drag recipient throws an uncaught exception There turn out to be two distinct bugs leading to runtime restarts. The first, dating from at least Android 3.1, is that following certain kinds of app crashes we properly clean up the drag-state bookkeeping, but aren't prepared in the case of the drag-target timeout clock firing with a now- null drag state in effect. We now catch that edge condition and don't NPE (and note that there was already similar code around the separate timeout when an app is *starting* the drag process). The second bug is that some new-in-ICS code in the input channel management wasn't prepared for certain cases where the current touch window could have become unusable and its input channel torn down summarily in the case of the aforesaid app crash during drag. The code now makes sure that there really is an input channel that needs to be flushed / cancelled prior to attempting that operation. Fixes bug 5173534 Change-Id: Idaae158ecfb4b93456ab1425769b669962893c00
2011-08-16 16:09:33 -07:00
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (newFocusedWindowHandle != NULL) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#if DEBUG_FOCUS
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
LOGD("Focus entered window: %s",
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
2011-08-30 20:34:48 -07:00
newFocusedWindowHandle->getName().string());
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
}
mFocusedWindowHandle = newFocusedWindowHandle;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
for (size_t i = 0; i < mTouchState.windows.size(); i++) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
TouchedWindow& touchedWindow = mTouchState.windows.editItemAt(i);
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (!hasWindowHandleLocked(touchedWindow.windowHandle)) {
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#if DEBUG_FOCUS
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
2011-08-30 20:34:48 -07:00
LOGD("Touched window was removed: %s",
touchedWindow.windowHandle->getName().string());
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
#endif
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
2011-08-30 20:34:48 -07:00
sp<InputChannel> touchedInputChannel =
touchedWindow.windowHandle->getInputChannel();
if (touchedInputChannel != NULL) {
Don't crash if a drag recipient throws an uncaught exception There turn out to be two distinct bugs leading to runtime restarts. The first, dating from at least Android 3.1, is that following certain kinds of app crashes we properly clean up the drag-state bookkeeping, but aren't prepared in the case of the drag-target timeout clock firing with a now- null drag state in effect. We now catch that edge condition and don't NPE (and note that there was already similar code around the separate timeout when an app is *starting* the drag process). The second bug is that some new-in-ICS code in the input channel management wasn't prepared for certain cases where the current touch window could have become unusable and its input channel torn down summarily in the case of the aforesaid app crash during drag. The code now makes sure that there really is an input channel that needs to be flushed / cancelled prior to attempting that operation. Fixes bug 5173534 Change-Id: Idaae158ecfb4b93456ab1425769b669962893c00
2011-08-16 16:09:33 -07:00
CancelationOptions options(CancelationOptions::CANCEL_POINTER_EVENTS,
"touched window was removed");
synthesizeCancelationEventsForInputChannelLocked(
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
2011-08-30 20:34:48 -07:00
touchedInputChannel, options);
Don't crash if a drag recipient throws an uncaught exception There turn out to be two distinct bugs leading to runtime restarts. The first, dating from at least Android 3.1, is that following certain kinds of app crashes we properly clean up the drag-state bookkeeping, but aren't prepared in the case of the drag-target timeout clock firing with a now- null drag state in effect. We now catch that edge condition and don't NPE (and note that there was already similar code around the separate timeout when an app is *starting* the drag process). The second bug is that some new-in-ICS code in the input channel management wasn't prepared for certain cases where the current touch window could have become unusable and its input channel torn down summarily in the case of the aforesaid app crash during drag. The code now makes sure that there really is an input channel that needs to be flushed / cancelled prior to attempting that operation. Fixes bug 5173534 Change-Id: Idaae158ecfb4b93456ab1425769b669962893c00
2011-08-16 16:09:33 -07:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTouchState.windows.removeAt(i--);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
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
2011-08-30 20:34:48 -07:00
// Release information for windows that are no longer present.
// This ensures that unused input channels are released promptly.
// Otherwise, they might stick around until the window handle is destroyed
// which might not happen until the next GC.
for (size_t i = 0; i < oldWindowHandles.size(); i++) {
const sp<InputWindowHandle>& oldWindowHandle = oldWindowHandles.itemAt(i);
if (!hasWindowHandleLocked(oldWindowHandle)) {
#if DEBUG_FOCUS
LOGD("Window went away: %s", oldWindowHandle->getName().string());
#endif
oldWindowHandle->releaseInfo();
}
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
} // release lock
// Wake up poll loop since it may need to make new input dispatching choices.
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
2010-09-13 23:17:30 -07:00
mLooper->wake();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
void InputDispatcher::setFocusedApplication(
const sp<InputApplicationHandle>& inputApplicationHandle) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
LOGD("setFocusedApplication");
#endif
{ // acquire lock
AutoMutex _l(mLock);
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
2011-08-30 20:34:48 -07:00
if (inputApplicationHandle != NULL && inputApplicationHandle->updateInfo()) {
Reset input dispatcher targets when focus changes apps. This fixes an issue where an ANR can occur in a newly focused application through no fault of its own, simply because the previous app took a little while to transfer focus to the new app. Bug: 4584620 Change-Id: If3227eb68d92a09a108e9de7f0afcbd9a5dbdead
2011-07-27 11:50:51 -07:00
if (mFocusedApplicationHandle != inputApplicationHandle) {
if (mFocusedApplicationHandle != NULL) {
resetTargetsLocked();
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
2011-08-30 20:34:48 -07:00
mFocusedApplicationHandle->releaseInfo();
Reset input dispatcher targets when focus changes apps. This fixes an issue where an ANR can occur in a newly focused application through no fault of its own, simply because the previous app took a little while to transfer focus to the new app. Bug: 4584620 Change-Id: If3227eb68d92a09a108e9de7f0afcbd9a5dbdead
2011-07-27 11:50:51 -07:00
}
mFocusedApplicationHandle = inputApplicationHandle;
}
} else if (mFocusedApplicationHandle != NULL) {
resetTargetsLocked();
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
2011-08-30 20:34:48 -07:00
mFocusedApplicationHandle->releaseInfo();
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mFocusedApplicationHandle.clear();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
#if DEBUG_FOCUS
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
//logDispatchStateLocked();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
} // release lock
// Wake up poll loop since it may need to make new input dispatching choices.
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
2010-09-13 23:17:30 -07:00
mLooper->wake();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
void InputDispatcher::setInputDispatchMode(bool enabled, bool frozen) {
#if DEBUG_FOCUS
LOGD("setInputDispatchMode: enabled=%d, frozen=%d", enabled, frozen);
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
2010-06-22 01:27:15 -07:00
#endif
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
bool changed;
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
2010-06-22 01:27:15 -07:00
{ // acquire lock
AutoMutex _l(mLock);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (mDispatchEnabled != enabled || mDispatchFrozen != frozen) {
Drop all dispatcher state when dispatcher is disabled. This patch makes the dispatcher drop all of its state when it is disabled (when the screen turns off). This ensures that the dispatcher does not get stuck thinking a pointer is still down if the screen turned off while the user was touching the display (such as a fat touch while hitting the power button). Bug: 3098344 Change-Id: If50ef5804870aa1acd3179fd4b40e3cda58dd39d
2010-10-27 18:43:51 -07:00
if (mDispatchFrozen && !frozen) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
resetANRTimeoutsLocked();
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
2010-06-22 01:27:15 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Drop all dispatcher state when dispatcher is disabled. This patch makes the dispatcher drop all of its state when it is disabled (when the screen turns off). This ensures that the dispatcher does not get stuck thinking a pointer is still down if the screen turned off while the user was touching the display (such as a fat touch while hitting the power button). Bug: 3098344 Change-Id: If50ef5804870aa1acd3179fd4b40e3cda58dd39d
2010-10-27 18:43:51 -07:00
if (mDispatchEnabled && !enabled) {
resetAndDropEverythingLocked("dispatcher is being disabled");
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mDispatchEnabled = enabled;
mDispatchFrozen = frozen;
changed = true;
} else {
changed = false;
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
2010-06-22 01:27:15 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#if DEBUG_FOCUS
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
//logDispatchStateLocked();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
#endif
} // release lock
if (changed) {
// Wake up poll loop since it may need to make new input dispatching choices.
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
2010-09-13 23:17:30 -07:00
mLooper->wake();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
2011-03-30 02:25:18 -07:00
void InputDispatcher::setInputFilterEnabled(bool enabled) {
#if DEBUG_FOCUS
LOGD("setInputFilterEnabled: enabled=%d", enabled);
#endif
{ // acquire lock
AutoMutex _l(mLock);
if (mInputFilterEnabled == enabled) {
return;
}
mInputFilterEnabled = enabled;
resetAndDropEverythingLocked("input filter is being enabled or disabled");
} // release lock
// Wake up poll loop since there might be work to do to drop everything.
mLooper->wake();
}
Add support for transferring touch focus. Prerequisite for drag and drop. Change-Id: Iedbe93ed0f3e1c4083130fe66b4ba06d416afce0
2010-09-27 14:52:15 -07:00
bool InputDispatcher::transferTouchFocus(const sp<InputChannel>& fromChannel,
const sp<InputChannel>& toChannel) {
#if DEBUG_FOCUS
LOGD("transferTouchFocus: fromChannel=%s, toChannel=%s",
fromChannel->getName().string(), toChannel->getName().string());
#endif
{ // acquire lock
AutoMutex _l(mLock);
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> fromWindowHandle = getWindowHandleLocked(fromChannel);
sp<InputWindowHandle> toWindowHandle = getWindowHandleLocked(toChannel);
if (fromWindowHandle == NULL || toWindowHandle == NULL) {
Add support for transferring touch focus. Prerequisite for drag and drop. Change-Id: Iedbe93ed0f3e1c4083130fe66b4ba06d416afce0
2010-09-27 14:52:15 -07:00
#if DEBUG_FOCUS
LOGD("Cannot transfer focus because from or to window not found.");
#endif
return false;
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (fromWindowHandle == toWindowHandle) {
Add support for transferring touch focus. Prerequisite for drag and drop. Change-Id: Iedbe93ed0f3e1c4083130fe66b4ba06d416afce0
2010-09-27 14:52:15 -07:00
#if DEBUG_FOCUS
LOGD("Trivial transfer to same window.");
#endif
return true;
}
bool found = false;
for (size_t i = 0; i < mTouchState.windows.size(); i++) {
const TouchedWindow& touchedWindow = mTouchState.windows[i];
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (touchedWindow.windowHandle == fromWindowHandle) {
Add support for transferring touch focus. Prerequisite for drag and drop. Change-Id: Iedbe93ed0f3e1c4083130fe66b4ba06d416afce0
2010-09-27 14:52:15 -07:00
int32_t oldTargetFlags = touchedWindow.targetFlags;
BitSet32 pointerIds = touchedWindow.pointerIds;
mTouchState.windows.removeAt(i);
Enable touch splitting for all windows by default. New default only applies to applications with targetSdkVersion >= HONEYCOMB. Old applications default to no touch splitting for their windows. In addition, enabled split touch for various system windows. Bug: 3049580 Change-Id: Idc8da9baa2cd8e1e4e76af8967d7b6a5ccb94427
2010-11-10 16:53:45 -08:00
int32_t newTargetFlags = oldTargetFlags
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
& (InputTarget::FLAG_FOREGROUND
| InputTarget::FLAG_SPLIT | InputTarget::FLAG_DISPATCH_AS_IS);
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mTouchState.addOrUpdateWindow(toWindowHandle, newTargetFlags, pointerIds);
Add support for transferring touch focus. Prerequisite for drag and drop. Change-Id: Iedbe93ed0f3e1c4083130fe66b4ba06d416afce0
2010-09-27 14:52:15 -07:00
found = true;
break;
}
}
if (! found) {
#if DEBUG_FOCUS
LOGD("Focus transfer failed because from window did not have focus.");
#endif
return false;
}
Track input state when transferring touch focus. Copies the input state to the destination window and sends synthesic cancelation events to the source window. Change-Id: Ia75820b0d756ed5d6cd22dce7830251ac85141ed
2010-10-11 18:32:20 -07:00
ssize_t fromConnectionIndex = getConnectionIndexLocked(fromChannel);
ssize_t toConnectionIndex = getConnectionIndexLocked(toChannel);
if (fromConnectionIndex >= 0 && toConnectionIndex >= 0) {
sp<Connection> fromConnection = mConnectionsByReceiveFd.valueAt(fromConnectionIndex);
sp<Connection> toConnection = mConnectionsByReceiveFd.valueAt(toConnectionIndex);
fromConnection->inputState.copyPointerStateTo(toConnection->inputState);
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
CancelationOptions options(CancelationOptions::CANCEL_POINTER_EVENTS,
Track input state when transferring touch focus. Copies the input state to the destination window and sends synthesic cancelation events to the source window. Change-Id: Ia75820b0d756ed5d6cd22dce7830251ac85141ed
2010-10-11 18:32:20 -07:00
"transferring touch focus from this window to another window");
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
synthesizeCancelationEventsForConnectionLocked(fromConnection, options);
Track input state when transferring touch focus. Copies the input state to the destination window and sends synthesic cancelation events to the source window. Change-Id: Ia75820b0d756ed5d6cd22dce7830251ac85141ed
2010-10-11 18:32:20 -07:00
}
Add support for transferring touch focus. Prerequisite for drag and drop. Change-Id: Iedbe93ed0f3e1c4083130fe66b4ba06d416afce0
2010-09-27 14:52:15 -07:00
#if DEBUG_FOCUS
logDispatchStateLocked();
#endif
} // release lock
// Wake up poll loop since it may need to make new input dispatching choices.
mLooper->wake();
return true;
}
Drop all dispatcher state when dispatcher is disabled. This patch makes the dispatcher drop all of its state when it is disabled (when the screen turns off). This ensures that the dispatcher does not get stuck thinking a pointer is still down if the screen turned off while the user was touching the display (such as a fat touch while hitting the power button). Bug: 3098344 Change-Id: If50ef5804870aa1acd3179fd4b40e3cda58dd39d
2010-10-27 18:43:51 -07:00
void InputDispatcher::resetAndDropEverythingLocked(const char* reason) {
#if DEBUG_FOCUS
LOGD("Resetting and dropping all events (%s).", reason);
#endif
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
CancelationOptions options(CancelationOptions::CANCEL_ALL_EVENTS, reason);
synthesizeCancelationEventsForAllConnectionsLocked(options);
Drop all dispatcher state when dispatcher is disabled. This patch makes the dispatcher drop all of its state when it is disabled (when the screen turns off). This ensures that the dispatcher does not get stuck thinking a pointer is still down if the screen turned off while the user was touching the display (such as a fat touch while hitting the power button). Bug: 3098344 Change-Id: If50ef5804870aa1acd3179fd4b40e3cda58dd39d
2010-10-27 18:43:51 -07:00
resetKeyRepeatLocked();
releasePendingEventLocked();
drainInboundQueueLocked();
resetTargetsLocked();
mTouchState.reset();
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
mLastHoverWindowHandle.clear();
Drop all dispatcher state when dispatcher is disabled. This patch makes the dispatcher drop all of its state when it is disabled (when the screen turns off). This ensures that the dispatcher does not get stuck thinking a pointer is still down if the screen turned off while the user was touching the display (such as a fat touch while hitting the power button). Bug: 3098344 Change-Id: If50ef5804870aa1acd3179fd4b40e3cda58dd39d
2010-10-27 18:43:51 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::logDispatchStateLocked() {
String8 dump;
dumpDispatchStateLocked(dump);
Fix input dispatcher regression on launcher drag&drop. Change-Id: I40e937bd712cd2ed6cceac95dfd1b8c8e070724f
2010-09-16 12:31:46 -07:00
char* text = dump.lockBuffer(dump.size());
char* start = text;
while (*start != '\0') {
char* end = strchr(start, '\n');
if (*end == '\n') {
*(end++) = '\0';
}
LOGD("%s", start);
start = end;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
void InputDispatcher::dumpDispatchStateLocked(String8& dump) {
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.appendFormat(INDENT "DispatchEnabled: %d\n", mDispatchEnabled);
dump.appendFormat(INDENT "DispatchFrozen: %d\n", mDispatchFrozen);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (mFocusedApplicationHandle != NULL) {
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.appendFormat(INDENT "FocusedApplication: name='%s', dispatchingTimeout=%0.3fms\n",
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
2011-08-30 20:34:48 -07:00
mFocusedApplicationHandle->getName().string(),
mFocusedApplicationHandle->getDispatchingTimeout(
DEFAULT_INPUT_DISPATCHING_TIMEOUT) / 1000000.0);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
} else {
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.append(INDENT "FocusedApplication: <null>\n");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.appendFormat(INDENT "FocusedWindow: name='%s'\n",
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
2011-08-30 20:34:48 -07:00
mFocusedWindowHandle != NULL ? mFocusedWindowHandle->getName().string() : "<null>");
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.appendFormat(INDENT "TouchDown: %s\n", toString(mTouchState.down));
dump.appendFormat(INDENT "TouchSplit: %s\n", toString(mTouchState.split));
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
dump.appendFormat(INDENT "TouchDeviceId: %d\n", mTouchState.deviceId);
Fix crashes caused by some input devices. The touch screen sometimes reports more than 10 pointers even though that's all we asked for. When this happens, we start dropping events with more than 10 pointers. This confuses applications and causes them to crash. Raised the limit to 16 pointers. Bug: 3331247 The default behavior was to identify all touch devices as touch screens. External devices that are plugged in are more likely to be touch pads not attached to a screen. Changed the default to be a touch pad and renamed some internal constants to avoid confusion. A certain mouse happens to also behave like a touch pad. That caused problems because we would see multiple concurrent traces of motion events coming from the same input device so we would batch them up. Added code to ensure that we don't batch events unless they come from the same *source* in addition to coming from the same *device*. Due to batching or misbehaving drivers, it's possible for the set of pointer ids to be different from what we expect when it comes time to split motion events across windows. As a result, we can generate motion events with 0 pointers. When we try to deliver those events, we cause an error in the InputTransport so we tear down the InputChannel and kill the application. Added code to check out assumption about pointer ids and drop the event gracefully instead. Patched up the tests to take into account the change in default behavior for identifying touch screens and touch pads. Change-Id: Ic364bd4cb4cc6335d4a1213a26d6bdadc7e33505
2011-01-25 16:02:22 -08:00
dump.appendFormat(INDENT "TouchSource: 0x%08x\n", mTouchState.source);
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
if (!mTouchState.windows.isEmpty()) {
dump.append(INDENT "TouchedWindows:\n");
for (size_t i = 0; i < mTouchState.windows.size(); i++) {
const TouchedWindow& touchedWindow = mTouchState.windows[i];
dump.appendFormat(INDENT2 "%d: name='%s', pointerIds=0x%0x, targetFlags=0x%x\n",
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
2011-08-30 20:34:48 -07:00
i, touchedWindow.windowHandle->getName().string(),
touchedWindow.pointerIds.value,
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
touchedWindow.targetFlags);
}
} else {
dump.append(INDENT "TouchedWindows: <none>\n");
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (!mWindowHandles.isEmpty()) {
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.append(INDENT "Windows:\n");
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
for (size_t i = 0; i < mWindowHandles.size(); i++) {
const sp<InputWindowHandle>& windowHandle = mWindowHandles.itemAt(i);
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
2011-08-30 20:34:48 -07:00
const InputWindowInfo* windowInfo = windowHandle->getInfo();
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.appendFormat(INDENT2 "%d: name='%s', paused=%s, hasFocus=%s, hasWallpaper=%s, "
"visible=%s, canReceiveKeys=%s, flags=0x%08x, type=0x%08x, layer=%d, "
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
"frame=[%d,%d][%d,%d], scale=%f, "
Support non-rectangular input regions. This enables the system bar to carve out a region through which events will be sent to the IME behind it. Bug: 3238092 Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
2011-01-16 14:06:57 -08:00
"touchableRegion=",
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
2011-08-30 20:34:48 -07:00
i, windowInfo->name.string(),
toString(windowInfo->paused),
toString(windowInfo->hasFocus),
toString(windowInfo->hasWallpaper),
toString(windowInfo->visible),
toString(windowInfo->canReceiveKeys),
windowInfo->layoutParamsFlags, windowInfo->layoutParamsType,
windowInfo->layer,
windowInfo->frameLeft, windowInfo->frameTop,
windowInfo->frameRight, windowInfo->frameBottom,
windowInfo->scaleFactor);
dumpRegion(dump, windowInfo->touchableRegion);
dump.appendFormat(", inputFeatures=0x%08x", windowInfo->inputFeatures);
Support non-rectangular input regions. This enables the system bar to carve out a region through which events will be sent to the IME behind it. Bug: 3238092 Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
2011-01-16 14:06:57 -08:00
dump.appendFormat(", ownerPid=%d, ownerUid=%d, dispatchingTimeout=%0.3fms\n",
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
2011-08-30 20:34:48 -07:00
windowInfo->ownerPid, windowInfo->ownerUid,
windowInfo->dispatchingTimeout / 1000000.0);
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
}
} else {
dump.append(INDENT "Windows: <none>\n");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
if (!mMonitoringChannels.isEmpty()) {
dump.append(INDENT "MonitoringChannels:\n");
for (size_t i = 0; i < mMonitoringChannels.size(); i++) {
const sp<InputChannel>& channel = mMonitoringChannels[i];
dump.appendFormat(INDENT2 "%d: '%s'\n", i, channel->getName().string());
}
} else {
dump.append(INDENT "MonitoringChannels: <none>\n");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.appendFormat(INDENT "InboundQueue: length=%u\n", mInboundQueue.count());
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
if (!mActiveConnections.isEmpty()) {
dump.append(INDENT "ActiveConnections:\n");
for (size_t i = 0; i < mActiveConnections.size(); i++) {
const Connection* connection = mActiveConnections[i];
Tweak log messages a bit. Change-Id: Ifadf78c1ab8db49106216c70086f98860795c65f
2010-10-25 17:37:46 -07:00
dump.appendFormat(INDENT2 "%d: '%s', status=%s, outboundQueueLength=%u, "
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
"inputState.isNeutral=%s\n",
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
i, connection->getInputChannelName(), connection->getStatusLabel(),
connection->outboundQueue.count(),
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
toString(connection->inputState.isNeutral()));
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
}
} else {
dump.append(INDENT "ActiveConnections: <none>\n");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
if (isAppSwitchPendingLocked()) {
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.appendFormat(INDENT "AppSwitch: pending, due in %01.1fms\n",
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
(mAppSwitchDueTime - now()) / 1000000.0);
} else {
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.append(INDENT "AppSwitch: not pending\n");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
status_t InputDispatcher::registerInputChannel(const sp<InputChannel>& inputChannel,
const sp<InputWindowHandle>& inputWindowHandle, bool monitor) {
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
2010-06-15 01:31:58 -07:00
#if DEBUG_REGISTRATION
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
LOGD("channel '%s' ~ registerInputChannel - monitor=%s", inputChannel->getName().string(),
toString(monitor));
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
2010-06-15 01:31:58 -07:00
#endif
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
2010-04-22 18:58:52 -07:00
{ // acquire lock
AutoMutex _l(mLock);
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
if (getConnectionIndexLocked(inputChannel) >= 0) {
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
2010-04-22 18:58:52 -07:00
LOGW("Attempted to register already registered input channel '%s'",
inputChannel->getName().string());
return BAD_VALUE;
}
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
2011-08-30 20:34:48 -07:00
sp<Connection> connection = new Connection(inputChannel, inputWindowHandle, monitor);
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
2010-04-22 18:58:52 -07:00
status_t status = connection->initialize();
if (status) {
LOGE("Failed to initialize input publisher for input channel '%s', status=%d",
inputChannel->getName().string(), status);
return status;
}
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
2010-08-17 15:59:26 -07:00
int32_t receiveFd = inputChannel->getReceivePipeFd();
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
2010-04-22 18:58:52 -07:00
mConnectionsByReceiveFd.add(receiveFd, connection);
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
2010-06-15 01:31:58 -07:00
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
if (monitor) {
mMonitoringChannels.push(inputChannel);
}
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
2010-09-13 23:17:30 -07:00
mLooper->addFd(receiveFd, 0, ALOOPER_EVENT_INPUT, handleReceiveCallback, this);
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
2010-08-17 15:59:26 -07:00
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
2010-06-15 01:31:58 -07:00
runCommandsLockedInterruptible();
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
2010-04-22 18:58:52 -07:00
} // release lock
return OK;
}
status_t InputDispatcher::unregisterInputChannel(const sp<InputChannel>& inputChannel) {
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
2010-06-15 01:31:58 -07:00
#if DEBUG_REGISTRATION
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
2010-06-22 01:27:15 -07:00
LOGD("channel '%s' ~ unregisterInputChannel", inputChannel->getName().string());
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
2010-06-15 01:31:58 -07:00
#endif
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
2010-04-22 18:58:52 -07:00
{ // acquire lock
AutoMutex _l(mLock);
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
2011-08-30 20:34:48 -07:00
status_t status = unregisterInputChannelLocked(inputChannel, false /*notify*/);
if (status) {
return status;
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
2010-04-22 18:58:52 -07:00
}
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
2011-08-30 20:34:48 -07:00
} // release lock
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
2010-04-22 18:58:52 -07:00
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
2011-08-30 20:34:48 -07:00
// Wake the poll loop because removing the connection may have changed the current
// synchronization state.
mLooper->wake();
return OK;
}
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
2010-04-22 18:58:52 -07:00
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
2011-08-30 20:34:48 -07:00
status_t InputDispatcher::unregisterInputChannelLocked(const sp<InputChannel>& inputChannel,
bool notify) {
ssize_t connectionIndex = getConnectionIndexLocked(inputChannel);
if (connectionIndex < 0) {
LOGW("Attempted to unregister already unregistered input channel '%s'",
inputChannel->getName().string());
return BAD_VALUE;
}
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
2010-04-22 18:58:52 -07:00
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
2011-08-30 20:34:48 -07:00
sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);
mConnectionsByReceiveFd.removeItemsAt(connectionIndex);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
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
2011-08-30 20:34:48 -07:00
if (connection->monitor) {
removeMonitorChannelLocked(inputChannel);
}
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
2010-08-17 15:59:26 -07:00
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
2011-08-30 20:34:48 -07:00
mLooper->removeFd(inputChannel->getReceivePipeFd());
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
2010-06-15 01:31:58 -07:00
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
2011-08-30 20:34:48 -07:00
nsecs_t currentTime = now();
abortBrokenDispatchCycleLocked(currentTime, connection, notify);
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
2010-04-22 18:58:52 -07:00
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
2011-08-30 20:34:48 -07:00
runCommandsLockedInterruptible();
connection->status = Connection::STATUS_ZOMBIE;
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
2010-04-22 18:58:52 -07:00
return OK;
}
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
2011-08-30 20:34:48 -07:00
void InputDispatcher::removeMonitorChannelLocked(const sp<InputChannel>& inputChannel) {
for (size_t i = 0; i < mMonitoringChannels.size(); i++) {
if (mMonitoringChannels[i] == inputChannel) {
mMonitoringChannels.removeAt(i);
break;
}
}
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
ssize_t InputDispatcher::getConnectionIndexLocked(const sp<InputChannel>& inputChannel) {
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
2010-08-17 15:59:26 -07:00
ssize_t connectionIndex = mConnectionsByReceiveFd.indexOfKey(inputChannel->getReceivePipeFd());
if (connectionIndex >= 0) {
sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);
if (connection->inputChannel.get() == inputChannel.get()) {
return connectionIndex;
}
}
return -1;
}
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
2010-04-22 18:58:52 -07:00
void InputDispatcher::activateConnectionLocked(Connection* connection) {
for (size_t i = 0; i < mActiveConnections.size(); i++) {
if (mActiveConnections.itemAt(i) == connection) {
return;
}
}
mActiveConnections.add(connection);
}
void InputDispatcher::deactivateConnectionLocked(Connection* connection) {
for (size_t i = 0; i < mActiveConnections.size(); i++) {
if (mActiveConnections.itemAt(i) == connection) {
mActiveConnections.removeAt(i);
return;
}
}
}
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
2010-06-15 01:31:58 -07:00
void InputDispatcher::onDispatchCycleStartedLocked(
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
nsecs_t currentTime, const sp<Connection>& connection) {
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
2010-04-22 18:58:52 -07:00
}
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
2010-06-15 01:31:58 -07:00
void InputDispatcher::onDispatchCycleFinishedLocked(
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
2010-11-05 15:02:16 -07:00
nsecs_t currentTime, const sp<Connection>& connection, bool handled) {
CommandEntry* commandEntry = postCommandLocked(
& InputDispatcher::doDispatchCycleFinishedLockedInterruptible);
commandEntry->connection = connection;
commandEntry->handled = handled;
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
2010-04-22 18:58:52 -07:00
}
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
2010-06-15 01:31:58 -07:00
void InputDispatcher::onDispatchCycleBrokenLocked(
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
nsecs_t currentTime, const sp<Connection>& connection) {
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
2010-04-22 18:58:52 -07:00
LOGE("channel '%s' ~ Channel is unrecoverably broken and will be disposed!",
connection->getInputChannelName());
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
2010-06-15 01:31:58 -07:00
CommandEntry* commandEntry = postCommandLocked(
& InputDispatcher::doNotifyInputChannelBrokenLockedInterruptible);
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
commandEntry->connection = connection;
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
2010-04-22 18:58:52 -07:00
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
void InputDispatcher::onANRLocked(
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
nsecs_t currentTime, const sp<InputApplicationHandle>& applicationHandle,
const sp<InputWindowHandle>& windowHandle,
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
nsecs_t eventTime, nsecs_t waitStartTime) {
LOGI("Application is not responding: %s. "
"%01.1fms since event, %01.1fms since wait started",
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
getApplicationWindowLabelLocked(applicationHandle, windowHandle).string(),
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
(currentTime - eventTime) / 1000000.0,
(currentTime - waitStartTime) / 1000000.0);
CommandEntry* commandEntry = postCommandLocked(
& InputDispatcher::doNotifyANRLockedInterruptible);
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
commandEntry->inputApplicationHandle = applicationHandle;
commandEntry->inputWindowHandle = windowHandle;
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::doNotifyConfigurationChangedInterruptible(
CommandEntry* commandEntry) {
mLock.unlock();
mPolicy->notifyConfigurationChanged(commandEntry->eventTime);
mLock.lock();
}
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
2010-06-15 01:31:58 -07:00
void InputDispatcher::doNotifyInputChannelBrokenLockedInterruptible(
CommandEntry* commandEntry) {
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
sp<Connection> connection = commandEntry->connection;
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
2010-06-15 01:31:58 -07:00
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
if (connection->status != Connection::STATUS_ZOMBIE) {
mLock.unlock();
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
2010-06-15 01:31:58 -07:00
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
mPolicy->notifyInputChannelBroken(connection->inputWindowHandle);
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
mLock.lock();
}
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
2010-06-15 01:31:58 -07:00
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
void InputDispatcher::doNotifyANRLockedInterruptible(
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
2010-06-15 01:31:58 -07:00
CommandEntry* commandEntry) {
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
mLock.unlock();
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
2010-06-15 01:31:58 -07:00
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
nsecs_t newTimeout = mPolicy->notifyANR(
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
commandEntry->inputApplicationHandle, commandEntry->inputWindowHandle);
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
2010-06-15 01:31:58 -07:00
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
mLock.lock();
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
resumeAfterTargetsNotReadyTimeoutLocked(newTimeout,
commandEntry->inputWindowHandle != NULL
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
2011-08-30 20:34:48 -07:00
? commandEntry->inputWindowHandle->getInputChannel() : NULL);
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
2010-06-15 01:31:58 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::doInterceptKeyBeforeDispatchingLockedInterruptible(
CommandEntry* commandEntry) {
KeyEntry* entry = commandEntry->keyEntry;
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
KeyEvent event;
initializeKeyEvent(&event, entry);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mLock.unlock();
Improve screenshot chord debouncing. Bug: 5011907 Introduce a 150ms delay in handling volume down keys while waiting to see if a power key will follow. Don't trigger the screenshot chord if both volume up and volume down are pressed together. Don't trigger the long-press power menu if volume keys are also pressed. Require the user to press both keys in the chord within the debounce time and continue long-pressing them in order to trigger the screenshot action. Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
2011-10-12 13:57:59 -07:00
nsecs_t delay = mPolicy->interceptKeyBeforeDispatching(commandEntry->inputWindowHandle,
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
2010-11-18 20:53:46 -08:00
&event, entry->policyFlags);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mLock.lock();
Improve screenshot chord debouncing. Bug: 5011907 Introduce a 150ms delay in handling volume down keys while waiting to see if a power key will follow. Don't trigger the screenshot chord if both volume up and volume down are pressed together. Don't trigger the long-press power menu if volume keys are also pressed. Require the user to press both keys in the chord within the debounce time and continue long-pressing them in order to trigger the screenshot action. Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
2011-10-12 13:57:59 -07:00
if (delay < 0) {
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_SKIP;
} else if (!delay) {
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_CONTINUE;
} else {
entry->interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER;
entry->interceptKeyWakeupTime = now() + delay;
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
entry->release();
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-11-05 15:02:16 -07:00
void InputDispatcher::doDispatchCycleFinishedLockedInterruptible(
CommandEntry* commandEntry) {
sp<Connection> connection = commandEntry->connection;
bool handled = commandEntry->handled;
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
bool skipNext = false;
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
if (!connection->outboundQueue.isEmpty()) {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
DispatchEntry* dispatchEntry = connection->outboundQueue.head;
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
if (dispatchEntry->inProgress) {
if (dispatchEntry->eventEntry->type == EventEntry::TYPE_KEY) {
KeyEntry* keyEntry = static_cast<KeyEntry*>(dispatchEntry->eventEntry);
skipNext = afterKeyEventLockedInterruptible(connection,
dispatchEntry, keyEntry, handled);
} else if (dispatchEntry->eventEntry->type == EventEntry::TYPE_MOTION) {
MotionEntry* motionEntry = static_cast<MotionEntry*>(dispatchEntry->eventEntry);
skipNext = afterMotionEventLockedInterruptible(connection,
dispatchEntry, motionEntry, handled);
}
}
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
if (!skipNext) {
startNextDispatchCycleLocked(now(), connection);
}
}
bool InputDispatcher::afterKeyEventLockedInterruptible(const sp<Connection>& connection,
DispatchEntry* dispatchEntry, KeyEntry* keyEntry, bool handled) {
if (!(keyEntry->flags & AKEY_EVENT_FLAG_FALLBACK)) {
// Get the fallback key state.
// Clear it out after dispatching the UP.
int32_t originalKeyCode = keyEntry->keyCode;
int32_t fallbackKeyCode = connection->inputState.getFallbackKey(originalKeyCode);
if (keyEntry->action == AKEY_EVENT_ACTION_UP) {
connection->inputState.removeFallbackKey(originalKeyCode);
}
if (handled || !dispatchEntry->hasForegroundTarget()) {
// If the application handles the original key for which we previously
// generated a fallback or if the window is not a foreground window,
// then cancel the associated fallback key, if any.
if (fallbackKeyCode != -1) {
if (fallbackKeyCode != AKEYCODE_UNKNOWN) {
CancelationOptions options(CancelationOptions::CANCEL_FALLBACK_EVENTS,
"application handled the original non-fallback key "
"or is no longer a foreground target, "
"canceling previously dispatched fallback key");
options.keyCode = fallbackKeyCode;
synthesizeCancelationEventsForConnectionLocked(connection, options);
}
connection->inputState.removeFallbackKey(originalKeyCode);
}
} else {
// If the application did not handle a non-fallback key, first check
// that we are in a good state to perform unhandled key event processing
// Then ask the policy what to do with it.
bool initialDown = keyEntry->action == AKEY_EVENT_ACTION_DOWN
&& keyEntry->repeatCount == 0;
if (fallbackKeyCode == -1 && !initialDown) {
Be more precise about tracking fallback keys. Only initiate fallback key handling if the first key down was not handled and there is no other fallback key already in progress. This prevents spurious fallbacks from being generated when applications handle the initial down but not repeated downs or the up. Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
2011-02-22 15:00:50 -08:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
LOGD("Unhandled key event: Skipping unhandled key event processing "
"since this is not an initial down. "
"keyCode=%d, action=%d, repeatCount=%d",
originalKeyCode, keyEntry->action, keyEntry->repeatCount);
Be more precise about tracking fallback keys. Only initiate fallback key handling if the first key down was not handled and there is no other fallback key already in progress. This prevents spurious fallbacks from being generated when applications handle the initial down but not repeated downs or the up. Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
2011-02-22 15:00:50 -08:00
#endif
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
return false;
}
Be more precise about tracking fallback keys. Only initiate fallback key handling if the first key down was not handled and there is no other fallback key already in progress. This prevents spurious fallbacks from being generated when applications handle the initial down but not repeated downs or the up. Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
2011-02-22 15:00:50 -08:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
// Dispatch the unhandled key to the policy.
Be more precise about tracking fallback keys. Only initiate fallback key handling if the first key down was not handled and there is no other fallback key already in progress. This prevents spurious fallbacks from being generated when applications handle the initial down but not repeated downs or the up. Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
2011-02-22 15:00:50 -08:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
LOGD("Unhandled key event: Asking policy to perform fallback action. "
"keyCode=%d, action=%d, repeatCount=%d",
keyEntry->keyCode, keyEntry->action, keyEntry->repeatCount);
Be more precise about tracking fallback keys. Only initiate fallback key handling if the first key down was not handled and there is no other fallback key already in progress. This prevents spurious fallbacks from being generated when applications handle the initial down but not repeated downs or the up. Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
2011-02-22 15:00:50 -08:00
#endif
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
KeyEvent event;
initializeKeyEvent(&event, keyEntry);
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
mLock.unlock();
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
bool fallback = mPolicy->dispatchUnhandledKey(connection->inputWindowHandle,
&event, keyEntry->policyFlags, &event);
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
mLock.lock();
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
if (connection->status != Connection::STATUS_NORMAL) {
connection->inputState.removeFallbackKey(originalKeyCode);
return true; // skip next cycle
}
Fix race condition in fallback key processing. Need to ensure that the channel is still valid before proceeding. Bug: 3271482 Change-Id: Ia6863cbedd9b53cbc5c9c8815e9ea90bef3d2218
2010-12-09 18:10:30 -08:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
LOG_ASSERT(connection->outboundQueue.head == dispatchEntry);
Fix race condition in fallback key processing. Need to ensure that the channel is still valid before proceeding. Bug: 3271482 Change-Id: Ia6863cbedd9b53cbc5c9c8815e9ea90bef3d2218
2010-12-09 18:10:30 -08:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
// Latch the fallback keycode for this key on an initial down.
// The fallback keycode cannot change at any other point in the lifecycle.
if (initialDown) {
if (fallback) {
fallbackKeyCode = event.getKeyCode();
} else {
fallbackKeyCode = AKEYCODE_UNKNOWN;
}
connection->inputState.setFallbackKey(originalKeyCode, fallbackKeyCode);
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
LOG_ASSERT(fallbackKeyCode != -1);
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
// Cancel the fallback key if the policy decides not to send it anymore.
// We will continue to dispatch the key to the policy but we will no
// longer dispatch a fallback key to the application.
if (fallbackKeyCode != AKEYCODE_UNKNOWN
&& (!fallback || fallbackKeyCode != event.getKeyCode())) {
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
if (fallback) {
LOGD("Unhandled key event: Policy requested to send key %d"
"as a fallback for %d, but on the DOWN it had requested "
"to send %d instead. Fallback canceled.",
event.getKeyCode(), originalKeyCode, fallbackKeyCode);
} else {
LOGD("Unhandled key event: Policy did not request fallback for %d,"
"but on the DOWN it had requested to send %d. "
"Fallback canceled.",
originalKeyCode, fallbackKeyCode);
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
#endif
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
CancelationOptions options(CancelationOptions::CANCEL_FALLBACK_EVENTS,
"canceling fallback, policy no longer desires it");
options.keyCode = fallbackKeyCode;
synthesizeCancelationEventsForConnectionLocked(connection, options);
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
fallback = false;
fallbackKeyCode = AKEYCODE_UNKNOWN;
if (keyEntry->action != AKEY_EVENT_ACTION_UP) {
connection->inputState.setFallbackKey(originalKeyCode,
fallbackKeyCode);
}
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
{
String8 msg;
const KeyedVector<int32_t, int32_t>& fallbackKeys =
connection->inputState.getFallbackKeys();
for (size_t i = 0; i < fallbackKeys.size(); i++) {
msg.appendFormat(", %d->%d", fallbackKeys.keyAt(i),
fallbackKeys.valueAt(i));
}
LOGD("Unhandled key event: %d currently tracked fallback keys%s.",
fallbackKeys.size(), msg.string());
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
#endif
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
if (fallback) {
// Restart the dispatch cycle using the fallback key.
keyEntry->eventTime = event.getEventTime();
keyEntry->deviceId = event.getDeviceId();
keyEntry->source = event.getSource();
keyEntry->flags = event.getFlags() | AKEY_EVENT_FLAG_FALLBACK;
keyEntry->keyCode = fallbackKeyCode;
keyEntry->scanCode = event.getScanCode();
keyEntry->metaState = event.getMetaState();
keyEntry->repeatCount = event.getRepeatCount();
keyEntry->downTime = event.getDownTime();
keyEntry->syntheticRepeat = false;
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
Be more precise about tracking fallback keys. Only initiate fallback key handling if the first key down was not handled and there is no other fallback key already in progress. This prevents spurious fallbacks from being generated when applications handle the initial down but not repeated downs or the up. Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
2011-02-22 15:00:50 -08:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
LOGD("Unhandled key event: Dispatching fallback key. "
"originalKeyCode=%d, fallbackKeyCode=%d, fallbackMetaState=%08x",
originalKeyCode, fallbackKeyCode, keyEntry->metaState);
Be more precise about tracking fallback keys. Only initiate fallback key handling if the first key down was not handled and there is no other fallback key already in progress. This prevents spurious fallbacks from being generated when applications handle the initial down but not repeated downs or the up. Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
2011-02-22 15:00:50 -08:00
#endif
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
dispatchEntry->inProgress = false;
startDispatchCycleLocked(now(), connection);
return true; // already started next cycle
} else {
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
LOGD("Unhandled key event: No fallback key.");
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
#endif
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
}
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
2010-11-05 15:02:16 -07:00
}
}
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
return false;
}
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
2010-11-05 15:02:16 -07:00
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
bool InputDispatcher::afterMotionEventLockedInterruptible(const sp<Connection>& connection,
DispatchEntry* dispatchEntry, MotionEntry* motionEntry, bool handled) {
return false;
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
2010-11-05 15:02:16 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
void InputDispatcher::doPokeUserActivityLockedInterruptible(CommandEntry* commandEntry) {
mLock.unlock();
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
mPolicy->pokeUserActivity(commandEntry->eventTime, commandEntry->userActivityEventType);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
mLock.lock();
}
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
2010-11-05 15:02:16 -07:00
void InputDispatcher::initializeKeyEvent(KeyEvent* event, const KeyEntry* entry) {
event->initialize(entry->deviceId, entry->source, entry->action, entry->flags,
entry->keyCode, entry->scanCode, entry->metaState, entry->repeatCount,
entry->downTime, entry->eventTime);
}
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
void InputDispatcher::updateDispatchStatisticsLocked(nsecs_t currentTime, const EventEntry* entry,
int32_t injectionResult, nsecs_t timeSpentWaitingForApplication) {
// TODO Write some statistics about how long we spend waiting.
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
void InputDispatcher::dump(String8& dump) {
Add input system to Watchdog. Bug: 5094994 Change-Id: I153866958efc64ac19bda8b997c1c9f6ad425ec4
2011-08-10 16:25:21 -07:00
AutoMutex _l(mLock);
Minor logging changes to input dispatcher to help with debugging. Added dumpsys reporting to EventHub. Made the formatting a bit clearer. Added 'Locked' suffix to some internal methods of EventHub. Change-Id: Ic449560bcce378f6361895d27c66854e9724abb0
2010-10-01 17:46:21 -07:00
dump.append("Input Dispatcher State:\n");
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
dumpDispatchStateLocked(dump);
Use ViewConfiguration to seed input system configuration. Fix bug where the pointer presentation would be updated on any input reader timeout rather than only when a pointer gesture is in progress. Bug: 4124987 Change-Id: Ie9bba4a0b3228d55e45e65fa2ede5cd6ba887a08
2011-05-26 19:17:02 -07:00
dump.append(INDENT "Configuration:\n");
dump.appendFormat(INDENT2 "MaxEventsPerSecond: %d\n", mConfig.maxEventsPerSecond);
dump.appendFormat(INDENT2 "KeyRepeatDelay: %0.1fms\n", mConfig.keyRepeatDelay * 0.000001f);
dump.appendFormat(INDENT2 "KeyRepeatTimeout: %0.1fms\n", mConfig.keyRepeatTimeout * 0.000001f);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Add input system to Watchdog. Bug: 5094994 Change-Id: I153866958efc64ac19bda8b997c1c9f6ad425ec4
2011-08-10 16:25:21 -07:00
void InputDispatcher::monitor() {
// Acquire and release the lock to ensure that the dispatcher has not deadlocked.
mLock.lock();
mLock.unlock();
}
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
2010-06-15 01:31:58 -07:00
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
// --- InputDispatcher::Queue ---
template <typename T>
uint32_t InputDispatcher::Queue<T>::count() const {
uint32_t result = 0;
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
for (const T* entry = head; entry; entry = entry->next) {
Make input dispatcher only ANR for foreground windows. Redesigned the input dispatcher's ANR timeout mechanism so it is much closer to Froyo's policy. ANR is only ever signalled if the dispatcher is waiting on a window to finish processing its previous event(s) and there is new pending input. In the old code, we tracked the dispatch timeout separately for each input channel. This was somewhat complicated and also resulted in the situation where applications could ANR long after the user had pushed them into the background. Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
2010-09-15 15:18:56 -07:00
result += 1;
}
return result;
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
// --- InputDispatcher::InjectionState ---
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
2010-04-22 18:58:52 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::InjectionState::InjectionState(int32_t injectorPid, int32_t injectorUid) :
refCount(1),
injectorPid(injectorPid), injectorUid(injectorUid),
injectionResult(INPUT_EVENT_INJECTION_PENDING), injectionIsAsync(false),
pendingForegroundDispatches(0) {
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
2010-04-22 18:58:52 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::InjectionState::~InjectionState() {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
void InputDispatcher::InjectionState::release() {
refCount -= 1;
if (refCount == 0) {
delete this;
} else {
LOG_ASSERT(refCount > 0);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
More native input event dispatching. Added ANRs handling. Added event injection. Fixed a NPE ActivityManagerServer writing ANRs to the drop box. Fixed HOME key interception. Fixed trackball reporting. Fixed pointer rotation in landscape mode. Change-Id: I50340f559f22899ab924e220a78119ffc79469b7
2010-06-17 20:52:56 -07:00
}
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
2010-04-22 18:58:52 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
// --- InputDispatcher::EventEntry ---
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
2010-04-22 18:58:52 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::EventEntry::EventEntry(int32_t type, nsecs_t eventTime, uint32_t policyFlags) :
refCount(1), type(type), eventTime(eventTime), policyFlags(policyFlags),
injectionState(NULL), dispatchInProgress(false) {
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
2010-04-22 18:58:52 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::EventEntry::~EventEntry() {
releaseInjectionState();
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
2010-04-22 18:58:52 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
void InputDispatcher::EventEntry::release() {
refCount -= 1;
if (refCount == 0) {
delete this;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
} else {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
LOG_ASSERT(refCount > 0);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
void InputDispatcher::EventEntry::releaseInjectionState() {
if (injectionState) {
injectionState->release();
injectionState = NULL;
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
2010-04-22 18:58:52 -07:00
}
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
// --- InputDispatcher::ConfigurationChangedEntry ---
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
2010-04-22 18:58:52 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::ConfigurationChangedEntry::ConfigurationChangedEntry(nsecs_t eventTime) :
EventEntry(TYPE_CONFIGURATION_CHANGED, eventTime, 0) {
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
2010-04-22 18:58:52 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::ConfigurationChangedEntry::~ConfigurationChangedEntry() {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
Input system bug fixes, particularly for stylus. Bug: 5049148 Finished stylus support, including support for indirect stylus and mouse tools. Added TILT axis. When stylus tilt X/Y is available, it is transformed into an orientation and tilt inclination which is a more convenient representation and a simpler extension to the exiting API. Touch devices now only report touch data using a single input source. Previously touch devices in pointer mode would report both absolute touch pad data and cooked pointer gestures. Now we just pick one. The touch device switches modes as needed when the focused application enables/disables pointer gestures. This change greatly simplifies the code and reduces the load on the input dispatcher. Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE would be zero whenever the stylus was in direct contact. It appears that the correct way to determine whether the stylus is in direct contact (rather than hovering) is by checking for a non-zero reported pressure. Added code to read the initial state of tool buttons and axis values when the input devices are initialized or reset. This fixes problems where the input mapper state might have the wrong initial state. Moved responsibility for cancelling pending inputs (keys down, touches, etc.) to the InputDispatcher by sending it a device reset notification. This frees the InputReader from having to synthesize events during reset, which was cumbersome and somewhat brittle to begin with. Consolidated more of the common accumulator logic from SingleTouchInputMapper and MultiTouchInputMapper into TouchInputMapper. Improved the PointerLocation output. Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
2011-08-18 11:20:58 -07:00
// --- InputDispatcher::DeviceResetEntry ---
InputDispatcher::DeviceResetEntry::DeviceResetEntry(nsecs_t eventTime, int32_t deviceId) :
EventEntry(TYPE_DEVICE_RESET, eventTime, 0),
deviceId(deviceId) {
}
InputDispatcher::DeviceResetEntry::~DeviceResetEntry() {
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
// --- InputDispatcher::KeyEntry ---
InputDispatcher::KeyEntry::KeyEntry(nsecs_t eventTime,
int32_t deviceId, uint32_t source, uint32_t policyFlags, int32_t action,
int32_t flags, int32_t keyCode, int32_t scanCode, int32_t metaState,
int32_t repeatCount, nsecs_t downTime) :
EventEntry(TYPE_KEY, eventTime, policyFlags),
deviceId(deviceId), source(source), action(action), flags(flags),
keyCode(keyCode), scanCode(scanCode), metaState(metaState),
repeatCount(repeatCount), downTime(downTime),
Improve screenshot chord debouncing. Bug: 5011907 Introduce a 150ms delay in handling volume down keys while waiting to see if a power key will follow. Don't trigger the screenshot chord if both volume up and volume down are pressed together. Don't trigger the long-press power menu if volume keys are also pressed. Require the user to press both keys in the chord within the debounce time and continue long-pressing them in order to trigger the screenshot action. Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
2011-10-12 13:57:59 -07:00
syntheticRepeat(false), interceptKeyResult(KeyEntry::INTERCEPT_KEY_RESULT_UNKNOWN),
interceptKeyWakeupTime(0) {
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
2010-04-22 18:58:52 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::KeyEntry::~KeyEntry() {
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
2010-06-15 01:31:58 -07:00
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
void InputDispatcher::KeyEntry::recycle() {
releaseInjectionState();
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
2010-04-22 18:58:52 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
dispatchInProgress = false;
syntheticRepeat = false;
interceptKeyResult = KeyEntry::INTERCEPT_KEY_RESULT_UNKNOWN;
Improve screenshot chord debouncing. Bug: 5011907 Introduce a 150ms delay in handling volume down keys while waiting to see if a power key will follow. Don't trigger the screenshot chord if both volume up and volume down are pressed together. Don't trigger the long-press power menu if volume keys are also pressed. Require the user to press both keys in the chord within the debounce time and continue long-pressing them in order to trigger the screenshot action. Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
2011-10-12 13:57:59 -07:00
interceptKeyWakeupTime = 0;
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
2010-04-22 18:58:52 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
// --- InputDispatcher::MotionSample ---
InputDispatcher::MotionSample::MotionSample(nsecs_t eventTime,
const PointerCoords* pointerCoords, uint32_t pointerCount) :
next(NULL), eventTime(eventTime), eventTimeBeforeCoalescing(eventTime) {
for (uint32_t i = 0; i < pointerCount; i++) {
this->pointerCoords[i].copyFrom(pointerCoords[i]);
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
// --- InputDispatcher::MotionEntry ---
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::MotionEntry::MotionEntry(nsecs_t eventTime,
int32_t deviceId, uint32_t source, uint32_t policyFlags, int32_t action, int32_t flags,
int32_t metaState, int32_t buttonState,
int32_t edgeFlags, float xPrecision, float yPrecision,
nsecs_t downTime, uint32_t pointerCount,
const PointerProperties* pointerProperties, const PointerCoords* pointerCoords) :
EventEntry(TYPE_MOTION, eventTime, policyFlags),
deviceId(deviceId), source(source), action(action), flags(flags),
metaState(metaState), buttonState(buttonState), edgeFlags(edgeFlags),
xPrecision(xPrecision), yPrecision(yPrecision),
downTime(downTime), pointerCount(pointerCount),
firstSample(eventTime, pointerCoords, pointerCount),
lastSample(&firstSample) {
for (uint32_t i = 0; i < pointerCount; i++) {
this->pointerProperties[i].copyFrom(pointerProperties[i]);
}
}
InputDispatcher::MotionEntry::~MotionEntry() {
for (MotionSample* sample = firstSample.next; sample != NULL; ) {
MotionSample* next = sample->next;
delete sample;
sample = next;
}
}
Add support for throttling motion events. Change-Id: I24b3a17753e91ecda60a60fe5cd2e6b3260e033d
2010-08-18 15:51:08 -07:00
uint32_t InputDispatcher::MotionEntry::countSamples() const {
uint32_t count = 1;
for (MotionSample* sample = firstSample.next; sample != NULL; sample = sample->next) {
count += 1;
}
return count;
}
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
bool InputDispatcher::MotionEntry::canAppendSamples(int32_t action, uint32_t pointerCount,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
const PointerProperties* pointerProperties) const {
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
if (this->action != action
|| this->pointerCount != pointerCount
|| this->isInjected()) {
return false;
}
for (uint32_t i = 0; i < pointerCount; i++) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
if (this->pointerProperties[i] != pointerProperties[i]) {
Coalesce input events that arrive faster than 333Hz. Some drivers report individual finger updates one at a time instead of all at once. When 10 fingers are down, this can cause the framework to have to handle 10 times as many events each with 10 times as much data. Applications like PointerLocation would get significantly bogged down by all of the redundant samples. This change coalesces samples that are closely spaced in time, before they are dispatched, as part of the motion event batching protocol. Increased the size of the InputChannel shared memory buffer so that applications can catch up faster if they accumulate a backlog of samples. Added logging code to help measure input dispatch and drawing latency issues in the view hierarchy. See ViewDebug.DEBUG_LATENCY. Change-Id: Ia5898f781f19901d2225c529a910c32bdf4f504f
2011-04-07 11:38:09 -07:00
return false;
}
}
return true;
}
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
void InputDispatcher::MotionEntry::appendSample(
nsecs_t eventTime, const PointerCoords* pointerCoords) {
MotionSample* sample = new MotionSample(eventTime, pointerCoords, pointerCount);
lastSample->next = sample;
lastSample = sample;
}
// --- InputDispatcher::DispatchEntry ---
InputDispatcher::DispatchEntry::DispatchEntry(EventEntry* eventEntry,
int32_t targetFlags, float xOffset, float yOffset, float scaleFactor) :
eventEntry(eventEntry), targetFlags(targetFlags),
xOffset(xOffset), yOffset(yOffset), scaleFactor(scaleFactor),
inProgress(false),
resolvedAction(0), resolvedFlags(0),
headMotionSample(NULL), tailMotionSample(NULL) {
eventEntry->refCount += 1;
}
InputDispatcher::DispatchEntry::~DispatchEntry() {
eventEntry->release();
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
// --- InputDispatcher::InputState ---
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
InputDispatcher::InputState::InputState() {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
InputDispatcher::InputState::~InputState() {
}
bool InputDispatcher::InputState::isNeutral() const {
return mKeyMementos.isEmpty() && mMotionMementos.isEmpty();
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
bool InputDispatcher::InputState::isHovering(int32_t deviceId, uint32_t source) const {
for (size_t i = 0; i < mMotionMementos.size(); i++) {
const MotionMemento& memento = mMotionMementos.itemAt(i);
if (memento.deviceId == deviceId
&& memento.source == source
&& memento.hovering) {
return true;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
return false;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
bool InputDispatcher::InputState::trackKey(const KeyEntry* entry,
int32_t action, int32_t flags) {
switch (action) {
case AKEY_EVENT_ACTION_UP: {
if (entry->flags & AKEY_EVENT_FLAG_FALLBACK) {
for (size_t i = 0; i < mFallbackKeys.size(); ) {
if (mFallbackKeys.valueAt(i) == entry->keyCode) {
mFallbackKeys.removeItemsAt(i);
} else {
i += 1;
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
}
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
ssize_t index = findKeyMemento(entry);
if (index >= 0) {
mKeyMementos.removeAt(index);
return true;
}
Fix system hotkey handling. Fixed a problem where the key up for the ALT or META key was not delivered to the task switcher dialog because it was deemed to be inconsistent with the window's observed state. Consequently the dialog would not be dismissed when the key was released. Moved global hotkey handling for META+* shortcuts and ALT/META-TAB into the window manager policy's interceptKeyBeforeDispatching method. This change prevents applications from hijacking these keys. The original idea was that these shortcuts would be handled only if the application did not handle them itself. That way certain applications, such as remote desktop tools, could deliberately override some of these less important system shortcuts. Unfortunately, that does make the behavior inconsistent across applications. What's more, bugs in the onKeyDown handler of applications can cause the shortcuts to not work at all, for no good reason. Perhaps we can add an opt-in feature later to enable specific applications to repurpose these keys when it makes sense. Bug: 5720358 Change-Id: I22bf17606d12dbea6549c60d20763e6608576cf7
2011-12-07 16:36:01 -08:00
/* FIXME: We can't just drop the key up event because that prevents creating
* popup windows that are automatically shown when a key is held and then
* dismissed when the key is released. The problem is that the popup will
* not have received the original key down, so the key up will be considered
* to be inconsistent with its observed state. We could perhaps handle this
* by synthesizing a key down but that will cause other problems.
*
* So for now, allow inconsistent key up events to be dispatched.
*
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
LOGD("Dropping inconsistent key up event: deviceId=%d, source=%08x, "
"keyCode=%d, scanCode=%d",
entry->deviceId, entry->source, entry->keyCode, entry->scanCode);
#endif
return false;
Fix system hotkey handling. Fixed a problem where the key up for the ALT or META key was not delivered to the task switcher dialog because it was deemed to be inconsistent with the window's observed state. Consequently the dialog would not be dismissed when the key was released. Moved global hotkey handling for META+* shortcuts and ALT/META-TAB into the window manager policy's interceptKeyBeforeDispatching method. This change prevents applications from hijacking these keys. The original idea was that these shortcuts would be handled only if the application did not handle them itself. That way certain applications, such as remote desktop tools, could deliberately override some of these less important system shortcuts. Unfortunately, that does make the behavior inconsistent across applications. What's more, bugs in the onKeyDown handler of applications can cause the shortcuts to not work at all, for no good reason. Perhaps we can add an opt-in feature later to enable specific applications to repurpose these keys when it makes sense. Bug: 5720358 Change-Id: I22bf17606d12dbea6549c60d20763e6608576cf7
2011-12-07 16:36:01 -08:00
*/
return true;
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
case AKEY_EVENT_ACTION_DOWN: {
ssize_t index = findKeyMemento(entry);
if (index >= 0) {
mKeyMementos.removeAt(index);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
addKeyMemento(entry, flags);
return true;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
default:
return true;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
bool InputDispatcher::InputState::trackMotion(const MotionEntry* entry,
int32_t action, int32_t flags) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
int32_t actionMasked = action & AMOTION_EVENT_ACTION_MASK;
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
switch (actionMasked) {
case AMOTION_EVENT_ACTION_UP:
case AMOTION_EVENT_ACTION_CANCEL: {
ssize_t index = findMotionMemento(entry, false /*hovering*/);
if (index >= 0) {
mMotionMementos.removeAt(index);
return true;
}
#if DEBUG_OUTBOUND_EVENT_DETAILS
LOGD("Dropping inconsistent motion up or cancel event: deviceId=%d, source=%08x, "
"actionMasked=%d",
entry->deviceId, entry->source, actionMasked);
#endif
return false;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
case AMOTION_EVENT_ACTION_DOWN: {
ssize_t index = findMotionMemento(entry, false /*hovering*/);
if (index >= 0) {
mMotionMementos.removeAt(index);
}
addMotionMemento(entry, flags, false /*hovering*/);
return true;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
case AMOTION_EVENT_ACTION_POINTER_UP:
case AMOTION_EVENT_ACTION_POINTER_DOWN:
case AMOTION_EVENT_ACTION_MOVE: {
ssize_t index = findMotionMemento(entry, false /*hovering*/);
if (index >= 0) {
MotionMemento& memento = mMotionMementos.editItemAt(index);
memento.setPointers(entry);
return true;
}
Fix joystick and trackpad regression. Change-Id: I33b6756f95a6b0725ffa210f341da3c98426491b
2011-06-29 21:19:05 -07:00
if (actionMasked == AMOTION_EVENT_ACTION_MOVE
&& (entry->source & (AINPUT_SOURCE_CLASS_JOYSTICK
| AINPUT_SOURCE_CLASS_NAVIGATION))) {
// Joysticks and trackballs can send MOVE events without corresponding DOWN or UP.
return true;
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
LOGD("Dropping inconsistent motion pointer up/down or move event: "
"deviceId=%d, source=%08x, actionMasked=%d",
entry->deviceId, entry->source, actionMasked);
#endif
return false;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
case AMOTION_EVENT_ACTION_HOVER_EXIT: {
ssize_t index = findMotionMemento(entry, true /*hovering*/);
if (index >= 0) {
mMotionMementos.removeAt(index);
return true;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
#if DEBUG_OUTBOUND_EVENT_DETAILS
LOGD("Dropping inconsistent motion hover exit event: deviceId=%d, source=%08x",
entry->deviceId, entry->source);
#endif
return false;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
case AMOTION_EVENT_ACTION_HOVER_ENTER:
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
case AMOTION_EVENT_ACTION_HOVER_MOVE: {
ssize_t index = findMotionMemento(entry, true /*hovering*/);
if (index >= 0) {
mMotionMementos.removeAt(index);
}
addMotionMemento(entry, flags, true /*hovering*/);
return true;
}
default:
return true;
}
}
ssize_t InputDispatcher::InputState::findKeyMemento(const KeyEntry* entry) const {
for (size_t i = 0; i < mKeyMementos.size(); i++) {
const KeyMemento& memento = mKeyMementos.itemAt(i);
if (memento.deviceId == entry->deviceId
&& memento.source == entry->source
&& memento.keyCode == entry->keyCode
&& memento.scanCode == entry->scanCode) {
return i;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
return -1;
}
ssize_t InputDispatcher::InputState::findMotionMemento(const MotionEntry* entry,
bool hovering) const {
for (size_t i = 0; i < mMotionMementos.size(); i++) {
const MotionMemento& memento = mMotionMementos.itemAt(i);
if (memento.deviceId == entry->deviceId
&& memento.source == entry->source
&& memento.hovering == hovering) {
return i;
}
}
return -1;
}
void InputDispatcher::InputState::addKeyMemento(const KeyEntry* entry, int32_t flags) {
mKeyMementos.push();
KeyMemento& memento = mKeyMementos.editTop();
memento.deviceId = entry->deviceId;
memento.source = entry->source;
memento.keyCode = entry->keyCode;
memento.scanCode = entry->scanCode;
memento.flags = flags;
memento.downTime = entry->downTime;
}
void InputDispatcher::InputState::addMotionMemento(const MotionEntry* entry,
int32_t flags, bool hovering) {
mMotionMementos.push();
MotionMemento& memento = mMotionMementos.editTop();
memento.deviceId = entry->deviceId;
memento.source = entry->source;
memento.flags = flags;
memento.xPrecision = entry->xPrecision;
memento.yPrecision = entry->yPrecision;
memento.downTime = entry->downTime;
memento.setPointers(entry);
memento.hovering = hovering;
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
void InputDispatcher::InputState::MotionMemento::setPointers(const MotionEntry* entry) {
pointerCount = entry->pointerCount;
for (uint32_t i = 0; i < entry->pointerCount; i++) {
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
pointerProperties[i].copyFrom(entry->pointerProperties[i]);
Use touch pad gestures to manipulate the pointer. 1. Single finger tap performs a click. 2. Single finger movement moves the pointer (hovers). 3. Button press plus movement performs click or drag. While dragging, the pointer follows the finger that is moving fastest. This is important if there are additional fingers down on the touch pad for the purpose of applying force to an integrated button underneath. 4. Two fingers near each other moving in the same direction are coalesced as a swipe gesture under the pointer. 5. Two or more fingers moving in arbitrary directions are transformed into touches in the vicinity of the pointer. This makes scale/zoom and rotate gestures possible. Added a native VelocityTracker implementation to enable intelligent switching of the active pointer during drags. Change-Id: I5ada57e7f2bdb9b0a791843eb354a8c706b365dc
2011-03-09 17:39:48 -08:00
pointerCoords[i].copyFrom(entry->lastSample->pointerCoords[i]);
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
void InputDispatcher::InputState::synthesizeCancelationEvents(nsecs_t currentTime,
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
Vector<EventEntry*>& outEvents, const CancelationOptions& options) {
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
for (size_t i = 0; i < mKeyMementos.size(); i++) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
const KeyMemento& memento = mKeyMementos.itemAt(i);
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
if (shouldCancelKey(memento, options)) {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
outEvents.push(new KeyEntry(currentTime,
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
memento.deviceId, memento.source, 0,
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
AKEY_EVENT_ACTION_UP, memento.flags | AKEY_EVENT_FLAG_CANCELED,
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
memento.keyCode, memento.scanCode, 0, 0, memento.downTime));
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
for (size_t i = 0; i < mMotionMementos.size(); i++) {
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
const MotionMemento& memento = mMotionMementos.itemAt(i);
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
if (shouldCancelMotion(memento, options)) {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
outEvents.push(new MotionEntry(currentTime,
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
memento.deviceId, memento.source, 0,
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
memento.hovering
? AMOTION_EVENT_ACTION_HOVER_EXIT
: AMOTION_EVENT_ACTION_CANCEL,
Improve input event consistency invariants. Fixed some issues where inconsistent streams of events could be generated by the dispatcher, particularly when switching from hovering with one device to hovering with another. Fixed a bug where the touch pad would fail to generate a new HOVER_MOVE following a tap event. As a result, the hover event stream would not resume until the user touched the touch pad again. Change-Id: I444dce84641fb12e56a0af84c931520771d6c493
2011-06-28 20:08:48 -07:00
memento.flags, 0, 0, 0,
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
memento.xPrecision, memento.yPrecision, memento.downTime,
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
2011-05-06 18:20:01 -07:00
memento.pointerCount, memento.pointerProperties, memento.pointerCoords));
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
}
void InputDispatcher::InputState::clear() {
mKeyMementos.clear();
mMotionMementos.clear();
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
mFallbackKeys.clear();
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Track input state when transferring touch focus. Copies the input state to the destination window and sends synthesic cancelation events to the source window. Change-Id: Ia75820b0d756ed5d6cd22dce7830251ac85141ed
2010-10-11 18:32:20 -07:00
void InputDispatcher::InputState::copyPointerStateTo(InputState& other) const {
for (size_t i = 0; i < mMotionMementos.size(); i++) {
const MotionMemento& memento = mMotionMementos.itemAt(i);
if (memento.source & AINPUT_SOURCE_CLASS_POINTER) {
for (size_t j = 0; j < other.mMotionMementos.size(); ) {
const MotionMemento& otherMemento = other.mMotionMementos.itemAt(j);
if (memento.deviceId == otherMemento.deviceId
&& memento.source == otherMemento.source) {
other.mMotionMementos.removeAt(j);
} else {
j += 1;
}
}
other.mMotionMementos.push(memento);
}
}
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
int32_t InputDispatcher::InputState::getFallbackKey(int32_t originalKeyCode) {
ssize_t index = mFallbackKeys.indexOfKey(originalKeyCode);
return index >= 0 ? mFallbackKeys.valueAt(index) : -1;
}
void InputDispatcher::InputState::setFallbackKey(int32_t originalKeyCode,
int32_t fallbackKeyCode) {
ssize_t index = mFallbackKeys.indexOfKey(originalKeyCode);
if (index >= 0) {
mFallbackKeys.replaceValueAt(index, fallbackKeyCode);
} else {
mFallbackKeys.add(originalKeyCode, fallbackKeyCode);
}
}
void InputDispatcher::InputState::removeFallbackKey(int32_t originalKeyCode) {
mFallbackKeys.removeItem(originalKeyCode);
}
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
bool InputDispatcher::InputState::shouldCancelKey(const KeyMemento& memento,
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
const CancelationOptions& options) {
if (options.keyCode != -1 && memento.keyCode != options.keyCode) {
return false;
}
Input system bug fixes, particularly for stylus. Bug: 5049148 Finished stylus support, including support for indirect stylus and mouse tools. Added TILT axis. When stylus tilt X/Y is available, it is transformed into an orientation and tilt inclination which is a more convenient representation and a simpler extension to the exiting API. Touch devices now only report touch data using a single input source. Previously touch devices in pointer mode would report both absolute touch pad data and cooked pointer gestures. Now we just pick one. The touch device switches modes as needed when the focused application enables/disables pointer gestures. This change greatly simplifies the code and reduces the load on the input dispatcher. Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE would be zero whenever the stylus was in direct contact. It appears that the correct way to determine whether the stylus is in direct contact (rather than hovering) is by checking for a non-zero reported pressure. Added code to read the initial state of tool buttons and axis values when the input devices are initialized or reset. This fixes problems where the input mapper state might have the wrong initial state. Moved responsibility for cancelling pending inputs (keys down, touches, etc.) to the InputDispatcher by sending it a device reset notification. This frees the InputReader from having to synthesize events during reset, which was cumbersome and somewhat brittle to begin with. Consolidated more of the common accumulator logic from SingleTouchInputMapper and MultiTouchInputMapper into TouchInputMapper. Improved the PointerLocation output. Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
2011-08-18 11:20:58 -07:00
if (options.deviceId != -1 && memento.deviceId != options.deviceId) {
return false;
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
switch (options.mode) {
case CancelationOptions::CANCEL_ALL_EVENTS:
case CancelationOptions::CANCEL_NON_POINTER_EVENTS:
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
return true;
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
case CancelationOptions::CANCEL_FALLBACK_EVENTS:
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
return memento.flags & AKEY_EVENT_FLAG_FALLBACK;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
default:
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
return false;
}
}
bool InputDispatcher::InputState::shouldCancelMotion(const MotionMemento& memento,
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
const CancelationOptions& options) {
Input system bug fixes, particularly for stylus. Bug: 5049148 Finished stylus support, including support for indirect stylus and mouse tools. Added TILT axis. When stylus tilt X/Y is available, it is transformed into an orientation and tilt inclination which is a more convenient representation and a simpler extension to the exiting API. Touch devices now only report touch data using a single input source. Previously touch devices in pointer mode would report both absolute touch pad data and cooked pointer gestures. Now we just pick one. The touch device switches modes as needed when the focused application enables/disables pointer gestures. This change greatly simplifies the code and reduces the load on the input dispatcher. Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE would be zero whenever the stylus was in direct contact. It appears that the correct way to determine whether the stylus is in direct contact (rather than hovering) is by checking for a non-zero reported pressure. Added code to read the initial state of tool buttons and axis values when the input devices are initialized or reset. This fixes problems where the input mapper state might have the wrong initial state. Moved responsibility for cancelling pending inputs (keys down, touches, etc.) to the InputDispatcher by sending it a device reset notification. This frees the InputReader from having to synthesize events during reset, which was cumbersome and somewhat brittle to begin with. Consolidated more of the common accumulator logic from SingleTouchInputMapper and MultiTouchInputMapper into TouchInputMapper. Improved the PointerLocation output. Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
2011-08-18 11:20:58 -07:00
if (options.deviceId != -1 && memento.deviceId != options.deviceId) {
return false;
}
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
switch (options.mode) {
case CancelationOptions::CANCEL_ALL_EVENTS:
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
return true;
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
case CancelationOptions::CANCEL_POINTER_EVENTS:
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
return memento.source & AINPUT_SOURCE_CLASS_POINTER;
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
case CancelationOptions::CANCEL_NON_POINTER_EVENTS:
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
2010-12-06 17:13:33 -08:00
return !(memento.source & AINPUT_SOURCE_CLASS_POINTER);
default:
return false;
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
2010-10-08 22:31:17 -07:00
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
}
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
2010-04-22 18:58:52 -07:00
// --- InputDispatcher::Connection ---
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
InputDispatcher::Connection::Connection(const sp<InputChannel>& inputChannel,
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
2011-08-30 20:34:48 -07:00
const sp<InputWindowHandle>& inputWindowHandle, bool monitor) :
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
status(STATUS_NORMAL), inputChannel(inputChannel), inputWindowHandle(inputWindowHandle),
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
2011-08-30 20:34:48 -07:00
monitor(monitor),
Prevent events from getting backlogged. This change implements two heuristics. 1. When events are older than 10 seconds, they are dropped. 2. If the application is currently busy processing an event and the user touches a window belonging to a different application then we drop the currently queued events so the other application can start processing the gesture immediately. Note that the system takes care of synthesizing cancelation events automatically for any events that it drops. Added some new handle types to allow the native dispatcher to indirectly refer to the WindowManager's window state and app window token. This was done to enable the dispatcher to identify the application to which each window belongs but it also eliminates some lookup tables and linear searches through the window list on each key press. Bug: 3224911 Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
2011-01-10 11:17:36 -08:00
inputPublisher(inputChannel),
Support chorded fallback keys. Also be more careful about canceling fallback keys during focus transitions, when the application handles the key, or when the policy decides to do something different. Fixed a crash due to JNI CallObjectMethod returning an undefined value (not null) when an exception is thrown. Fixed a crash due to the policy trying to create a Dialog for recent apps on the dispatcher thread. It should happen on the policy's Looper instead. Bug: 4187302 Change-Id: I659a3fd1bd2325ed36d965f9beb75dacb89790c9
2011-03-29 15:11:34 -07:00
lastEventTime(LONG_LONG_MAX), lastDispatchTime(LONG_LONG_MAX) {
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
2010-04-22 18:58:52 -07:00
}
InputDispatcher::Connection::~Connection() {
}
status_t InputDispatcher::Connection::initialize() {
return inputPublisher.initialize();
}
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
2010-06-15 01:31:58 -07:00
const char* InputDispatcher::Connection::getStatusLabel() const {
switch (status) {
case STATUS_NORMAL:
return "NORMAL";
case STATUS_BROKEN:
return "BROKEN";
case STATUS_ZOMBIE:
return "ZOMBIE";
default:
return "UNKNOWN";
}
}
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
2010-04-22 18:58:52 -07:00
InputDispatcher::DispatchEntry* InputDispatcher::Connection::findQueuedDispatchEntryForEvent(
const EventEntry* eventEntry) const {
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
for (DispatchEntry* dispatchEntry = outboundQueue.tail; dispatchEntry;
dispatchEntry = dispatchEntry->prev) {
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
2010-04-22 18:58:52 -07:00
if (dispatchEntry->eventEntry == eventEntry) {
return dispatchEntry;
}
}
return NULL;
}
Input dispatcher ANR handling enhancements. This change is essentially a rewrite of the main input dispatcher loop with the target identification folded in. Since the input dispatcher now has all of the window state, it can make better decisions about when to ANR. Added a .5 second deadline for processing app switch keys. This behavior predates Gingerbread but had not previously been ported. Fixed some timing inaccuracies in the ANR accounting that could cause applications to ANR sooner than they should have. Added a mechanism for tracking key and motion events that have been dispatched to a window so that appropriate cancelation events can be synthesized when recovering from ANR. This change helps to keep applications in sync so they don't end up with stuck buttons upon recovery from ANRs. Added more comments to describe the tricky parts of PollLoop. Change-Id: I13dffca27acb436fc383980db536abc4d8b9e6f1
2010-09-08 11:49:43 -07:00
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
2010-06-15 01:31:58 -07:00
// --- InputDispatcher::CommandEntry ---
Remove unimplemented memory pool. dlmalloc does such a great job that we don't need a pool anyways. Change-Id: I105b28c4a5c491543959190c7c0a9de75a5b8052
2011-07-20 15:19:50 -07:00
InputDispatcher::CommandEntry::CommandEntry(Command command) :
command(command), eventTime(0), keyEntry(NULL), userActivityEventType(0), handled(false) {
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
2010-06-15 01:31:58 -07:00
}
InputDispatcher::CommandEntry::~CommandEntry() {
}
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
2010-04-22 18:58:52 -07:00
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
// --- InputDispatcher::TouchState ---
InputDispatcher::TouchState::TouchState() :
Fix crashes caused by some input devices. The touch screen sometimes reports more than 10 pointers even though that's all we asked for. When this happens, we start dropping events with more than 10 pointers. This confuses applications and causes them to crash. Raised the limit to 16 pointers. Bug: 3331247 The default behavior was to identify all touch devices as touch screens. External devices that are plugged in are more likely to be touch pads not attached to a screen. Changed the default to be a touch pad and renamed some internal constants to avoid confusion. A certain mouse happens to also behave like a touch pad. That caused problems because we would see multiple concurrent traces of motion events coming from the same input device so we would batch them up. Added code to ensure that we don't batch events unless they come from the same *source* in addition to coming from the same *device*. Due to batching or misbehaving drivers, it's possible for the set of pointer ids to be different from what we expect when it comes time to split motion events across windows. As a result, we can generate motion events with 0 pointers. When we try to deliver those events, we cause an error in the InputTransport so we tear down the InputChannel and kill the application. Added code to check out assumption about pointer ids and drop the event gracefully instead. Patched up the tests to take into account the change in default behavior for identifying touch screens and touch pads. Change-Id: Ic364bd4cb4cc6335d4a1213a26d6bdadc7e33505
2011-01-25 16:02:22 -08:00
down(false), split(false), deviceId(-1), source(0) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
InputDispatcher::TouchState::~TouchState() {
}
void InputDispatcher::TouchState::reset() {
down = false;
split = false;
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
deviceId = -1;
Fix crashes caused by some input devices. The touch screen sometimes reports more than 10 pointers even though that's all we asked for. When this happens, we start dropping events with more than 10 pointers. This confuses applications and causes them to crash. Raised the limit to 16 pointers. Bug: 3331247 The default behavior was to identify all touch devices as touch screens. External devices that are plugged in are more likely to be touch pads not attached to a screen. Changed the default to be a touch pad and renamed some internal constants to avoid confusion. A certain mouse happens to also behave like a touch pad. That caused problems because we would see multiple concurrent traces of motion events coming from the same input device so we would batch them up. Added code to ensure that we don't batch events unless they come from the same *source* in addition to coming from the same *device*. Due to batching or misbehaving drivers, it's possible for the set of pointer ids to be different from what we expect when it comes time to split motion events across windows. As a result, we can generate motion events with 0 pointers. When we try to deliver those events, we cause an error in the InputTransport so we tear down the InputChannel and kill the application. Added code to check out assumption about pointer ids and drop the event gracefully instead. Patched up the tests to take into account the change in default behavior for identifying touch screens and touch pads. Change-Id: Ic364bd4cb4cc6335d4a1213a26d6bdadc7e33505
2011-01-25 16:02:22 -08:00
source = 0;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
windows.clear();
}
void InputDispatcher::TouchState::copyFrom(const TouchState& other) {
down = other.down;
split = other.split;
Only allow touch events from one device at a time. Reject movements from other devices when one device is already down. This fixes jittery behavior when the user moves the mouse and touches the screen at the same time. Change-Id: I99151c8f2596a3139720f776bcbc559d4b314878
2011-01-04 19:41:59 -08:00
deviceId = other.deviceId;
Fix crashes caused by some input devices. The touch screen sometimes reports more than 10 pointers even though that's all we asked for. When this happens, we start dropping events with more than 10 pointers. This confuses applications and causes them to crash. Raised the limit to 16 pointers. Bug: 3331247 The default behavior was to identify all touch devices as touch screens. External devices that are plugged in are more likely to be touch pads not attached to a screen. Changed the default to be a touch pad and renamed some internal constants to avoid confusion. A certain mouse happens to also behave like a touch pad. That caused problems because we would see multiple concurrent traces of motion events coming from the same input device so we would batch them up. Added code to ensure that we don't batch events unless they come from the same *source* in addition to coming from the same *device*. Due to batching or misbehaving drivers, it's possible for the set of pointer ids to be different from what we expect when it comes time to split motion events across windows. As a result, we can generate motion events with 0 pointers. When we try to deliver those events, we cause an error in the InputTransport so we tear down the InputChannel and kill the application. Added code to check out assumption about pointer ids and drop the event gracefully instead. Patched up the tests to take into account the change in default behavior for identifying touch screens and touch pads. Change-Id: Ic364bd4cb4cc6335d4a1213a26d6bdadc7e33505
2011-01-25 16:02:22 -08:00
source = other.source;
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
windows = other.windows;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
void InputDispatcher::TouchState::addOrUpdateWindow(const sp<InputWindowHandle>& windowHandle,
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
int32_t targetFlags, BitSet32 pointerIds) {
if (targetFlags & InputTarget::FLAG_SPLIT) {
split = true;
}
for (size_t i = 0; i < windows.size(); i++) {
TouchedWindow& touchedWindow = windows.editItemAt(i);
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
if (touchedWindow.windowHandle == windowHandle) {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
touchedWindow.targetFlags |= targetFlags;
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
if (targetFlags & InputTarget::FLAG_DISPATCH_AS_SLIPPERY_EXIT) {
touchedWindow.targetFlags &= ~InputTarget::FLAG_DISPATCH_AS_IS;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
touchedWindow.pointerIds.value |= pointerIds.value;
return;
}
}
windows.push();
TouchedWindow& touchedWindow = windows.editTop();
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
touchedWindow.windowHandle = windowHandle;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
touchedWindow.targetFlags = targetFlags;
touchedWindow.pointerIds = pointerIds;
}
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
void InputDispatcher::TouchState::filterNonAsIsTouchWindows() {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
for (size_t i = 0 ; i < windows.size(); ) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
TouchedWindow& window = windows.editItemAt(i);
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
if (window.targetFlags & (InputTarget::FLAG_DISPATCH_AS_IS
| InputTarget::FLAG_DISPATCH_AS_SLIPPERY_ENTER)) {
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
window.targetFlags &= ~InputTarget::FLAG_DISPATCH_MASK;
window.targetFlags |= InputTarget::FLAG_DISPATCH_AS_IS;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
i += 1;
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
2011-03-07 16:56:21 -08:00
} else {
windows.removeAt(i);
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
}
}
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
sp<InputWindowHandle> InputDispatcher::TouchState::getFirstForegroundWindowHandle() const {
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
for (size_t i = 0; i < windows.size(); i++) {
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
const TouchedWindow& window = windows.itemAt(i);
if (window.targetFlags & InputTarget::FLAG_FOREGROUND) {
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
2011-07-13 22:51:29 -07:00
return window.windowHandle;
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
}
}
return NULL;
}
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
bool InputDispatcher::TouchState::isSlippery() const {
// Must have exactly one foreground window.
bool haveSlipperyForegroundWindow = false;
for (size_t i = 0; i < windows.size(); i++) {
const TouchedWindow& window = windows.itemAt(i);
if (window.targetFlags & InputTarget::FLAG_FOREGROUND) {
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
2011-08-30 20:34:48 -07:00
if (haveSlipperyForegroundWindow
|| !(window.windowHandle->getInfo()->layoutParamsFlags
& InputWindowInfo::FLAG_SLIPPERY)) {
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
2011-06-08 15:37:10 -07:00
return false;
}
haveSlipperyForegroundWindow = true;
}
}
return haveSlipperyForegroundWindow;
}
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
2010-09-26 22:20:12 -07:00
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
2010-04-22 18:58:52 -07:00
// --- InputDispatcherThread ---
InputDispatcherThread::InputDispatcherThread(const sp<InputDispatcherInterface>& dispatcher) :
Thread(/*canCallJava*/ true), mDispatcher(dispatcher) {
}
InputDispatcherThread::~InputDispatcherThread() {
}
bool InputDispatcherThread::threadLoop() {
mDispatcher->dispatchOnce();
return true;
}
} // namespace android
Reference in New Issue Copy Permalink