Schlüssellayoutdateien

Schlüssellayoutdateien (.kl-Dateien) ordnen Linux-Schlüsselcodes und -Achsencodes zu in Android-Schlüsselcodes und Achsencodes umwandeln und zugehörige Richtlinien-Flags angeben. Gerätespezifische Schlüssellayoutdateien sind:

  • Erforderlich für interne (integrierte) Eingabegeräte mit Schlüsseln, einschließlich Sondertasten wie Lautstärke, Ein/Aus und Medientasten für das Headset.
  • Optional für andere Eingabegeräte, aber empfohlen für Spezialtastaturen und Joysticks.

Ist keine gerätespezifische Schlüssellayoutdatei verfügbar, wählt das System eine .

Standort

Die Schlüssellayoutdateien werden nach USB-Anbieter, Produkt (und optional der Version) aufgeschlüsselt. oder anhand des Gerätenamens eingeben. Die folgenden Pfade werden der Reihe nach verwendet:

  • /odm/usr/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
  • /vendor/usr/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
  • /system/usr/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
  • /data/system/devices/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
  • /odm/usr/keylayout/Vendor_XXXX_Product_XXXX.kl
  • /vendor/usr/keylayout/Vendor_XXXX_Product_XXXX.kl
  • /system/usr/keylayout/Vendor_XXXX_Product_XXXX.kl
  • /data/system/devices/keylayout/Vendor_XXXX_Product_XXXX.kl
  • /odm/usr/keylayout/DEVICE_NAME.kl
  • /vendor/usr/keylayout/DEVICE_NAME.kl
  • /system/usr/keylayout/DEVICE_NAME.kl
  • /data/system/devices/keylayout/DEVICE_NAME.kl
  • /odm/usr/keylayout/Generic.kl
  • /vendor/usr/keylayout/Generic.kl
  • /system/usr/keylayout/Generic.kl
  • /data/system/devices/keylayout/Generic.kl

Beim Erstellen eines Dateipfads, der den Gerätenamen enthält, werden alle Zeichen im Gerätenamen einen anderen Wert als '0'-'9', 'a'-'z', A–Z, - oder '_' durch '_'.

Generische Schlüssellayoutdatei

Das System stellt eine spezielle, integrierte generische Schlüssel-Layoutdatei namens Generic.kl Dieses Tastenlayout soll eine Vielzahl von Standardtastaturen und Joysticks verwenden. Den generischen Schlüssel nicht ändern Layout!

Syntax

Eine Schlüssellayoutdatei ist eine Nur-Text-Datei, die aus Schlüssel- oder Achsendeklarationen besteht. und Markierungen.

Schlüsseldeklarationen

Schlüsseldeklarationen bestehen aus dem Schlüsselwort key gefolgt von einem Linux- und der Name des Android-Schlüsselcodes oder die Schlüsselwortverwendung gefolgt von einem HID-Nutzung und Android-Schlüsselcodename. Die HID-Nutzung wird als 32-Bit- Ganzzahl, wobei die hohen 16 Bit für die HID-Nutzungsseite und die niedrigen 16 Bits für die HID-Nutzungs-ID steht. Auf jede Deklaration kann ein optionales Satz von durch Leerzeichen getrennten Richtlinien-Flags.

key 1     ESCAPE
key 114   VOLUME_DOWN
key 16    Q                 VIRTUAL
key usage 0x0c006F          BRIGHTNESS_UP

Die folgenden Richtlinien-Flags werden erkannt:

  • FUNCTION: Der Schlüssel sollte so interpretiert werden, als wäre die FUNCTION-Taste. die ebenfalls gedrückt wurden.
  • GESTURE: Schlüssel, der durch eine Nutzergeste, z. B. Handballen, generiert wird Touchscreen verwenden.
  • VIRTUAL: Der Schlüssel ist ein virtueller Softkey (kapazitive Taste). neben dem Haupt-Touchscreen. Dadurch wird eine spezielle Entprellungslogik aktiviert ist (siehe unten).

Achsendeklarationen

Achsendeklarationen bestehen jeweils aus dem Keyword axis, gefolgt von einem Linux-Achsencodenummer und -qualifizierer, die das Verhalten der Achse steuern einschließlich mindestens einem Android-Achsencodenamen.

Einfache Achsen

Eine einfache Achse ordnet einen Linux-Achsencode einem Android-Achsencodenamen zu. Die folgende Deklarationszuordnung ABS_X (gekennzeichnet durch 0x00) in AXIS_X (gekennzeichnet durch X).

axis 0x00 X

Wenn im obigen Beispiel der Wert von ABS_X 5 ist dann wird AXIS_X auf 5 gesetzt.

Geteilte Achsen

