Tastaturgeräte

Android unterstützt eine Vielzahl von Tastaturgeräten, darunter Tastaturen mit Sonderfunktionen (Lautstärke- und Leistungssteuerung), kompakte integrierte QWERTZ-Tastaturen und voll ausgestattete externe Tastaturen im PC-Stil.

In diesem Dokument werden nur physische Tastaturen beschrieben. Informationen zu Softtastaturen (Eingabemethoden-Editoren) finden Sie im Android SDK.

Tastaturklassifizierung

Ein Eingabegerät wird als Tastatur klassifiziert, wenn eine der folgenden Bedingungen zutrifft:

• Das Eingabegerät meldet das Vorhandensein aller auf Tastaturen verwendeten Linux-Tastencodes, einschließlich 0 bis 0xff oder KEY_OK bis KEY_MAX .

• Das Eingabegerät meldet das Vorhandensein aller Linux-Tastencodes, die auf Joysticks und Gamepads verwendet werden, einschließlich BTN_0 bis BTN_9 , BTN_TRIGGER bis BTN_DEAD oder BTN_A bis BTN_THUMBR .

Joysticks werden derzeit als Tastaturen klassifiziert, da Joystick- und Gamepad-Tasten von EV_KEY Ereignissen auf die gleiche Weise gemeldet werden wie Tastaturtasten. So nutzen Joysticks und Gamepads auch Key-Map-Dateien zur Konfiguration.

Sobald ein Eingabegerät als Tastatur klassifiziert wurde, lädt das System die Konfigurationsdatei des Eingabegeräts und das Tastaturlayout für die Tastatur.

Das System versucht dann, weitere Eigenschaften des Geräts zu ermitteln.

• Wenn das Eingabegerät über Tasten verfügt, die KEYCODE_Q zugeordnet sind, wird davon ausgegangen, dass das Gerät über eine alphabetische Tastatur (im Gegensatz zu einer numerischen) verfügt. Die alphabetische Tastaturfunktion wird im Configuration als KEYBOARD_QWERTY gemeldet.

• Wenn das Eingabegerät über Tasten verfügt, die KEYCODE_DPAD_UP , KEYCODE_DPAD_DOWN , KEYCODE_DPAD_LEFT , KEYCODE_DPAD_RIGHT und KEYCODE_DPAD_CENTER zugeordnet sind (alle müssen vorhanden sein), wird davon ausgegangen, dass das Gerät über eine Richtungstastatur verfügt. Die Richtungstastaturfunktion wird im Configuration als NAVIGATION_DPAD gemeldet.

• Wenn das Eingabegerät über Tasten verfügt, die KEYCODE_BUTTON_A oder anderen Gamepad-bezogenen Tasten zugeordnet sind, wird davon ausgegangen, dass das Gerät über ein Gamepad verfügt.

Anforderungen an den Tastaturtreiber

1. Tastaturtreiber sollten nur Tastencodes für die Tasten registrieren, die sie tatsächlich unterstützen. Das Registrieren überschüssiger Tastencodes kann den Geräteklassifizierungsalgorithmus verwirren oder dazu führen, dass das System die unterstützten Tastaturfunktionen des Geräts falsch erkennt.

2. Tastaturtreiber sollten EV_KEY verwenden, um Tastendrücke zu melden, wobei ein Wert von 0 verwendet wird, um anzuzeigen, dass eine Taste losgelassen wird, ein Wert von 1 , um anzuzeigen, dass eine Taste gedrückt wird, und ein Wert größer oder gleich 2 , um anzuzeigen, dass die Taste losgelassen wird automatisch wiederholt.

3. Android führt eine eigene Tastaturwiederholung durch. Die automatische Wiederholungsfunktion sollte im Treiber deaktiviert sein.

4. Tastaturtreiber können optional die HID-Nutzung oder den Low-Level-Scancode anzeigen, indem sie EV_MSC mit MSC_SCANCODE und einem Wert senden, der die Verwendung oder den Scancode angibt, wenn die Taste gedrückt wird. Diese Informationen werden derzeit nicht von Android verwendet.

