Dispositivos de teclado

Android admite una variedad de dispositivos de teclado, incluidos teclados de funciones especiales (controles de volumen y encendido), teclados QWERTY integrados compactos y teclados externos estilo PC con todas las funciones.

Este documento describe únicamente los teclados físicos. Consulte el SDK de Android para obtener información sobre los teclados virtuales (editores de métodos de entrada).

Clasificación del teclado

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

• El dispositivo de entrada informa la presencia de cualquier código de tecla de Linux utilizado en los teclados, incluidos 0 a 0xff o KEY_OK a KEY_MAX .

• El dispositivo de entrada informa la presencia de cualquier código clave de Linux utilizado en joysticks y gamepads, incluidos BTN_0 a BTN_9 , BTN_TRIGGER a BTN_DEAD o BTN_A a BTN_THUMBR .

Actualmente, los joysticks se clasifican como teclados porque los eventos EV_KEY informan sobre los botones del joystick y del gamepad de la misma manera que se informan las teclas del teclado. Por lo tanto, los joysticks y gamepads también utilizan archivos de mapas clave para la configuración.

Una vez que un dispositivo de entrada se ha clasificado como teclado, el sistema carga el archivo de configuración del dispositivo de entrada y la distribución del teclado.

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

• Si el dispositivo de entrada tiene teclas asignadas a KEYCODE_Q , se considera que el dispositivo tiene un teclado alfabético (en lugar de numérico). La capacidad del teclado alfabético se informa en el objeto Configuration del recurso 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 (todas deben estar presentes), entonces se considera que el dispositivo tiene un teclado direccional. La capacidad del teclado direccional se informa en el objeto Configuration del recurso como NAVIGATION_DPAD .

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

Requisitos del controlador de teclado

1. Los controladores de teclado sólo deben registrar códigos de teclas para las teclas que realmente admiten. El registro de códigos de teclas excesivos puede confundir el algoritmo de clasificación del dispositivo o hacer que el sistema detecte incorrectamente las capacidades de teclado admitidas del dispositivo.

2. Los controladores de teclado deben usar EV_KEY para informar las pulsaciones de teclas, usando un valor de 0 para indicar que se suelta una tecla, un valor de 1 para indicar que se presiona una tecla y un valor mayor o igual a 2 para indicar que la tecla está presionada. repitiéndose automáticamente.

3. Android realiza su propia repetición de teclado. La función de repetición automática debe estar desactivada en el controlador.

4. Los controladores de teclado pueden indicar opcionalmente el uso de HID o el código de escaneo de bajo nivel enviando EV_MSC con MSC_SCANCODE y un valor que indica el uso o el código de escaneo cuando se presiona la tecla. Actualmente Android no utiliza esta información.

5. Los controladores de teclado deben admitir la configuración de estados de LED cuando se escribe EV_LED en el dispositivo. El controlador hid-input maneja esto automáticamente. Al momento de escribir este artículo, Android usa LED_CAPSLOCK , LED_SCROLLLOCK y LED_NUMLOCK . Estos LED solo necesitan ser compatibles cuando el teclado realmente tiene las luces indicadoras asociadas.

6. Los controladores de teclado para teclados integrados (por ejemplo, que usan una matriz GPIO) deben asegurarse de enviar eventos EV_KEY con un valor de 0 para cualquier tecla que aún esté presionada cuando el dispositivo entre en modo de suspensión. De lo contrario, las teclas podrían atascarse y se repetirán automáticamente para siempre.

Operación del teclado

El siguiente es 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 teclas de Android utilizando el mapa de distribución de teclas del teclado.

2. InputReader consume los eventos sin procesar y actualiza el estado de la metaclave. Por ejemplo, si se presiona o suelta la tecla Mayús izquierda, el lector configurará o restablecerá los bits META_SHIFT_LEFT_ON y META_SHIFT_ON en consecuencia.

3. InputReader notifica a InputDispatcher sobre el evento clave.

