Tastaturgeräte

Android unterstützt eine Vielzahl von Tastaturgeräten, einschließlich Spezialfunktionen. Tastaturen (Lautstärke- und Ein/Aus-Taste), kompakte eingebettete QWERTY-Tastaturen und externen Tastaturen im PC-Stil mit vollem Funktionsumfang.

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

Tastaturklassifizierung

Ein Eingabegerät wird als Tastatur klassifiziert, wenn eines der folgenden Kriterien zutrifft: Bedingungen gelten:

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

• Das Eingabegerät meldet das Vorhandensein von Linux-Schlüsselcodes, die auf Joysticks verwendet werden. und Gamepads, darunter BTN_0 bis BTN_9, BTN_TRIGGER bis BTN_DEAD, oder BTN_A bis BTN_THUMBR.

Joysticks werden derzeit als Tastaturen eingestuft, da Joystick- und Gamepad-Tasten werden von EV_KEY-Ereignissen auf die gleiche Weise gemeldet wie Tastaturtasten. Das heißt: Joysticks und Gamepads nutzen ebenfalls Keymap-Dateien für die Konfiguration.

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

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

• Wenn das Eingabegerät Tasten hat, die KEYCODE_Q zugeordnet sind, ist der wird davon ausgegangen, dass das Gerät eine alphabetische Wähltastatur hat (im Gegensatz zu einer numerischen Tastatur). Die Funktion für die alphabetische Wähltastatur wird in der Ressource Configuration gemeldet -Objekt als KEYBOARD_QWERTY.

• Wenn das Eingabegerät Tasten hat, die KEYCODE_DPAD_UP zugeordnet sind, KEYCODE_DPAD_DOWN, KEYCODE_DPAD_LEFT, KEYCODE_DPAD_RIGHT und KEYCODE_DPAD_CENTER (alle müssen vorhanden sein), wird das Gerät als eine Richtungstasten haben. Die Funktion für die Richtungstasten wird in der Ressource Configuration gemeldet -Objekt als NAVIGATION_DPAD.

• Wenn das Eingabegerät Tasten hat, die KEYCODE_BUTTON_A zugeordnet sind oder andere mit dem Gamepad zusammenhängende Tasten, wird davon ausgegangen, dass das Gerät ein Gamepad hat.

Anforderungen an Tastaturtreiber

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

2. Tastaturtreiber sollten EV_KEY verwenden, um Tastendrücke zu melden, und einen Wert verwenden 0 gibt an, dass ein Schlüssel freigegeben wird, und der Wert 1 gibt an, eine Taste gedrückt wird und ein Wert größer oder gleich 2, wird der Schlüssel automatisch wiederholt.

3. Android führt seine eigenen Tastaturwiederholungen aus. Funktion zur automatischen Wiederholung sollte im Treiber deaktiviert sein.

4. Optional können die Tastaturtreiber die HID-Nutzung oder den Low-Level-Scan angeben indem Sie EV_MSC mit MSC_SCANCODE und einem Wert senden, der die Nutzung angibt oder Code scannen, wenn die Taste gedrückt wird. Diese Informationen sind derzeit nicht die von Android verwendet werden.

5. Tastaturtreiber sollten die Einstellung der LED-Status unterstützen, wenn EV_LED geschrieben wird auf das Gerät übertragen. Der hid-input-Treiber übernimmt das automatisch. Zum Zeitpunkt der Erstellung dieses Dokuments nutzt Android LED_CAPSLOCK, LED_SCROLLLOCK, und LED_NUMLOCK. Diese LEDs müssen nur unterstützt werden, wenn die die entsprechenden Kontrollleuchten hat.

6. Tastaturtreiber für eingebettete Tastaturen (z. B. bei Verwendung einer GPIO-Matrix) EV_KEY-Ereignisse mit dem Wert 0 für alle Schlüssel senden, wenn das Gerät in den Ruhemodus wechselt. Andernfalls können Schlüssel stecken fest und wiederholt sich automatisch für immer.

Tastatursteuerung

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

1. EventHub liest Rohereignisse aus dem evdev-Treiber und ordnet Linux-Schlüsselcodes zu (manchmal auch als Scan-Codes bezeichnet) in Android-Schlüsselcodes mithilfe der Key Layout Map der Tastatur.

