Dispositivos de teclado

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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

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 un teclado si se cumple alguna de las siguientes condiciones:

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

• El dispositivo de entrada informa la presencia de cualquier código de tecla de Linux que se use 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 los botones del joystick y del control de juegos de la misma manera que se informan las teclas del teclado. Por lo tanto, los joysticks y los gamepads también usan archivos de asignación de teclas para la configuración.

Una vez que se clasifica un dispositivo de entrada 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 alguna tecla asignada a KEYCODE_Q, se considera que tiene un teclado alfabético (en lugar de numérico). La función 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), se considera que el dispositivo tiene un teclado direccional. La función del teclado direccional se informa en el objeto Configuration del recurso como NAVIGATION_DPAD.

• Si el dispositivo de entrada tiene alguna tecla asignada a KEYCODE_BUTTON_A o a otras teclas relacionadas con el gamepad, se considera que el dispositivo tiene un gamepad.

Requisitos del controlador de teclado

1. Los controladores de teclado solo deben registrar códigos de teclas para las teclas que realmente admiten. El registro de códigos de teclas en exceso puede confundir el algoritmo de clasificación del dispositivo o hacer que el sistema detecte de forma incorrecta las capacidades compatibles del teclado del dispositivo.

2. Los controladores de teclado deben usar EV_KEY para informar las pulsaciones de teclas, con 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 que 2 para indicar que la tecla se repite automáticamente.

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

4. De manera opcional, los controladores de teclado pueden indicar el uso de HID o el código de análisis de bajo nivel enviando EV_MSC con MSC_SCANCODE y un valor que indique el uso o el código de análisis cuando se presiona la tecla. Actualmente, Android no usa 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 lo controla automáticamente. En el momento de escribir este artículo, Android usa LED_CAPSLOCK, LED_SCROLLLOCK y LED_NUMLOCK. Estos LED solo deben admitirse cuando el teclado realmente tiene las luces indicadoras asociadas.

6. Los controladores de teclado para teclados incorporados (por ejemplo, con una matriz GPIO) deben asegurarse de enviar eventos EV_KEY con un valor de 0 para las teclas que aún están presionadas cuando el dispositivo entra en modo de suspensión. De lo contrario, las teclas podrían quedar atascadas y repetirse automáticamente para siempre.

Operación 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 los códigos de teclas de Linux (a veces denominados códigos de escaneo) a los códigos de teclas de Android con el mapa de diseño de teclas del teclado.

2. InputReader consume los eventos sin procesar y actualiza el estado de la meta clave. Por ejemplo, si se presiona o suelta la tecla de mayúsculas izquierda, el lector establecerá o restablecerá los bits META_SHIFT_LEFT_ON y META_SHIFT_ON según corresponda.

3. InputReader notifica a InputDispatcher sobre el evento de tecla.

4. InputDispatcher le pregunta a WindowManagerPolicy qué hacer con el evento de tecla llamando a WindowManagerPolicy.interceptKeyBeforeQueueing. Este método forma parte de una ruta crítica que es responsable de activar el dispositivo cuando se presionan ciertas teclas. El EventHub mantiene de manera efectiva un bloqueo de activación a lo largo de esta ruta crítica para garantizar que se ejecute hasta completarse.

5. Si se está usando un InputFilter, InputDispatcher le da la oportunidad de consumir o transformar la clave. Se puede usar InputFilter 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 subproceso de envío.

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

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

9. Dentro de la aplicación, el evento de tecla se propaga por la jerarquía de vistas hasta la vista enfocada para el envío de teclas previas al IME.

10. Si el evento de tecla no se controla en el envío previo al IME y se está usando un IME, el evento de tecla se entrega al IME.

11. Si el IME no consumió el evento de tecla, este se propaga por la jerarquía de vistas hasta la vista enfocada para el envío de teclas estándar.

12. La aplicación informa a InputDispatcher si se consumió el evento de tecla. Si no se consumió el evento, InputDispatcher llama a WindowManagerPolicy.dispatchUnhandledKey para aplicar el comportamiento de "reemplazo". Según la acción de resguardo, es posible que se reinicie el ciclo de envío de eventos de teclas con un código de tecla diferente. Por ejemplo, si una aplicación no controla KEYCODE_ESCAPE, el sistema puede volver a enviar el evento de tecla como KEYCODE_BACK.

Configuración del teclado

El comportamiento del teclado se determina según el diseño de teclas, el mapa de caracteres clave y la configuración del dispositivo de entrada.

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

• Archivos de diseño de claves
• Archivos de mapas de caracteres clave
• Archivos de configuración de dispositivos de entrada

Propiedades

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

keyboard.layout

Definición: keyboard.layout = <name>

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

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

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

keyboard.characterMap

Definición: keyboard.characterMap = <name>

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

Los espacios en el 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.

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