5. Tastaturtreiber sollten das Festlegen von LED-Zuständen unterstützen, wenn EV_LED auf das Gerät geschrieben wird. Der hid-input Treiber erledigt dies automatisch. Zum Zeitpunkt des Verfassens dieses Artikels verwendet Android LED_CAPSLOCK , LED_SCROLLLOCK und LED_NUMLOCK . Diese LEDs müssen nur dann unterstützt werden, wenn die Tastatur tatsächlich über die zugehörigen Anzeigeleuchten verfügt.

6. Tastaturtreiber für eingebettete Tastaturen (z. B. mit einer GPIO-Matrix) sollten sicherstellen, dass EV_KEY Ereignisse mit dem Wert 0 für alle Tasten gesendet werden, die noch gedrückt werden, wenn das Gerät in den Ruhezustand wechselt. Andernfalls kann es passieren, dass die Tasten hängen bleiben und die automatische Wiederholung für immer erfolgt.

Tastaturbedienung

Im Folgenden finden Sie eine kurze Zusammenfassung der Tastaturbedienung unter Android.

1. Der EventHub liest Rohereignisse vom evdev Treiber und ordnet Linux-Tastencodes (manchmal auch als Scan-Codes bezeichnet) anhand der Tastenbelegungszuordnung der Tastatur Android-Tastencodes zu.

2. Der InputReader konsumiert die Rohereignisse und aktualisiert den Metaschlüsselstatus. Wenn beispielsweise die linke Umschalttaste gedrückt oder losgelassen wird, setzt oder setzt der Leser die Bits META_SHIFT_LEFT_ON und META_SHIFT_ON entsprechend.

3. Der InputReader benachrichtigt den InputDispatcher über das Schlüsselereignis.

4. Der InputDispatcher fragt die WindowManagerPolicy was mit dem Schlüsselereignis geschehen soll, indem er WindowManagerPolicy.interceptKeyBeforeQueueing aufruft. Diese Methode ist Teil eines kritischen Pfads, der dafür verantwortlich ist, das Gerät aufzuwecken, wenn bestimmte Tasten gedrückt werden. Der EventHub hält entlang dieses kritischen Pfads effektiv eine Wecksperre, um sicherzustellen, dass er vollständig ausgeführt wird.

5. Wenn derzeit ein InputFilter verwendet wird, gibt ihm der InputDispatcher die Möglichkeit, den Schlüssel zu konsumieren oder umzuwandeln. Der InputFilter kann verwendet werden, um systemweite Barrierefreiheitsrichtlinien auf niedriger Ebene zu implementieren.

6. Der InputDispatcher stellt den Schlüssel zur Verarbeitung im Dispatch-Thread in die Warteschlange.

7. Wenn der InputDispatcher den Schlüssel aus der Warteschlange entfernt, gibt er der WindowManagerPolicy eine zweite Chance, das Schlüsselereignis abzufangen, indem er WindowManagerPolicy.interceptKeyBeforeDispatching aufruft. Diese Methode verarbeitet Systemverknüpfungen und andere Funktionen.

8. Der InputDispatcher identifiziert dann das Schlüsselereignisziel (das fokussierte Fenster) und wartet darauf, dass es bereit ist. Anschließend übermittelt der InputDispatcher das Schlüsselereignis an die Anwendung.

9. Innerhalb der Anwendung wird das Schlüsselereignis entlang der Ansichtshierarchie an die fokussierte Ansicht weitergegeben, um den Schlüsselversand vor dem IME zu ermöglichen.

10. Wenn das Schlüsselereignis im Vor-IME-Versand nicht behandelt wird und ein IME verwendet wird, wird das Schlüsselereignis an den IME übermittelt.

11. Wenn das Schlüsselereignis nicht vom IME genutzt wurde, wird das Schlüsselereignis in der Ansichtshierarchie nach unten an die fokussierte Ansicht für den Standardschlüsselversand weitergegeben.