2. InputReader verarbeitet die Rohereignisse und aktualisiert den Status des Metaschlüssels. Wenn beispielsweise die linke Umschalttaste gedrückt wird, Die META_SHIFT_LEFT_ON- und META_SHIFT_ON-Bits entsprechend festlegen oder zurücksetzen.

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

4. InputDispatcher fragt das WindowManagerPolicy, was mit dem Schlüssel geschehen soll durch Aufrufen von WindowManagerPolicy.interceptKeyBeforeQueueing. Diese Methode ist Teil eines kritischen Pfads, der für den Ruhemodus des Geräts verantwortlich ist, bestimmte Tasten gedrückt werden. EventHub hält effektiv einen Wakelock um sicherzustellen, dass sie vollständig ausgeführt wird.

5. Wenn gerade ein InputFilter verwendet wird, weist ihm InputDispatcher einen den Schlüssel zu nutzen oder zu transformieren. Mit dem InputFilter können Sie systemweite Richtlinien zur Barrierefreiheit auf unterer Ebene.

6. InputDispatcher stellt den Schlüssel zur Verarbeitung im Weiterleitungsthread in die Warteschlange.

7. Wenn InputDispatcher den Schlüssel aus der Warteschlange entfernt, wird der WindowManagerPolicy eine zweite Möglichkeit, das Schlüsselereignis abzufangen, indem der Aufruf WindowManagerPolicy.interceptKeyBeforeDispatching Diese Methode verarbeitet Systemdaten, Tastenkombinationen und anderen Funktionen.

8. InputDispatcher identifiziert dann das Schlüsselereignisziel (das fokussierte Fenster). und wartet, bis sie bereit sind. Dann liefert InputDispatcher Schlüsselereignis an die Anwendung übergeben.

9. Innerhalb der Anwendung zieht das Schlüsselereignis die Ansichtshierarchie nach unten weiter, fokussierte Ansicht für das Senden von Schlüsseln vor dem IME.

10. Wenn das Schlüsselereignis bei der Weiterleitung vor dem IME nicht verarbeitet wird und ein IME verwendet wird, wird der Schlüsselereignis an den IME übermittelt.

11. Wenn das Schlüsselereignis nicht vom IME verarbeitet wurde, wird das Schlüsselereignis weitergegeben von der Ansichtshierarchie zur fokussierten Ansicht für die standardmäßige Schlüsselfreigabe herunter.

12. Die Anwendung gibt an InputDispatcher zurück, ob der Schlüssel Ereignis verarbeitet wurde. Wenn das Ereignis nicht verarbeitet wurde, wird der InputDispatcher ruft WindowManagerPolicy.dispatchUnhandledKey auf, um ein Fallback anzuwenden verhalten. Je nach Fallback-Aktion wird der Weiterleitungszyklus für Schlüsselereignisse möglicherweise neu gestartet mit einem anderen Schlüsselcode. Wenn eine Anwendung zum Beispiel KEYCODE_ESCAPE gesetzt, kann das System das Schlüsselereignis stattdessen als KEYCODE_BACK noch einmal senden.

Tastaturkonfiguration

Das Tastaturverhalten wird durch das Tastenlayout, die Tastenzeichen Karten- und Eingabegerätekonfiguration.

In den folgenden Abschnitten finden Sie weitere Informationen zu den Dateien, die an der Tastaturkonfiguration teilnehmen:

• Wichtige Layoutdateien
• Zuordnungsdateien für Schlüsselzeichen
• Konfigurationsdateien für die Eingabegeräte

Properties

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

Tastatur.layout

Definition: keyboard.layout = <name>

Gibt den Namen der Schlüssellayoutdatei an, die mit dem Eingabegerät verknüpft ist. ohne die Erweiterung .kl. Wenn diese Datei nicht gefunden wird, wird stattdessen das Standard-Tastenlayout verwendet.

Leerzeichen im Namen werden bei der Suche in Unterstriche umgewandelt.

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

Tastatur.characterMap

Definition: keyboard.characterMap = <name>

Gibt den Namen der Schlüsselzeichenzuordnungsdatei an, die mit dem Eingabegerät verknüpft ist, ohne die Erweiterung .kcm. Wenn diese Datei nicht gefunden wird, wird stattdessen die Standardschlüsselzeichenzuordnung verwendet.

Leerzeichen im Namen werden bei der Suche in Unterstriche umgewandelt.

