Dispositivos com teclado

O Android oferece suporte a vários dispositivos de teclado, incluindo funções especiais teclados (controles de volume e liga/desliga), teclados QWERTY compactos incorporados, e teclados externos completos no estilo PC.

Este documento descreve apenas teclados físicos. Consulte o SDK do Android para ver informações sobre teclados de software (Editores de método de entrada).

Classificação do teclado

Um dispositivo de entrada será classificado como teclado se uma das seguintes opções: condições são mantidas:

• O dispositivo de entrada informa a presença de códigos de teclas do Linux usados em teclados. incluindo de 0 a 0xff ou de KEY_OK a KEY_MAX.

• O dispositivo de entrada informa a presença de códigos de teclas do Linux usados em joysticks. e gamepads incluindo de BTN_0 a BTN_9, BTN_TRIGGER a BTN_DEAD, ou BTN_A a BTN_THUMBR.

Atualmente, os joysticks são classificados como teclados porque os botões deles são informados por eventos EV_KEY da mesma forma que as teclas do teclado. Assim, joysticks e gamepads também usam os principais arquivos de mapa para configuração.

Depois que um dispositivo de entrada for classificado como teclado, o sistema carregará o arquivo de configuração do dispositivo de entrada e layout do teclado.

Em seguida, o sistema tenta determinar outras características do dispositivo.

• Se o dispositivo de entrada tiver alguma tecla mapeada para KEYCODE_Q, o considera-se que o dispositivo tem um teclado alfabético (e não numérico). O recurso do teclado alfabético é informado no recurso Configuration como KEYBOARD_QWERTY.

• Se o dispositivo de entrada tiver alguma tecla mapeada para KEYCODE_DPAD_UP: KEYCODE_DPAD_DOWN, KEYCODE_DPAD_LEFT, KEYCODE_DPAD_RIGHT e KEYCODE_DPAD_CENTER (todos precisam estar presentes), então o dispositivo é considerado ter um teclado direcional. O recurso do teclado direcional é informado no recurso Configuration. como NAVIGATION_DPAD.

• Se o dispositivo de entrada tiver alguma tecla mapeada para KEYCODE_BUTTON_A ou outras teclas relacionadas ao gamepad, o dispositivo será considerado como tendo um gamepad.

Requisitos do driver do teclado

1. Os drivers de teclado só devem registrar códigos de teclas para as teclas que suporte de verdade. O registro de códigos de chave excedentes pode confundir o dispositivo algoritmo de classificação, ou fazer com que o sistema detecte incorretamente as capacidades de teclado compatíveis do dispositivo.

2. Os drivers do teclado precisam usar EV_KEY para informar pressionamentos de tecla usando um valor. de 0 para indicar que uma chave é liberada, um valor de 1 para indicar que uma tecla é pressionada e um valor maior ou igual a 2 para indicar que a chave é repetida automaticamente.

3. O Android executa a própria repetição de teclado. Funcionalidade de repetição automática deve ser desativado no driver.

4. Os drivers do teclado podem indicar o uso de HID ou a verificação de baixo nível código enviando EV_MSC com MSC_SCANCODE e um valor indicando o uso ou ler o código quando a tecla for pressionada. No momento, essas informações não estão usados pelo Android.

5. Os drivers de teclado precisam oferecer suporte à configuração de estados do LED quando EV_LED for gravado. ao dispositivo. O driver do hid-input processa isso automaticamente. No momento em que este artigo foi escrito, o Android usa LED_CAPSLOCK, LED_SCROLLLOCK. e LED_NUMLOCK. Esses LEDs só precisam de suporte quando o teclado tem as luzes indicadoras associadas.

6. Drivers de teclado para teclados incorporados (por exemplo, usando uma matriz GPIO) envie eventos EV_KEY com um valor de 0 para todas as chaves que ainda são pressionados quando o dispositivo está em modo de suspensão. Caso contrário, as chaves poderão travadas e repetem automaticamente para sempre.

Operação do teclado

