Dispositivos con teclado

Android admite diferentes dispositivos de teclado, como las funciones especiales teclados (controles de volumen y encendido), teclados QWERTY compactos incorporados, y teclados externos similares a PC con todas las funciones.

En este documento, solo se describen los teclados físicos. Consulta el SDK de Android para obtener información sobre los teclados en pantalla (editores de métodos de entrada).

Clasificación del teclado

Un dispositivo de entrada se clasifica como teclado si alguna de las siguientes opciones se aplican las siguientes condiciones:

• El dispositivo de entrada informa la presencia de códigos de teclas de Linux que se usan en teclados. incluidos 0 a 0xff o KEY_OK a KEY_MAX.

• El dispositivo de entrada informa la presencia de códigos de teclas de Linux que se usan en los joysticks. y controles de juegos, incluidos BTN_0 a BTN_9, de BTN_TRIGGER a BTN_DEAD, o de BTN_A a BTN_THUMBR.

Actualmente, los joysticks se clasifican como teclados porque los botones del joystick y del control de juegos. Los eventos EV_KEY los informan de la misma manera que las teclas del teclado. Por lo tanto, los joysticks y los controles de juegos también usan archivos de mapas de teclas para la configuración.

Una vez que un dispositivo de entrada se clasificó como teclado, el sistema carga el archivo de configuración del dispositivo de entrada y el diseño del teclado.

Luego, el sistema intenta determinar características adicionales del dispositivo.

• Si el dispositivo de entrada tiene teclas asignadas a KEYCODE_Q, el se considera que el dispositivo tiene un teclado alfabético (a diferencia del numérico). La capacidad del teclado alfabético se informa en el recurso Configuration. objeto como KEYBOARD_QWERTY.

• Si el dispositivo de entrada tiene teclas asignadas a KEYCODE_DPAD_UP, KEYCODE_DPAD_DOWN, KEYCODE_DPAD_LEFT, KEYCODE_DPAD_RIGHT y KEYCODE_DPAD_CENTER (todos deben estar presentes), entonces, se considera que el dispositivo para tener un teclado direccional. La capacidad del teclado direccional se informa en el recurso Configuration objeto como NAVIGATION_DPAD.

• Si el dispositivo de entrada tiene teclas asignadas a KEYCODE_BUTTON_A u otras teclas relacionadas con un control de juegos, se considera que el dispositivo tiene un control de juegos.

Requisitos del controlador del teclado

1. Los controladores del teclado solo deben registrar los códigos de tecla para las teclas que realmente admiten. El registro de códigos de tecla excesivo podría confundir el dispositivo de clasificación o hacer que el sistema detecte incorrectamente las capacidades de teclado compatibles del dispositivo.

2. Los controladores del teclado deben usar EV_KEY para informar las pulsaciones de teclas mediante un valor de 0 para indicar que se libera una clave, un valor de 1 para indicar que se presiona una tecla y un valor mayor o igual que 2 para indicar que la clave se repite automáticamente.

3. Android realiza su propio teclado que se repite. Función de repetición automática debe estar inhabilitado en el controlador.

4. De manera opcional, los controladores del teclado pueden indicar el uso de HID o la búsqueda de bajo nivel envía EV_MSC con MSC_SCANCODE y un valor que indique el uso o escanear código cuando se presiona la tecla. Esta información no se encuentra actualmente que usa Android.

5. Los controladores del teclado deben admitir la configuración de estados de luz LED cuando se escribe EV_LED al dispositivo. El controlador hid-input controla esto automáticamente. Al momento de la redacción de este documento, Android usa LED_CAPSLOCK, LED_SCROLLLOCK, y LED_NUMLOCK. Estos LED solo deben ser compatibles cuando el teclado tiene luces indicadoras asociadas.

6. Controladores de teclado para teclados incorporados (por ejemplo, con una matriz GPIO) debes asegurarte de enviar eventos EV_KEY con un valor de 0 para cualquier clave que aún estén presionados cuando el dispositivo se suspenda. De lo contrario, las claves podrían se detenga y se repetirá automáticamente para siempre.

Funcionamiento del teclado

A continuación, se incluye un breve resumen del funcionamiento del teclado en Android.

