《android 的按键映射表》.docVIP

Keymaps and Keyboard Input This document describes how keyboard input gets translated into Android actions and how you can customize key layout and key character maps to match the needs of your own device. Android uses the standard Linux input event device (/dev/event0) and driver as described in the linux/input.h kernel header file. For more information regarding standard Linux input drivers, please see Linux Input drivers at . Androids input event device is structured around an interrupt or polling routine that captures the device-specific scancode and converts it to a standard form acceptable to Linux (as defined in input.h) before passing it to the kernel with input_event(). The keymap drivers other primary function is to establish a probe function that sets up the interrupt or polling function, handles hardware initialization, and attaches the driver to the input subsystem with input_register_device(). The table below describes the steps required to translate from keyboard input to application action: Step Action Explanation 1. Window manager reads key event from Linux keyboard driver. Events are typically positional. For example, the top-left position on a keypad returns 16 regardless of whether that key is printed with a Q (as on a QWERTY keypad) or an A (as on an AZERTY keypads). This first conversion by the Linux Keyboard Driver yields a scancode (for example, 16). 2. Window manager maps scancode to keycode. When the window manager reads a key event out of the driver, it maps the scancode to a keycode using a key layout map file. Typically, the keycode is the primary symbol screen-printed on a key. For example, KEYCODE_DPAD_CENTER is the center button on the five-way navigation control. Even though ALT + G generates a ? character, KEYCODE_G is the keycode. 3. Window manager sends both the scancode and the keycode to the application. Both the scancode and keycode are handled by the view with focus. How the application interprets both depend on the app