Confira a seguir um breve resumo da operação do teclado no Android.

1. O EventHub lê eventos brutos do driver evdev e mapeia códigos de tecla do Linux (também chamados de códigos de verificação) nos códigos de tecla do Android usando o mapa de layout de teclas do teclado.

2. O InputReader consome os eventos brutos e atualiza o estado da tecla meta. Por exemplo, se a tecla shift esquerda for pressionada ou solta, o leitor vai defina ou redefina os bits META_SHIFT_LEFT_ON e META_SHIFT_ON adequadamente.

3. O InputReader notifica o InputDispatcher sobre o evento principal.

4. O InputDispatcher pergunta ao WindowManagerPolicy o que fazer com a chave. evento chamando WindowManagerPolicy.interceptKeyBeforeQueueing. Esse método faz parte de um caminho crítico responsável por despertar o dispositivo quando algumas teclas são pressionadas. O EventHub mantém um wake lock de maneira eficaz. nesse caminho crítico para garantir que ele seja executado até a conclusão.

5. Se um InputFilter estiver em uso no momento, o InputDispatcher concederá a ele um chance de consumir ou transformar a chave. O InputFilter pode ser usado para implementar políticas de acessibilidade de baixo nível para todo o sistema.

6. O InputDispatcher enfileira a chave para processamento na linha de execução de envio.

7. Quando o InputDispatcher retira a chave da fila, ele fornece ao WindowManagerPolicy uma segunda chance de interceptar o evento de tecla chamando WindowManagerPolicy.interceptKeyBeforeDispatching Esse método lida com o sistema atalhos de teclado e outras funções.

8. Em seguida, o InputDispatcher identifica o destino do evento principal (a janela em foco). e espera até que elas fiquem prontas. Depois, o InputDispatcher entrega o evento de tecla ao aplicativo.

9. Dentro do aplicativo, o evento de tecla se propaga pela hierarquia de visualização até a visualização focada para envio de chaves pré-IME.

10. Se o evento principal não for manipulado no envio do pré-IME e um IME estiver em uso, o é entregue ao IME.

11. Se o evento principal não for consumido pelo IME, ele será propagado pela hierarquia de visualizações até a visualização em foco para envio de teclas padrão.

12. O aplicativo informa ao InputDispatcher se a chave evento for consumido. Se o evento não foi consumido, o InputDispatcher chama WindowManagerPolicy.dispatchUnhandledKey para aplicar "substituto". do seu modelo. Dependendo da ação substituta, o ciclo de envio do evento principal pode ser reiniciado. usando um código de tecla diferente. Por exemplo, se um aplicativo não lida KEYCODE_ESCAPE, o sistema poderá reenviar o evento de tecla como KEYCODE_BACK.

Configuração do teclado

O comportamento do teclado é determinado pelo layout das teclas, pelo caractere de tecla mapa e configuração do dispositivo de entrada.

Consulte as seções a seguir para mais detalhes sobre os arquivos que participam da configuração do teclado:

• Principais arquivos de layout
• Arquivos de mapas de caracteres principais
• Arquivos de configuração do dispositivo de entrada

Propriedades

As seguintes propriedades de configuração do dispositivo de entrada são usadas para teclados.

teclado.layout

Definição:keyboard.layout = <name>

Especifica o nome do arquivo de layout de chave associado ao dispositivo de entrada. excluindo a extensão .kl. Se esse arquivo não for encontrado, o sistema de entrada usará o layout de teclas padrão.

Os espaços no nome são convertidos em sublinhados durante a pesquisa.

Consulte a documentação do arquivo de layout principal para mais detalhes.

teclado.characterMap

Definição:keyboard.characterMap = <name>

Especifica o nome do arquivo de mapeamento de caracteres principal associado ao dispositivo de entrada. excluindo a extensão .kcm. Se esse arquivo não for encontrado, o sistema de entrada usará o mapa padrão de caracteres de tecla.

Os espaços no nome são convertidos em sublinhados durante a pesquisa.