12. Die Anwendung meldet dem InputDispatcher zurück, ob das Schlüsselereignis verbraucht wurde. Wenn das Ereignis nicht verbraucht wurde, ruft der InputDispatcher WindowManagerPolicy.dispatchUnhandledKey auf, um ein „Fallback“-Verhalten anzuwenden. Abhängig von der Fallback-Aktion kann der Schlüsselereignis-Versandzyklus mit einem anderen Schlüsselcode neu gestartet werden. Wenn eine Anwendung beispielsweise KEYCODE_ESCAPE nicht verarbeitet, sendet das System das Schlüsselereignis möglicherweise stattdessen als KEYCODE_BACK weiter.

Tastaturkonfiguration

Das Tastaturverhalten wird durch das Tastenlayout der Tastatur, die Tastenbelegung und die Konfiguration des Eingabegeräts bestimmt.

Weitere Informationen zu den Dateien, die an der Tastaturkonfiguration beteiligt sind, finden Sie in den folgenden Abschnitten:

• Schlüssellayoutdateien
• Schlüsselkartendateien
• Konfigurationsdateien für Eingabegeräte

Eigenschaften

Die folgenden Konfigurationseigenschaften für Eingabegeräte werden für Tastaturen verwendet.

Tastaturbelegung

Definition: keyboard.layout = <Name>

Gibt den Namen der Tastenlayoutdatei an, die dem Eingabegerät zugeordnet ist, ohne die Erweiterung .kl . Wenn diese Datei nicht gefunden wird, verwendet das Eingabesystem stattdessen das Standardtastenlayout.

Leerzeichen im Namen werden bei der Suche in Unterstriche umgewandelt.

Weitere Einzelheiten finden Sie in der Dokumentation zur Schlüssellayoutdatei.

keyboard.characterMap

Definition: keyboard.characterMap = <name>

Gibt den Namen der Tastenzeichentabellendatei an, die dem Eingabegerät zugeordnet ist, mit Ausnahme der Erweiterung .kcm . Wenn diese Datei nicht gefunden wird, verwendet das Eingabesystem stattdessen die Standard-Tastenzeichentabelle.

Leerzeichen im Namen werden bei der Suche in Unterstriche umgewandelt.

Weitere Einzelheiten finden Sie in der Dokumentation zur Tastenzuordnungsdatei.

keyboard.orientationAware

Definition: keyboard.orientationAware = 0 | 1

Gibt an, ob die Tastatur auf Änderungen der Anzeigeausrichtung reagieren soll.

• Wenn der Wert 1 ist, werden die Richtungstasten des Tastenfelds gedreht, wenn sich die zugehörige Anzeigeausrichtung ändert.

• Wenn der Wert 0 ist, ist die Tastatur immun gegen Änderungen der Anzeigeausrichtung.

Der Standardwert ist 0 .

Die Orientierungserkennung wird verwendet, um die Drehung der Richtungstasten des Tastenfelds zu unterstützen, beispielsweise beim Motorola Droid. Wenn das Gerät beispielsweise um 90 Grad von seiner natürlichen Ausrichtung im Uhrzeigersinn gedreht wird, wird KEYCODE_DPAD_UP neu zugeordnet, um KEYCODE_DPAD_RIGHT zu erzeugen, da die Aufwärtstaste letztendlich nach „rechts“ zeigt, wenn das Gerät in dieser Ausrichtung gehalten wird.

keyboard.builtIn

Definition: keyboard.builtIn = 0 | 1

Gibt an, ob es sich bei der Tastatur um die integrierte (physisch angeschlossene) Tastatur handelt.

Der Standardwert ist 1 , wenn der Gerätename mit -keypad endet, andernfalls 0 .

Der integrierten Tastatur wird immer die Geräte-ID 0 zugewiesen. Anderen Tastaturen, die nicht integriert sind, werden eindeutige Geräte-IDs ungleich Null zugewiesen.

Die Verwendung einer ID von 0 für die integrierte Tastatur ist wichtig, um die Kompatibilität mit dem Feld KeyCharacterMap.BUILT_IN_KEYBOARD aufrechtzuerhalten, das die ID der integrierten Tastatur angibt und den Wert 0 hat. Dieses Feld ist in der API veraltet, wird aber möglicherweise noch von älteren Anwendungen verwendet.