1. EventHub lee eventos sin procesar del controlador evdev y asigna códigos de teclas de Linux. (a veces denominados códigos de escaneo) a códigos de clave de Android usando el mapa de diseño de teclas del teclado.

2. InputReader consume los eventos sin procesar y actualiza el estado de la tecla meta. Por ejemplo, si presionas o sueltas la tecla Mayúsculas de la izquierda, el lector Configura o restablece los bits META_SHIFT_LEFT_ON y META_SHIFT_ON según corresponda.

3. El InputReader notifica al InputDispatcher sobre el evento clave.

4. InputDispatcher le pregunta al WindowManagerPolicy qué hacer con la clave. evento llamando a WindowManagerPolicy.interceptKeyBeforeQueueing. Este método es parte de una ruta crítica que es responsable de activar el dispositivo cuando se presionan ciertas teclas. EventHub tiene eficazmente un bloqueo de activación. a lo largo de esta ruta crítica para garantizar que se ejecutará hasta su finalización.

5. Si un InputFilter está en uso actualmente, InputDispatcher le da una de consumir o transformar la clave. Se puede usar InputFilter para implementar políticas de accesibilidad en todo el sistema de bajo nivel.

6. InputDispatcher pone en cola la clave para procesarla en el subproceso de envío.

7. Cuando InputDispatcher quita la clave de la cola, le da a WindowManagerPolicy una segunda oportunidad para interceptar el evento clave llamando WindowManagerPolicy.interceptKeyBeforeDispatching Este método controla las variables atajos y otras funciones.

8. Luego, el InputDispatcher identifica el objetivo del evento clave (la ventana enfocada). y espera a que estén listos. Luego, InputDispatcher entrega el evento clave a la aplicación.

9. Dentro de la aplicación, el evento clave se propaga hacia abajo en la jerarquía de vistas para la vista enfocada para el envío de claves previo al IME

10. Si el evento clave no se controla en el envío previo al IME y hay uno en uso, el el evento clave se entrega al IME.

11. Si el IME no consumió el evento clave, se propaga el evento clave. hacia abajo en la jerarquía de vistas hasta la vista enfocada para el envío de claves estándar.

12. La aplicación informa a InputDispatcher si la clave se consumió el evento. Si el evento no se consumió, InputDispatcher Llama a WindowManagerPolicy.dispatchUnhandledKey para aplicar el "resguardo". el comportamiento de los usuarios. Según la acción de resguardo, el ciclo de envío de eventos clave puede reiniciarse usando un código de tecla diferente. Por ejemplo, si una aplicación no controla KEYCODE_ESCAPE, el sistema puede volver a enviar el evento clave como KEYCODE_BACK en su lugar.

Configuración del teclado

El comportamiento del teclado se determina por el diseño de las teclas del teclado, los caracteres del mapa y del dispositivo de entrada.

Consulta las siguientes secciones para obtener más detalles sobre los archivos que participar en la configuración del teclado:

• Archivos de diseño de claves
• Archivos de mapa de caracteres clave
• Archivos de configuración del dispositivo de entrada

Propiedades

Las siguientes propiedades de configuración del dispositivo de entrada se usan para teclados.

teclado.layout

Definición: keyboard.layout = <nombre>

Especifica el nombre del archivo de diseño de claves asociado con el dispositivo de entrada. excepto la extensión .kl. Si no se encuentra este archivo, el sistema de entrada usará el diseño de teclas predeterminado.

Los espacios del nombre se convierten en guiones bajos durante la búsqueda.

Consulta la documentación del archivo de diseño clave para obtener más detalles.

teclado.caracteres

Definición: keyboard.characterMap = <nombre>

Especifica el nombre del archivo de mapa de caracteres clave asociado con el dispositivo de entrada. excepto la extensión .kcm. Si no se encuentra este archivo, el sistema de entrada usará el mapa de caracteres clave predeterminado.

Los espacios del nombre se convierten en guiones bajos durante la búsqueda.

Consulta la documentación del archivo de mapa de caracteres clave para obtener más detalles.

teclado.orientationAware

Definición: keyboard.orientationAware = 0 | 1

Especifica si el teclado debe reaccionar a los cambios de orientación de la pantalla.

• Si el valor es 1, las teclas direccionales del teclado rotan cuando el valor cambios de orientación de la pantalla asociados.

• Si el valor es 0, el teclado es inmune a los cambios de orientación de la pantalla.