Consulte a documentação do arquivo de mapeamento de caracteres de teclas para mais detalhes.

teclado.orientationAware

Definição:keyboard.orientationAware = 0 | 1

Especifica se o teclado deve reagir às mudanças de orientação da tela.

• Se o valor for 1, as teclas do teclado direcional serão giradas quando o mudanças de orientação da tela associadas.

• Se o valor for 0, o teclado estará imune a mudanças de orientação de exibição.

O valor padrão é 0.

O reconhecimento de orientação é usado para oferecer suporte à rotação das teclas do teclado direcionais, como no Motorola Droid. Por exemplo, quando o dispositivo é girado 90 graus no sentido horário a partir da orientação natural, KEYCODE_DPAD_UP é remapeado para produzir KEYCODE_DPAD_RIGHT desde o início a chave acaba apontando "direita" quando o dispositivo é mantido nessa orientação.

teclado.integrado

Definição:keyboard.builtIn = 0 | 1

Especifica se o teclado é integrado (fisicamente conectado) teclado.

O valor padrão será 1 se o nome do dispositivo terminar com -keypad. Caso contrário, será 0.

O teclado integrado sempre recebe o ID de dispositivo 0. Outros teclados que não são integrados recebem IDs exclusivos de dispositivo diferentes de zero.

Usar o ID 0 para o teclado integrado é importante para manter compatibilidade com o campo KeyCharacterMap.BUILT_IN_KEYBOARD, que especifica o ID do teclado integrado e tem um valor de 0. Este campo foi obsoleto na API, mas ele ainda pode ser usado por aplicativos mais antigos.

Um teclado de função especial (cujo mapa de caracteres de teclas especifica um tipo de SPECIAL_FUNCTION) nunca será registrado como o teclado integrado, seja qual for a configuração dessa propriedade. Isso ocorre porque uma função especial o teclado não se destina, por definição, à digitação para fins gerais.

Exemplos de configuração

# 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

Observações de compatibilidade

Antes do Honeycomb, o mapeador de entrada de teclado não usava propriedades de configuração. Consideramos que todos os teclados estavam fisicamente conectados e têm reconhecimento de orientação. O padrão O layout de teclas e o mapa de caracteres das teclas foram nomeados como qwerty em vez de Generic. A chave o formato do mapa de caracteres também era muito diferente, e o framework não oferecia Teclados completos ou teclados externos, como o de PC.

Ao fazer upgrade dos dispositivos para o Honeycomb, crie ou atualize os e os arquivos de mapeamento de chaves.

Usos de HID, códigos de chaves do Linux e do Android

O sistema faz referência às chaves usando vários identificadores diferentes, dependendo do camada de abstração.

Para dispositivos HID, cada chave tem um uso de HID associado. O hid-input do Linux e drivers de HID específicos do dispositivo e do fornecedor relacionado são responsáveis para analisar relatórios de HID e mapear usos de HID para códigos de chave do Linux.

Como o Android lê eventos EV_KEY do kernel do Linux, ele traduz cada Código de tecla do Linux no código de tecla correspondente do Android, de acordo com a do arquivo de layout de teclas do dispositivo.

Quando o evento de tecla é enviado para um aplicativo, o android.view.KeyEvent informa o código de chave do Linux como o valor de getScanCode() e a Código de chave do Android como o valor de getKeyCode(). Para os fins do framework, apenas o valor de getKeyCode() é importante.

Observe que as informações de uso de HID não são usadas pelo próprio Android ou passados para os aplicativos.

Tabelas de código

As tabelas a seguir mostram como o uso de HIDs, os códigos de chaves do Linux e o uso do Android são relacionados entre si.

A coluna LKC especifica o código de chave do Linux em hexadecimal.

A coluna AKC especifica o código de chave do Android em hexadecimal.

A coluna Observações se refere às observações postadas após a tabela.

A coluna "Versão" especifica a primeira versão da plataforma Android. incluir essa chave em seu mapa de chaves padrão. Várias linhas são mostrado nos casos em que o mapa de teclas padrão é alterado entre as versões. A versão mais antiga indicada é a 1.6.