Eine Sonderfunktionstastatur (eine, deren Tastenbelegung einen Typ von SPECIAL_FUNCTION angibt) wird unabhängig von der Einstellung dieser Eigenschaft niemals als integrierte Tastatur registriert. Dies liegt daran, dass eine Tastatur mit Sonderfunktionen per Definition nicht für die Verwendung zum allgemeinen Tippen gedacht ist.

Beispielkonfigurationen

# 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

Kompatibilitätshinweise

Vor Honeycomb verwendete der Tastatureingabe-Mapper keine Konfigurationseigenschaften. Es wurde davon ausgegangen, dass alle Tastaturen physisch befestigt sind und ihre Ausrichtung erkennen kann. Das Standard-Tastenlayout und die Tastenzeichentabelle wurden qwerty anstelle von Generic genannt. Auch das Format der Tastenzuordnung war sehr unterschiedlich und das Framework unterstützte weder PC-ähnliche Volltastaturen noch externe Tastaturen.

Stellen Sie beim Upgrade von Geräten auf Honeycomb sicher, dass Sie die erforderlichen Konfigurations- und Tastenzuordnungsdateien erstellen oder aktualisieren.

HID-Verwendungen, Linux-Schlüsselcodes und Android-Schlüsselcodes

Das System bezieht sich auf Schlüssel, die je nach Abstraktionsebene mehrere unterschiedliche Bezeichner verwenden.

Bei HID-Geräten ist jedem Schlüssel eine HID-Nutzung zugeordnet. Der Linux- hid-input Treiber und zugehörige hersteller- und gerätespezifische HID-Treiber sind für die Analyse von HID-Berichten und die Zuordnung von HID-Verwendungen zu Linux-Schlüsselcodes verantwortlich.

Während Android EV_KEY Ereignisse vom Linux-Kernel liest, übersetzt es jeden Linux-Tastencode entsprechend der Tastenlayoutdatei des Geräts in den entsprechenden Android-Tastencode.

Wenn das Schlüsselereignis an eine Anwendung gesendet wird, meldet die Instanz android.view.KeyEvent den Linux-Schlüsselcode als Wert von getScanCode() und den Android-Schlüsselcode als Wert von getKeyCode() . Für die Zwecke des Frameworks ist nur der Wert von getKeyCode() wichtig.

Beachten Sie, dass die HID-Nutzungsinformationen nicht von Android selbst verwendet oder an Anwendungen weitergegeben werden.

Codetabellen

Die folgenden Tabellen zeigen, wie HID-Nutzungen, Linux-Tastencodes und Android-Tastencodes miteinander zusammenhängen.

Die Spalte LKC gibt den Linux-Schlüsselcode im Hexadezimalformat an.

Die AKC-Spalte gibt den Android-Schlüsselcode im Hexadezimalformat an.

Die Spalte „Notizen“ bezieht sich auf Notizen, die nach der Tabelle gepostet werden.

Die Spalte „Version“ gibt die erste Version der Android-Plattform an, die diesen Schlüssel in ihre Standardschlüsselzuordnung aufgenommen hat. In Fällen, in denen sich die Standard-Tastenzuordnung zwischen den Versionen geändert hat, werden mehrere Zeilen angezeigt. Die älteste angegebene Version ist 1.6.

• In Gingerbread (2.3) und früheren Versionen war die Standardtastenzuordnung qwerty.kl . Diese Tastenbelegung war nur für die Verwendung mit dem Android-Emulator gedacht und nicht zur Unterstützung beliebiger externer Tastaturen. Dennoch haben einige OEMs der Plattform Bluetooth-Tastaturunterstützung hinzugefügt und sich auf qwerty.kl verlassen, um die erforderlichen Tastaturzuordnungen bereitzustellen. Daher könnten diese älteren Zuordnungen für OEMs von Interesse sein, die Peripheriegeräte für diese speziellen Geräte bauen. Beachten Sie, dass sich die Zuordnungen erheblich von den aktuellen unterscheiden, insbesondere im Hinblick auf die Behandlung der HOME Taste. Es wird empfohlen, alle neuen Peripheriegeräte gemäß Honeycomb oder neueren Schlüsselkarten (d. h. Standard-HID) zu entwickeln.