El valor predeterminado es 0.

El reconocimiento de orientación se usa para admitir la rotación de las teclas direccionales del teclado como el Motorola Droid. Por ejemplo, cuando se rota el dispositivo en el sentido de las manecillas del reloj 90 grados desde su orientación natural, KEYCODE_DPAD_UP es se reasignó para producir KEYCODE_DPAD_RIGHT desde el termina apuntando 'derecha' cuando el dispositivo se mantiene en esa orientación.

teclado.builtIn

Definición: keyboard.builtIn = 0 | 1

Especifica si el teclado es el integrado (conectado físicamente) teclado.

El valor predeterminado es 1 si el nombre del dispositivo termina en -keypad; de lo contrario, es 0.

Al teclado integrado siempre se le asigna un ID de dispositivo de 0. Otros teclados no integrados reciben ID de dispositivos únicos distintos de cero.

El uso de un ID de 0 para el teclado integrado es importante para el mantenimiento compatibilidad con el campo KeyCharacterMap.BUILT_IN_KEYBOARD, que especifica El ID del teclado integrado y tiene un valor de 0. Este campo se dado que dejó de estar disponible en la API, pero es posible que las aplicaciones más antiguas aún lo utilicen.

Un teclado de funciones especiales (uno cuyo mapa de caracteres de tecla especifica una tipo de SPECIAL_FUNCTION) nunca se registrarán como el teclado integrado. independientemente de la configuración de esta propiedad. Esto se debe a que una función especial el teclado está, por definición, no está diseñado para usarse con la escritura de uso general.

Configuraciones de ejemplo

# This is an example input device configuration file for a built-in
# keyboard that has a DPad.

# The keyboard is internal because it is part of the device.
device.internal = 1

# The keyboard is the default built-in keyboard so it should be assigned
# an id of 0.
keyboard.builtIn = 1

# The keyboard includes a DPad which is mounted on the device.  As the device
# is rotated the orientation of the DPad rotates along with it, so the DPad must
# be aware of the display orientation.  This ensures that pressing 'up' on the
# DPad always means 'up' from the perspective of the user, even when the entire
# device has been rotated.
keyboard.orientationAware = 1

Notas de compatibilidad

Antes de Honeycomb, el asignador de entrada del teclado no usaba ninguna propiedad de configuración. Se da por sentado que todos los teclados están conectados físicamente y reconocen la orientación. Predeterminado El diseño de la clave y el mapa de caracteres clave se denominaba qwerty en lugar de Generic. La clave también era muy diferente y el framework no era compatible Teclados completos tipo PC o externos.

Cuando actualices dispositivos a Honeycomb, asegúrate de crear o actualizar las configuración y archivos de mapas de claves.

Usos de HID, códigos de teclas de Linux y códigos de teclas de Android

El sistema se refiere a las claves que usan varios identificadores diferentes, según el capa de abstracción.

En el caso de los dispositivos HID, cada clave tiene un uso de HID asociado. El hid-input de Linux el controlador y los controladores HID de proveedores relacionados y específicos del dispositivo son responsables para analizar informes HID y asignar usos de HID a códigos de teclas de Linux.

A medida que Android lee los eventos EV_KEY del kernel de Linux, traduce cada uno de Linux en su código de tecla de Android correspondiente de acuerdo con el archivo de diseño de claves del dispositivo.

Cuando el evento clave se envía a una aplicación, el android.view.KeyEvent informa el código de clave de Linux como el valor de getScanCode() y el Código de clave de Android como valor de getKeyCode() A los efectos del solo es importante el valor de getKeyCode().

Ten en cuenta que Android no utiliza la información de uso de HID ni pasan a las aplicaciones.

Tablas de códigos

En las siguientes tablas, se muestra cómo los usos de HID, los códigos de teclas de Linux y Android los códigos de tecla están relacionados entre sí.

La columna LKC especifica el código de clave de Linux en hexadecimal.

La columna AKC especifica el código de clave de Android en hexadecimal.

La columna Notes hace referencia a las notas que se publican después de la tabla.

La columna Versión especifica la primera versión de la plataforma de Android incluir esta clave en su mapa de claves predeterminado. Varias filas se se muestra en los casos en los que el mapa de claves predeterminado cambia entre versiones. La versión más antigua que se indicó es la 1.6.