Eine geteilte Achse ordnet einen Linux-Achsencode zwei Android-Achsencodenamen zu, sodass Werte, die kleiner oder größer als ein Schwellenwert sind, werden auf zwei verschiedene Achsen aufgeteilt wenn sie zugeordnet sind. Diese Zuordnung ist nützlich, wenn eine einzelne physische Achse, die vom codiert das Gerät zwei verschiedene sich gegenseitig ausschließende logische Achsen.

Die folgende Deklaration ordnet Werte der ABS_Y-Achse zu (gekennzeichnet durch 0x01) in AXIS_GAS, wenn kleiner als 0x7f oder bis AXIS_BRAKE, wenn größer als 0x7f.

axis 0x01 split 0x7f GAS BRAKE

Wenn im obigen Beispiel der Wert von ABS_Y 0x7d ist dann wird AXIS_GAS auf 2 (0x7f - 0x7d) festgelegt und AXIS_BRAKE auf 0 festgelegt ist. Wenn dagegen der Wert von ABS_Y ist 0x83, dann ist AXIS_GAS festgelegt auf 0 und AXIS_BRAKE sind auf 4 festgelegt (0x83 - 0x7f) Wenn schließlich der Wert von ABS_Y gleich den Aufteilungswert von 0x7f, dann AXIS_GAS und AXIS_BRAKE sind auf 0 eingestellt.

Umgekehrte Achsen

Eine umgekehrte Achse kehrt das Vorzeichen des Achsenwerts um. Die folgenden -Deklaration ABS_RZ (gekennzeichnet durch 0x05) zu AXIS_BRAKE (gekennzeichnet durch BRAKE) und invertiert die indem Sie sie negieren.

axis 0x05 invert BRAKE

Wenn im obigen Beispiel der Wert von ABS_RZ 2 ist dann wird AXIS_BRAKE auf -2 gesetzt.

Option „Zentriert“

Ein Joystick-Gerät kann Eingabeereignisse aufgrund von Störfaktoren auch dann melden, wenn der Joystick nicht verwendet wird. Dieses Geräusch kommt in der Regel vom linken und/oder rechten Stick und führt dazu, dass der Fahrer einen Positionswert nahe 0 haben. Die „mittlere Ebene“ value gibt den Geräuschpegel an, der vom Controller im Ruhezustand zu erwarten ist.

Mit dem Linux-Eingabeprotokoll können Eingabegerätetreiber angeben, der mittlere Flat-Wert der Joystickachsen, aber nicht alle Treiber geben ihn an und einige falsche Werte. Zur Behebung dieses Problems kann auf eine Achsendeklaration folgt ein Option flat, die die Breite des Bereichs um den Mittelpunkt angibt Position der Achse, die als zentriert betrachtet werden soll.

Wenn beispielsweise ein Gerätetreiber Werte für AXIS_X zwischen 0 und 100 meldet, Dann wird 0 vom Android-Eingabesystem -1 und 100 1 zugeordnet. Der Mittelpunkt des Bereichs liegt in den nicht skalierten Koordinaten 50 und in den skalierten Koordinaten bei 0. Wenn ein flacher Wert gleich 10 ist, sollten die Entwickler davon ausgehen, dass jeder AXIS_X-Wert, der zwischen -0,1 und 0,1 (zwischen 40 und 60 in nicht skalierten Koordinaten) ist Rauschen. Diese Werte werden vom Joystick in Null.

Hinweis: In der Schlüssellayoutdatei wird der Wert für den Koordinatenraum der Fahrer der von „android.view.InputDevice.MotionRange#getFlat()“ gemeldete Wert befindet sich im Koordinatenraum.

axis 0x03 Z flat 4096

Im obigen Beispiel wird der mittlere flache Wert auf 4096 gesetzt.

Kommentare

Kommentarzeilen beginnen mit # und gehen bis zum Ende der Zeile:

# A comment!

Leerzeilen werden ignoriert.

Beispiele

Tastatur

# This is an example of a key layout file for a keyboard.

key 1     ESCAPE
key 2     1
key 3     2
key 4     3
key 5     4
key 6     5
key 7     6
key 8     7
key 9     8
key 10    9
key 11    0
key 12    MINUS
key 13    EQUALS
key 14    DEL

# etc...

System­steuerelemente

# This is an example of a key layout file for basic system controls,
# such as volume and power keys which are typically implemented as GPIO pins
# the device decodes into key presses.

key 114   VOLUME_DOWN
key 115   VOLUME_UP
key 116   POWER

Kapazitive Tasten

# This is an example of a key layout file for a touch device with capacitive buttons.

key 139    MENU           VIRTUAL
key 172    HOME           VIRTUAL
key 158    BACK           VIRTUAL
key 217    SEARCH         VIRTUAL

Mediensteuerung für Headset-Anschluss