• Ab Honeycomb (3.0) ist die Standardschlüsselzuordnung Generic.kl . Diese Tastenbelegung wurde für die Unterstützung vollständiger PC-Tastaturen entwickelt. Die meisten Funktionen von Standard-HID-Tastaturen sollten sofort funktionieren.

Die Tastencodezuordnung kann je nach Linux-Kernel- und Android-Version variieren. Wenn bekannt ist, dass an den Android-Standardtastenzuordnungen Änderungen vorgenommen wurden, werden diese in der Versionsspalte angezeigt.

Gerätespezifische HID-Treiber und Tastenzuordnungen können andere Zuordnungen als die hier angegebenen anwenden.

HID-Tastatur- und Tastaturseite (0x07)

HID generische Desktop-Seite (0x01)

HID-Verbraucherseite (0x0c)

Zusätzliche nicht versteckte Zuordnungen

Diese Zuordnungen beschreiben Funktionen, die nicht in HID erscheinen, sondern für die Linux -Schlüsselcodes existieren.

Legacy nicht unterstützte Schlüssel

Diese Zuordnungen traten in früheren Android-Versionen auf, standen jedoch nicht mit HID oder verwendeten nicht standardmäßigen Linux-Schlüsselcodes wider. Sie werden nicht mehr unterstützt.

Anmerkungen

1. Der Android -Schlüsselcode, der mit gemeinsamen alphanumerischen und symbolischen Tasten zugeordnet ist, kann je nach Tastaturlayout und Sprache variieren. Aus historischen Gründen werden die mit Tasten auf einer Tastatur verbundenen physischen Scancodes und versteckten Verwendungen häufig positionell definiert, obwohl die auf diesen Tasten gedruckten Etiketten von einer Sprache zu einer anderen variieren können.

   Auf einer US-amerikanischen englischen (QWERTY) -Tastatur ist die obere links alphabetische Taste mit der Bezeichnung von Q. Auf einer französischen (asery) Tastatur ist die Taste in derselben Position mit A. trotz des Etikett Es wird auf die HID -Nutzung verwiesen 0x07 0x0014, die dem Linux -Key -Code -Key_Q zugeordnet ist.

   Wenn Android mit einem US -amerikanischen Englisch -Tastatur -Layout konfiguriert wird, wird der LINUX -Tastaturcode -Key_Q dem Android -Tastatur -Code -KeyCode_Q zugeordnet und produziert die Zeichen 'Q' und 'Q'. Wenn Android jedoch mit einem französischen Tastaturlayout konfiguriert ist, wird der Linux -Taste -Code -Key_Q dem Android -Tastencode -KeyCode_A zugeordnet und produziert die Zeichen 'a' und 'a'.

   Der Android-Schlüsselcode spiegelt typischerweise die sprachspezifische Interpretation des Schlüssels wider, sodass für verschiedene Sprachen ein anderer Android-Schlüsselcode verwendet werden kann.

2. 0x0c 0x022f AC Zoom wird in der HID als lineare Steuerung definiert, aber der Kernel kartiert ihn als Schlüssel, was wahrscheinlich falsch ist.

3. Die Linux -Funktionstasten KEY_FN_* werden auf einfachere Schlüsselcodes abgebildet, aber mit dem auf true eingestellten Meta -Status -Bit META_FUNCTION versandt.

4. Vor Android Ice Cream Sandwich 4.0 enthielt das Standard -Schlüssellayout Zuordnungen für einige zusätzliche Schlüsselcodes, die in den Hauptkern -Kernel -Headern der Hauptlinie nicht definiert waren. Diese Zuordnungen wurden seitdem entfernt, da diesen zuvor undefinierten Schlüsselcodes seitdem unterschiedliche Bedeutungen in neueren Versionen des Linux -Kernels zugewiesen wurden.

Quellen

1. USB -HID -Nutzungstabellen v1.12
2. Linux 2.6.39 Kernel: Include/Linux/input.h, Treiber/HID/HID-Input.c
3. Android ICS: QWERTY.KL, Generic.kl, KeyEvent.java