4. InputDispatcher pregunta a WindowManagerPolicy qué hacer con el evento clave llamando 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 mantiene efectivamente un bloqueo de activación a lo largo de esta ruta crítica para garantizar que se ejecute hasta su finalización.

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

6. InputDispatcher pone en cola la clave para su procesamiento en el hilo de envío.

7. Cuando InputDispatcher retira la clave de la cola, le da a WindowManagerPolicy una segunda oportunidad de interceptar el evento clave llamando a WindowManagerPolicy.interceptKeyBeforeDispatching . Este método maneja accesos directos del sistema y otras funciones.

8. Luego, 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 hasta la vista enfocada para el envío de claves previas al IME.

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

11. Si el IME no consumió el evento clave, entonces el evento clave se propaga 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 al InputDispatcher si se consumió el evento clave. Si el evento no se consumió, InputDispatcher llama WindowManagerPolicy.dispatchUnhandledKey para aplicar el comportamiento de "alternativa". Dependiendo de la acción alternativa, el ciclo de envío de eventos clave puede reiniciarse utilizando un código clave diferente. Por ejemplo, si una aplicación no maneja KEYCODE_ESCAPE , el sistema puede volver a enviar el evento clave como KEYCODE_BACK .

Configuración del teclado

El comportamiento del teclado está determinado por la distribución de las teclas, el mapa de caracteres de las teclas y la configuración del dispositivo de entrada.

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

• Archivos de diseño clave
• Archivos de mapas de personajes clave
• Archivos de configuración del dispositivo de entrada

Propiedades

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

Diseño del teclado

Definición: keyboard.layout = <nombre>

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

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

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

teclado.mapa de caracteres

Definición: keyboard.characterMap = <nombre>

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

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

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

teclado.orientaciónAware

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 del teclado direccional giran cuando cambia la orientación de la pantalla asociada.

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

El valor predeterminado es 0 .

El conocimiento de la orientación se utiliza para admitir la rotación de las teclas direccionales del teclado, como en el Motorola Droid. Por ejemplo, cuando el dispositivo se gira 90 grados en el sentido de las agujas del reloj desde su orientación natural, KEYCODE_DPAD_UP se reasigna para producir KEYCODE_DPAD_RIGHT ya que la tecla "arriba" termina apuntando "derecha" cuando el dispositivo se mantiene en esa orientación.

teclado.integrado

Definición: keyboard.builtIn = 0 | 1

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

El valor predeterminado es 1 si el nombre del dispositivo termina con -keypad , 0 en caso contrario.

Al teclado integrado siempre se le asigna una identificación de dispositivo de 0 . A otros teclados que no están integrados se les asignan identificadores de dispositivo únicos distintos de cero.

Usar una identificación de 0 para el teclado integrado es importante para mantener la compatibilidad con el campo KeyCharacterMap.BUILT_IN_KEYBOARD , que especifica la identificación del teclado integrado y tiene un valor de 0 . Este campo ha quedado obsoleto en la API, pero es posible que aplicaciones más antiguas aún lo utilicen.

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

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 utilizaba ninguna propiedad de configuración. Se supuso que todos los teclados estaban conectados físicamente y tenían en cuenta la orientación. El diseño de clave predeterminado y el mapa de caracteres clave se denominaron qwerty en lugar de Generic . El formato del mapa de caracteres clave también era muy diferente y el marco no admitía teclados completos estilo PC ni teclados externos.

Al actualizar dispositivos a Honeycomb, asegúrese de crear o actualizar la configuración necesaria y los archivos de mapa clave.

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

El sistema hace referencia a claves utilizando varios identificadores diferentes, según la capa de abstracción.

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

A medida que Android lee los eventos EV_KEY del kernel de Linux, traduce cada código de clave de Linux en su código de clave 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, la instancia android.view.KeyEvent informa el código clave de Linux como el valor de getScanCode() y el código clave de Android como el valor de getKeyCode() . A los efectos del marco, sólo es importante el valor de getKeyCode() .

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

