Filters input events before they are dispatched to the system.
At most one input filter can be installed by calling
{@link WindowManagerService#setInputFilter}. When an input filter is installed, the
system's behavior changes as follows:
- Input events are first delivered to the {@link WindowManagerPolicy}
interception methods before queuing as usual. This critical step takes care of managing
the power state of the device and handling wake keys.
- Input events are then asynchronously delivered to the input filter's
{@link #onInputEvent(InputEvent)} method instead of being enqueued for dispatch to
applications as usual. The input filter only receives input events that were
generated by an input device; the input filter will not receive input events that were
injected into the system by other means, such as by instrumentation.
- The input filter processes and optionally transforms the stream of events. For example,
it may transform a sequence of motion events representing an accessibility gesture into
a different sequence of motion events, key presses or other system-level interactions.
The input filter can send events to be dispatched by calling
{@link #sendInputEvent(InputEvent)} and passing appropriate policy flags for the
input event.
The importance of input event consistency
The input filter mechanism is very low-level. At a minimum, it needs to ensure that it
sends an internally consistent stream of input events to the dispatcher. There are
very important invariants to be maintained.
For example, if a key down is sent, a corresponding key up should also be sent eventually.
Likewise, for touch events, each pointer must individually go down with
{@link MotionEvent#ACTION_DOWN} or {@link MotionEvent#ACTION_POINTER_DOWN} and then
individually go up with {@link MotionEvent#ACTION_POINTER_UP} or {@link MotionEvent#ACTION_UP}
and the sequence of pointer ids used must be consistent throughout the gesture.
Sometimes a filter may wish to cancel a previously dispatched key or motion. It should
use {@link KeyEvent#FLAG_CANCELED} or {@link MotionEvent#ACTION_CANCEL} accordingly.
The input filter must take into account the fact that the input events coming from different
devices or even different sources all consist of distinct streams of input.
Use {@link InputEvent#getDeviceId()} and {@link InputEvent#getSource()} to identify
the source of the event and its semantics. There may be multiple sources of keys,
touches and other input: they must be kept separate.
Policy flags
Input events received from the dispatcher and sent to the dispatcher have policy flags
associated with them. Policy flags control some functions of the dispatcher.
The early policy interception decides whether an input event should be delivered
to applications or dropped. The policy indicates its decision by setting the
{@link WindowManagerPolicy#FLAG_PASS_TO_USER} policy flag. The input filter may
sometimes receive events that do not have this flag set. It should take note of
the fact that the policy intends to drop the event, clean up its state, and
then send appropriate cancellation events to the dispatcher if needed.
For example, suppose the input filter is processing a gesture and one of the touch events
it receives does not have the {@link WindowManagerPolicy#FLAG_PASS_TO_USER} flag set.
The input filter should clear its internal state about the gesture and then send key or
motion events to the dispatcher to cancel any keys or pointers that are down.
Corollary: Events that get sent to the dispatcher should usually include the
{@link WindowManagerPolicy#FLAG_PASS_TO_USER} flag. Otherwise, they will be dropped!
It may be prudent to disable automatic key repeating for synthetic key events
by setting the {@link WindowManagerPolicy#FLAG_DISABLE_KEY_REPEAT} policy flag.
|