# This is an example of a key layout file for headset mounted media controls.
# A typical headset jack interface might have special control wires or detect known
# resistive loads as corresponding to media functions or volume controls.
# This file assumes that the driver decodes these signals and reports media
# controls as key presses.

key 163   MEDIA_NEXT
key 165   MEDIA_PREVIOUS
key 226   HEADSETHOOK

Joystick

# This is an example of a key layout file for a joystick.

# These are the buttons that the joystick supports, represented as keys.
key 304   BUTTON_A
key 305   BUTTON_B
key 307   BUTTON_X
key 308   BUTTON_Y
key 310   BUTTON_L1
key 311   BUTTON_R1
key 314   BUTTON_SELECT
key 315   BUTTON_START
key 316   BUTTON_MODE
key 317   BUTTON_THUMBL
key 318   BUTTON_THUMBR

# Left and right stick.
# The reported value for flat is 128 in a range of -32767 to 32768, which is absurd.
# This confuses applications that rely on the flat value because the joystick
# actually settles in a flat range of +/- 4096 or so. We override it here.
axis 0x00 X flat 4096
axis 0x01 Y flat 4096
axis 0x03 Z flat 4096
axis 0x04 RZ flat 4096

# Triggers.
axis 0x02 LTRIGGER
axis 0x05 RTRIGGER

# Hat.
axis 0x10 HAT_X
axis 0x11 HAT_Y

Virtuelle Softkeys

Das Eingabesystem bietet spezielle Funktionen zum Implementieren virtueller Softkeys. in den folgenden Anwendungsfällen:

  1. Werden die virtuellen Softkeys grafisch auf dem Bildschirm angezeigt (z. B. des Galaxy Nexus), werden sie durch die Navigationsleistenkomponente im System-UI-Paket Da grafische virtuelle Softkeys mit einer hohen im System hat, sind keine Schlüssellayoutdateien beteiligt und die folgenden Informationen nicht gelten.
  2. Wenn die virtuellen Softkeys als erweiterter, berührbarer Bereich implementiert sind die Teil des Haupt-Touchscreens wie z. B. auf dem Nexus One ist, wird die Eingabe verwendet eine virtuelle Tastenbelegungsdatei, um X/Y-Touch-Koordinaten in Linux-Schlüsselcodes und nutzt diese dann zur Übersetzung der Linux-Tastencodes in Android-Schlüsselcodes (Details zu Virtual Key Map-Dateien finden Sie unter Touch-Geräte). Die Schlüssellayoutdatei für die muss die entsprechende Tastenbelegung aufweisen und das Flag VIRTUAL für jeden Schlüssel.
  3. Wenn die virtuellen Softkeys als kapazitive Tasten getrennt von den Haupt-Touchscreen (z. B. beim Nexus S), den Kernel-Gerätetreiber oder Firmware für die Übersetzung von Berührungen in Linux-Schlüsselcodes zuständig, und wird dann mithilfe der Schlüssellayoutdatei in Android-Schlüsselcodes umgewandelt. In der Schlüssel-Layoutdatei für das kapazitive Tasteneingabegerät muss die entsprechende Schlüsselzuordnung und fügen Sie für jeden Schlüssel das Flag VIRTUAL hinzu.

Wenn sich virtuelle Softkeys innerhalb oder in unmittelbarer Nähe des Geräts befinden, des Touchscreens ist es für Nutzende leicht, versehentlich auf eine Schaltfläche zu drücken, den Bildschirm berühren oder einen Finger von oben nach unten ziehen oder von unten nach oben. Um dies zu verhindern, wendet das Eingabesystem entprellt, sodass das Betätigen virtueller Softtasten kurzzeitig ignoriert wird erst nach der letzten Berührung des Touchscreens (diese Verzögerung wird als Ruhezeit des virtuellen Schlüssels).

So aktivieren Sie die Entprellung für virtuelle Softkeys:

  1. Stellen Sie eine Schlüssellayoutdatei für den Touchscreen oder die kapazitive Taste bereit Eingabegerät mit dem Flag VIRTUAL für jeden Schlüssel. 
    key 139    MENU           VIRTUAL
key 172    HOME           VIRTUAL
key 158    BACK           VIRTUAL
key 217    SEARCH         VIRTUAL
  2. Legen Sie den Wert der Ruhezeit des virtuellen Schlüssels in einem Ressourcen-Overlay für die Framework config.xml. 
    <!-- Specifies the amount of time to disable virtual keys after the screen
is touched to filter out accidental virtual key presses due to swiping gestures
or taps near the edge of the display. May be 0 to disable the feature.
It is recommended that this value be no more than 250 ms.
This feature should be disabled for most devices. -->

<integer name="config_virtualKeyQuietTimeMillis">250</integer>

Zertifizierungsstufe

Sie sollten Ihre Schlüssellayoutdateien mit dem Validieren Sie Keymaps.