Tablas de códigos

Las siguientes tablas muestran cómo se relacionan entre sí los usos de HID, los códigos clave de Linux y los códigos clave de Android.

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 Notas se refiere a las notas que se publican después de la tabla.

La columna Versión especifica la primera versión de la plataforma Android que incluyó esta clave en su mapa de claves predeterminado. Se muestran varias filas en los casos en que el mapa de claves predeterminado ha cambiado entre versiones. La versión más antigua indicada es la 1.6.

• En Gingerbread (2.3) y versiones anteriores, el mapa de claves predeterminado era qwerty.kl . Este mapa de teclas solo fue diseñado para usarse con el emulador de Android y no para admitir teclados externos arbitrarios. Sin embargo, algunos fabricantes de equipos originales agregaron soporte para teclado Bluetooth a la plataforma y confiaron en qwerty.kl para proporcionar las asignaciones de teclado necesarias. En consecuencia, estas asignaciones más antiguas pueden ser de interés para los OEM que están construyendo periféricos para estos dispositivos en particular. Tenga en cuenta que las asignaciones son sustancialmente diferentes de las actuales, particularmente con respecto al tratamiento de la tecla HOME . Se recomienda que todos los periféricos nuevos se desarrollen de acuerdo con Honeycomb o mapas clave más recientes (es decir, HID estándar).

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

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

Los controladores HID y los mapas de claves específicos del dispositivo pueden aplicar asignaciones diferentes a las que se indican aquí.

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

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

Página del consumidor HID (0x0c)

Asignaciones no escondidas adicionales

Estas asignaciones describen funciones que no aparecen en HID, sino para las cuales existen códigos de claves Linux.

Legacy Keys sin apoyo

Estas asignaciones aparecieron en versiones anteriores de Android, pero eran inconsistentes con los códigos de claves Linux HID o usados ​​no estándar. Ya no son apoyados.

Notas

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

   En un teclado en inglés de EE. UU. (Qwerty), la tecla alfabética superior izquierda está etiquetada Q. En un teclado francés (Azerty), la tecla en la misma posición está etiquetada A. A pesar de la etiqueta, en ambos teclados, la tecla alfabética superior izquierda se hace referencia utilizando el uso de HID 0x07 0x0014 que se asigna al código de clave Linux Key_q.

   Cuando Android se configura con un diseño de teclado en inglés de EE. UU., El código de tecla Linux Key_Q se asignará al código de tecla de Android KeyCode_Q y producirá los caracteres 'Q' y 'Q'. Sin embargo, cuando Android se configura con un diseño de teclado francés, el código de tecla Linux Key_Q se asignará al código de teclas de Android, KeyCode_A y producirá los caracteres 'A' y 'A'.

   El código de la tecla Android generalmente refleja la interpretación específica del lenguaje de la clave, por lo que se puede usar un código de clave Android diferente para diferentes idiomas.

2. 0x0c 0x022f AC Zoom se define en el HID como un control lineal, pero el núcleo lo asigna como una clave, lo que probablemente sea incorrecto.

3. Las teclas de función de Linux KEY_FN_* se asignan a códigos de clave más simples, pero se envían con el bit de meta estado META_FUNCTION establecido en verdadero.

4. Antes del Sandwich 4.0 de Android Ice Cream, el diseño de clave predeterminado contenía asignaciones para algunos códigos de clave adicionales que no se definieron en los encabezados del kernel de Linux. Desde entonces, estas asignaciones se han eliminado porque desde entonces a estos códigos clave previamente indefinidos se han asignado diferentes significados en versiones más recientes del núcleo de Linux.

Fuentes

1. Tablas de uso de USB HID V1.12
2. Linux 2.6.39 Kernel: incluir/linux/input.h, controladores/hid/hid-input.c
3. Android ICS: Qwerty.kl, Generic.KL, KeyEvent.java