History log of /frameworks/base/core/jni/android_view_KeyEvent.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
1f2451007c660091b7b090c1ea332f9044515d2d 19-Nov-2010 Jeff Brown <jeffbrown@google.com> 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
/frameworks/base/core/jni/android_view_KeyEvent.h
c5ed5910c9ef066cec6a13bbb404ec57b1e92637 15-Jul-2010 Jeff Brown <jeffbrown@google.com> Add support for new input sources.

Added several new coordinate values to MotionEvents to capture
touch major/minor area, tool major/minor area and orientation.

Renamed NDK input constants per convention.

Added InputDevice class in Java which will eventually provide
useful information about available input devices.

Added APIs for manufacturing new MotionEvent objects with multiple
pointers and all necessary coordinate data.

Fixed a bug in the input dispatcher where it could get stuck with
a pointer down forever.

Fixed a bug in the WindowManager where the input window list could
end up containing stale removed windows.

Fixed a bug in the WindowManager where the input channel was being
removed only after the final animation transition had taken place
which caused spurious WINDOW DIED log messages to be printed.

Change-Id: Ie55084da319b20aad29b28a0499b8dd98bb5da68
/frameworks/base/core/jni/android_view_KeyEvent.h
46b9ac0ae2162309774a7478cd9d4e578747bfc2 23-Apr-2010 Jeff Brown <jeffbrown@google.com> Native input dispatch rewrite work in progress.

The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.

Includes part of the new input event NDK API. Some details TBD.

To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.

There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.

End-to-end event dispatch mostly works!

To do: event injection, rate limiting, ANRs, testing, optimization, etc.

Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
/frameworks/base/core/jni/android_view_KeyEvent.h