• En Gingerbread (2.3) y versiones anteriores, el mapa de claves predeterminado era qwerty.kl Este mapa de claves se diseñó solo para usarse con la plataforma emulador y no estaba diseñado para usarse para admitir arquitecturas teclados externos. Sin embargo, algunos OEMs agregaron Bluetooth compatibilidad del teclado con la plataforma y dependió de qwerty.kl para proporcionar las asignaciones de teclado necesarias. Por lo tanto, estos Los mapeos más antiguos pueden ser de interés para los OEM que están creando periféricos para estos dispositivos en particular. Ten en cuenta que las asignaciones son muy diferentes de los actuales, especialmente con respecto al tratamiento de la clave HOME. Se recomienda que todos los periféricos nuevos se desarrollen según la normativa Honeycomb o más mapas de claves recientes (es decir, HID estándar).

• A partir de Honeycomb (3.0), el mapa de teclas predeterminado es Generic.kl. Este mapa de teclas se diseñó para admitir teclados completos estilo PC. La mayoría de las funciones de los teclados HID estándar deberían funcionar. de la caja.

La asignación de códigos de teclas puede variar según las versiones del kernel de Linux y Android. Cuando se sabe que ocurrieron cambios en los mapas de claves predeterminados de Android, se indican en la columna de versión.

Es posible que los controladores de claves y los controladores HID específicos de cada dispositivo apliquen asignaciones diferentes. que las que se indican aquí.

Página del teclado y teclado HID (0x07)

Página de escritorio genérica de HID (0x01)

Página para consumidores de HID (0x0c)

Asignaciones adicionales que no son HID

Estas asignaciones describen funciones que no aparecen en HID, pero para las que Linux existen los códigos de tecla.

Claves heredadas no compatibles

Estas asignaciones aparecieron en versiones anteriores de Android, pero no eran coherentes con Códigos de teclas de Linux no estándar utilizados o HID. Ya no se admiten.

Notas

1. El código de tecla de Android asociado con los códigos alfanuméricos y simbólicos comunes las teclas pueden variar según el idioma y el diseño del teclado. Por razones históricas, los códigos de escaneo físicos y los usos de HID asociados con las teclas de un teclado, a menudo se definen posicionalmente aunque las etiquetas impresas en esas claves puedan variar de un lenguaje a otro.

   En un teclado de inglés de EE.UU. (QWERTY), la tecla alfabética superior izquierda es con la etiqueta Q. En un teclado francés (AZERTY), la tecla en la misma posición se etiqueta como A. A pesar de la etiqueta, en ambos teclados, la tecla alfabética superior izquierda se denomina mediante el uso de HID 0x07 0x0014, que se asigna al código de tecla de Linux KEY_Q.

   Cuando Android está configurado con un diseño de teclado inglés de EE.UU., el código de tecla de Linux KEY_Q se asignará al código de tecla de Android KEYCODE_Q y generará los caracteres 'Q' y "q". Sin embargo, cuando Android está configurado con un diseño de teclado francés, el código de tecla de Linux KEY_Q se asignará al código de tecla de Android KEYCODE_A y producirá los caracteres 'A' y "a".

   Por lo general, el código de clave de Android refleja la clave específica del lenguaje interpretación de la clave, por lo que un código de clave de Android diferente puede para distintos idiomas.

2. 0x0c 0x022f AC Zoom se define en el HID como un control lineal, pero el kernel lo asigna como una clave, lo que probablemente no sea correcto.

3. Las teclas de función de Linux KEY_FN_* se asignaron a una configuración pero se envían con el metaestado META_FUNCTION bit a true.

4. Antes de Android Ice Cream Sandwich 4.0, el diseño de claves predeterminado contenía asignaciones para algunos códigos de tecla adicionales que no estaban definidos en los encabezados del kernel de Linux de la línea principal. Estos mapeos tienen desde se eliminó porque estos códigos de tecla previamente no definidos ya que se les asignaron diferentes significados en versiones más recientes del kernel de Linux.

Fuentes

1. Tablas de uso de HID USB v1.12
2. Kernel de Linux 2.6.39: include/linux/input.h, controllers/hid/hid-input.c
3. ICS de Android: qwerty.kl, Generic.kl, KeyEvent.java