Weitere Informationen finden Sie in der Dokumentation zur Schlüsselzeichenzuordnungsdatei.

Tastatur.orientationAware

Definition: keyboard.orientationAware = 0 | 1

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

• Lautet der Wert 1, werden die Richtungstasten gedreht, wenn die zugehörigen Änderungen der Displayausrichtung.

• Wenn der Wert 0 ist, kann die Tastatur die Ausrichtung nicht ändern.

Der Standardwert ist 0.

Die Ausrichtungserkennung wird verwendet, um die Drehung von Tasten auf der Tastatur zu unterstützen. wie auf dem Motorola Droid. Zum Beispiel, wenn das Gerät gedreht wird. im Uhrzeigersinn um 90 Grad von ihrer natürlichen Ausrichtung entfernt, entspricht KEYCODE_DPAD_UP neu zugeordnet, um KEYCODE_DPAD_RIGHT zu erzeugen, seitdem „up“ Taste zeigt am Ende 'rechts' wenn das Gerät in dieser Ausrichtung gehalten wird.

Tastatur.integriert

Definition: keyboard.builtIn = 0 | 1

Gibt an, ob die Tastatur integriert ist oder nicht Tastatur.

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

Der eingebauten Tastatur wird immer die Geräte-ID 0 zugewiesen. Andere Tastaturen , die nicht integriert sind, erhalten eindeutige Geräte-IDs ungleich null.

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

Eine Spezialtastatur (die mit einer Tastenbelegung ein Typ von SPECIAL_FUNCTION) nie als integrierte Tastatur registriert, unabhängig von der Einstellung dieser Property. Das liegt daran, dass eine spezielle Funktion Die Tastatur ist standardmäßig nicht für die allgemeine Eingabe gedacht.

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 angenommen, dass alle Tastaturen physisch angebracht sind und die Ausrichtung erkannt haben. Standardeinstellung Tastenlayout und Schlüsselzeichenzuordnung hatten den Namen qwerty statt Generic. Der Schlüssel Das Character Map-Format war auch sehr unterschiedlich und das Framework Vollständige Tastaturen im PC-Stil oder externe Tastaturen

Wenn Sie Geräte auf Honeycomb upgraden, achten Sie darauf, die erforderlichen Konfigurations- und Schlüsselzuordnungsdateien.

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

Das System verweist auf Schlüssel mit verschiedenen Kennungen, je nachdem, Abstraktionsebene.

Bei HID-Geräten ist jedem Schlüssel eine HID-Nutzung zugeordnet. Das Linux-hid-input Treiber und zugehörige anbieter- und gerätespezifische HID-Treiber für das Parsen von HID-Berichten und die Zuordnung von HID-Nutzungen zu Linux-Schlüsselcodes.

Während Android EV_KEY-Ereignisse aus dem Linux-Kernel liest, in den entsprechenden Android-Schlüsselcode gemäß Key-Layout-Datei des Geräts.

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

Beachten Sie, dass die HID-Nutzungsinformationen weder von Android an Anwendungen übergeben werden.

Codetabellen

In den folgenden Tabellen sehen Sie, wie HID-Nutzungen, Linux-Schlüsselcodes und Android Schlüsselcodes haben einen Bezug zueinander.

Die LKC-Spalte gibt den Linux-Schlüsselcode in hexadezimaler Form an.

Die Spalte AKC gibt den Android-Schlüsselcode in hexadezimaler Form an.

Die Spalte Notizen bezieht sich auf Notizen, die nach der Tabelle veröffentlicht werden.

In der Spalte „Version“ wird die erste Version der Android-Plattform angegeben. um diesen Schlüssel in seine Standardschlüsselzuordnung aufzunehmen. Mehrere Zeilen sind in Fällen, in denen sich die Standardschlüsselzuordnung von Version zu Version geändert hat. Die älteste angegebene Version ist 1.6.