• No Gingerbread (2.3) e versões anteriores, o mapa de teclas padrão era qwerty.kl: Este mapa de chave foi destinado somente para uso com o Android e não foi criado para dar suporte a regras e teclados externos. No entanto, alguns OEMs adicionaram Bluetooth suporte a teclado na plataforma e dependia do qwerty.kl para fornecer os mapeamentos de teclado necessários. Consequentemente, mapeamentos mais antigos podem ser interessantes para OEMs que estejam criando periféricos específicos para esses dispositivos. Observe que os mapeamentos são substancialmente diferentes das atuais, especialmente em relação ao tratamento da chave HOME. É recomendado que todos os novos periféricos sejam desenvolvidos de acordo com o Honeycomb ou outros mapas de teclas recentes (por exemplo, HID padrão).

• A partir do Honeycomb (3.0), o mapa de chaves padrão será Generic.kl. Esse mapa de teclas foi projetado para oferecer suporte a teclados completos no estilo PC. A maioria das funcionalidades dos teclados HID padrão vai funcionar da caixa.

O mapeamento de códigos de teclas pode variar entre as versões do kernel do Linux e do Android. Quando se sabe que ocorreram mudanças nos mapas de teclado padrão do Android, elas são indicadas na coluna da versão.

Drivers de HID e mapas de chaves específicos do dispositivo podem aplicar mapeamentos diferentes além das indicadas aqui.

Teclado HID e página do teclado (0x07)

Página genérica para computadores HID (0x01)

Página do cliente HID (0x0c)

Outros mapeamentos não HID

Esses mapeamentos descrevem funções que não aparecem no HID, mas para as quais o Linux os códigos de tecla.

Chaves legadas sem suporte

Esses mapeamentos apareciam em versões anteriores do Android, mas eram inconsistentes com HID ou códigos de chave Linux não padrão usados. Eles não são mais compatíveis.

Observações

1. O código de tecla do Android associado a métodos alfanuméricos e simbólicos podem variar de acordo com o layout e o idioma do teclado. Por motivos históricos, os códigos de verificação físicos e o uso de HID associadas a teclas em um teclado são frequentemente definidas de maneira mesmo que os rótulos impressos nessas chaves possam variar de um de uma linguagem para outra.

   Em um teclado em inglês americano (QWERTY), a tecla alfabética no canto superior esquerdo é rotulado como Q. Em um teclado francês (AZERTY), a tecla na mesma posição é identificada como A. Apesar do rótulo, nos dois teclados, a chave alfabética no canto superior esquerdo é chamada de uso do HID 0x07 0x0014 que é mapeado para o código de tecla do Linux KEY_Q.

   Quando o Android estiver configurado com um layout de teclado em inglês americano, o código de tecla do Linux KEY_Q será mapeado para o código de tecla do Android; KEYCODE_Q e produzirá os caracteres 'Q' e "q". No entanto, quando o Android está configurado com um layout de teclado francês, o código de tecla do Linux KEY_Q será mapeado para o código de tecla do Android KEYCODE_A e produzirá os caracteres 'A' e "a".

   O código de chave do Android costuma refletir as definições a interpretação da chave. Portanto, um código de tecla Android diferente pode ser usados em diferentes idiomas.

2. 0x0c 0x022f AC Zoom é definido no HID como um controle linear, mas o kernel a mapeia como uma chave, o que provavelmente está incorreto.

3. As teclas de função KEY_FN_* do Linux são associadas a uma códigos de teclas, mas são enviados com o estado meta META_FUNCTION bit definido como verdadeiro.

4. Antes do Android Ice Cream Sandwich 4.0, o layout de chave padrão continham mapeamentos para alguns códigos de teclas extras que não foram definidos nos cabeçalhos do kernel do Linux principal. Desde então, esses mapeamentos porque esses códigos de tecla anteriormente indefinidos já que receberam significados diferentes em versões mais recentes do kernel do Linux.

Fontes

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