• Si el valor es 0, el teclado no se ve afectado por los cambios de orientación de la pantalla.

El valor predeterminado es 0.

La detección de orientación se usa para admitir la rotación de las teclas del teclado direccional, como en el Motorola Droid. Por ejemplo, cuando el dispositivo se rota en el sentido de las manecillas del reloj 90 grados desde su orientación natural, KEYCODE_DPAD_UP se vuelve a asignar para producir KEYCODE_DPAD_RIGHT, ya que la tecla "arriba" termina apuntando a "derecha" cuando el dispositivo se sostiene en esa orientación.

keyboard.builtIn

Definición: keyboard.builtIn = 0 | 1

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

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

Al teclado integrado siempre se le asigna un ID de dispositivo de 0. A los otros teclados que no son integrados se les asignan IDs de dispositivos únicos distintos de cero.

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

Un teclado de funciones especiales (cuyo mapa de caracteres clave especifique un tipo de SPECIAL_FUNCTION) nunca se registrará como el teclado integrado, independientemente de la configuración de esta propiedad. Esto se debe a que, por definición, un teclado con funciones especiales no está diseñado para escribir texto 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 suponía que todos los teclados estaban conectados físicamente y tenían en cuenta la orientación. El diseño de teclas y el mapa de caracteres de teclas predeterminados se llamaron qwerty en lugar de Generic. El formato del mapa de caracteres clave también era muy diferente, y el framework no admitía teclados externos ni teclados completos al estilo de PC.

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

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

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

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

A medida que Android lee eventos EV_KEY del kernel de Linux, traduce cada código de tecla de Linux en su código de tecla de Android correspondiente según el archivo de diseño de teclas del dispositivo.

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

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

Tablas de códigos

En las siguientes tablas, se muestra cómo se relacionan entre sí los usos de HID, los códigos de teclas de Linux y los códigos de teclas de Android.

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

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

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

La columna Version especifica la primera versión de la plataforma de Android que incluyó esta clave en su mapa de teclas predeterminado. Se muestran varias filas en los casos en que el mapa de teclas predeterminado cambió entre versiones. La versión más antigua que se indica es 1.6.

• En Gingerbread (2.3) y versiones anteriores, el mapa de teclas predeterminado era qwerty.kl. Este mapa de teclas solo se diseñó para usarse con Android Emulator y no para admitir teclados externos arbitrarios. Sin embargo, algunos OEMs agregaron compatibilidad con teclados Bluetooth a la plataforma y se basaron en qwerty.kl para proporcionar las asignaciones de teclado necesarias. En consecuencia, estas asignaciones anteriores pueden ser de interés para los OEM que compilan periféricos para estos dispositivos en particular. Ten en cuenta que las asignaciones son muy diferentes de las actuales, en particular, con respecto al tratamiento de la clave HOME. Se recomienda que todos los periféricos nuevos se desarrollen de acuerdo con Honeycomb o mapas de teclas más recientes (p. ej., 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 de estilo PC completos. La mayoría de las funciones de los teclados HID estándar deberían funcionar de inmediato.

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

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

Página del teclado y el teclado numérico HID (0x07)

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

Página de consumidor de HID (0x0c)

Asignaciones adicionales que no son HID

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

Claves heredadas no admitidas

Estas asignaciones aparecieron en versiones anteriores de Android, pero no eran coherentes con HID o usaban códigos de teclas no estándar de Linux. Ya no son compatibles.

Notas

1. El código de tecla de Android asociado con las teclas alfanuméricas y simbólicas comunes puede variar según el diseño y el idioma 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 suelen definirse de forma posicional, aunque 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 de la esquina superior izquierda está etiquetada como Q. En un teclado francés (AZERTY), la tecla en la misma posición está etiquetada como A. A pesar de la etiqueta, en ambos teclados, la tecla alfabética superior izquierda se refiere al uso de HID 0x07 0x0014, que se asigna al código de tecla KEY_Q de Linux.

   Cuando Android se configura con un diseño de teclado en inglés de EE.UU., el código de tecla KEY_Q de Linux se asignará al código de tecla KEYCODE_Q de Android 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 KEY_Q de Linux se asignará al código de tecla KEYCODE_A de Android y producirá los caracteres "A" y "a".

   Por lo general, el código de clave de Android refleja la interpretación de la clave específica del idioma, por lo que se puede usar un código de clave de Android diferente para diferentes 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 sea incorrecto.

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

4. Antes de Android Ice Cream Sandwich 4.0, el diseño de teclas predeterminado contenía asignaciones para algunos códigos de teclas adicionales que no se definían en los encabezados del kernel de Linux principal. Desde entonces, se quitaron estas asignaciones porque a estos códigos de teclas no definidos anteriormente se les asignaron significados diferentes 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, drivers/hid/hid-input.c
3. Android ICS: qwerty.kl, Generic.kl, KeyEvent.java