• In Gingerbread (2.3) und früheren Releases war die Standardschlüsselzuordnung qwerty.kl Diese Tastenbelegung war nur für die Verwendung mit dem Android- Emulator. Er war nicht zur Unterstützung beliebiger externen Tastaturen verwenden. Dennoch haben einige OEMs Bluetooth-Geräte die Tastatur unterstützt, und setzte qwerty.kl darauf, die erforderlichen Tastaturbelegungen bereitstellen. Dementsprechend sind diese ältere Zuordnungen könnten für OEMs von Interesse sein, Peripheriegeräten für diese Geräte an. Die Zuordnungen deutlich von den aktuellen unterscheiden, in Bezug auf die Verarbeitung des HOME-Schlüssels. Es wird empfohlen, dass alle neuen Peripheriegeräte nach Honeycomb oder höher entwickelt werden, Letzte Schlüsselbelegungen (d. h. Standard-HID)

• Ab Honeycomb (3.0) ist die Standardschlüsselbelegung Generic.kl. Diese Tastenbelegung wurde für die Unterstützung von Tastaturen im PC-Stil entwickelt. Die meisten Funktionen der Standard-HID-Tastaturen sollten problemlos funktionieren. der Verpackung.

Die Schlüsselcodezuordnung kann je nach Linux-Kernel- und Android-Version variieren. Wenn bekannt ist, dass Änderungen an den Android-Standardschlüsselzuordnungen vorgenommen wurden, werden sie in der Spalte „Version“ angezeigt.

Für gerätespezifische HID-Treiber und Schlüsselkarten können unterschiedliche Zuordnungen angewendet werden als hier angegeben.

HID-Seite mit Tastatur und Tastenfeld (0x07)

Allgemeine HID-Desktop-Seite (0x01)

HID-Nutzerseite (0x0c)

Zusätzliche Zuordnungen ohne HID

Diese Zuordnungen beschreiben Funktionen, die nicht in HID angezeigt werden, für die Linux Schlüsselcodes vorhanden sind.

Nicht unterstützte alte Schlüssel

Diese Zuordnungen erschienen in früheren Android-Versionen, stimmten aber nicht mit den HID oder nicht standardmäßige Linux-Schlüsselcodes verwendet wurden. Sie werden nicht mehr unterstützt.

Hinweise

1. Der Android-Schlüsselcode, der dem allgemeinen alphanumerischen und symbolischen Code Die Tasten können je nach Tastaturlayout und Sprache variieren. Aus historischen Gründen wurden physische Scancodes und HID-Nutzung die Tasten auf einer Tastatur zugeordnet sind, werden oft positionell definiert. Auch wenn die auf diesen Schlüsseln aufgedruckten Labels von einem in eine andere Sprache zu übersetzen.

   Auf einer US-Tastatur (QWERTY) ist die linke obere Buchstabentaste mit der Beschriftung Q. Auf einer französischen Tastatur (AZERTY) drücken Sie die Taste ist mit „A“ beschriftet. Trotz der Beschriftung ist das Symbol auf beiden Tastaturen wird unter Verwendung der HID-Nutzung 0x07 0x0014, die dem Linux-Schlüsselcode KEY_Q zugeordnet ist.

   Wenn Android mit einem US-englischen Tastaturlayout konfiguriert ist, gilt Folgendes: der Linux-Schlüsselcode KEY_Q wird dem Android-Schlüsselcode zugeordnet KEYCODE_Q und erzeugt die Zeichen 'Q' und "q". Wenn Android jedoch mit einem französischen Tastaturlayout konfiguriert ist, wird der Linux-Schlüsselcode KEY_Q dem Android-Schlüsselcode KEYCODE_A und erzeugt die Zeichen 'A' und 'a'.

   Der Android-Schlüsselcode spiegelt in der Regel den sprachspezifischen Interpretation des Schlüssels, sodass ein anderer Android-Schlüsselcode für verschiedene Sprachen verwendet werden.

2. 0x0c 0x022f AC Zoom ist in HID als lineares Steuerelement definiert, aber ordnet er sie als Schlüssel zu, was wahrscheinlich falsch ist.

3. Die Linux-Funktionstasten KEY_FN_* sind einfachen Schlüsselcodes, werden aber mit dem Metastatus META_FUNCTION gesendet Bit auf "true" gesetzt.

4. Vor Android Ice Cream Sandwich 4.0 war das Standard-Schlüssellayout Zuordnungen für einige zusätzliche Schlüsselcodes enthielten, die nicht definiert wurden in den Linux-Kernel-Headern von Mainline. Diese Zuordnungen haben seit da diese zuvor undefinierten Schlüsselcodes da sie in neueren Versionen verschiedene Bedeutungen des Linux-Kernels.

Quellen

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