Klawiatury

Android obsługuje różne rodzaje klawiatur, w tym funkcje specjalne klawiatura (sterowanie głośnością i zasilaniem), kompaktowe klawiatury QWERTY, i w pełni funkcjonalne klawiatury zewnętrzne.

W tym dokumencie opisujemy tylko klawiatury fizyczne. Zapoznaj się z pakietem Android SDK .

Klasyfikacja klawiatury

Urządzenie wejściowe jest klasyfikowane jako klawiatura, jeśli: spełnione są warunki:

• Urządzenie wejściowe zgłasza obecność wszelkich kodów klawiszy w Linuksie używanych na klawiaturze. w tym 0 za 0xff lub KEY_OK do KEY_MAX.

• Urządzenie wejściowe zgłasza obecność wszelkich kodów klawiszy Linuksa używanych na joystickach. i pady do gier, w tym od BTN_0 do BTN_9, BTN_TRIGGER do BTN_DEAD, lub od BTN_A do BTN_THUMBR.

Joysticki są obecnie klasyfikowane jako klawiatury, ponieważ przyciski joysticka i pada do gier są zgłaszane przez zdarzenia EV_KEY w taki sam sposób, w jaki są raportowane klawisze na klawiaturze. Zatem joysticki i kontrolery do gier również wykorzystują do konfiguracji kluczowe pliki mapy.

Po sklasyfikowaniu urządzenia wejściowego jako klawiatury system wczytuje plik konfiguracji urządzenia i układ klawiatury.

System próbuje następnie określić dodatkowe cechy urządzenia.

• Jeśli urządzenie wejściowe ma klawisze zmapowane na KEYCODE_Q, urządzenie ma klawiaturę alfabetyczną (a nie cyfrową). Możliwości klawiatury alfabetycznej są zgłaszane w zasobie Configuration jako KEYBOARD_QWERTY.

• Jeśli urządzenie wejściowe ma klucze zmapowane na KEYCODE_DPAD_UP, KEYCODE_DPAD_DOWN, KEYCODE_DPAD_LEFT, KEYCODE_DPAD_RIGHT i KEYCODE_DPAD_CENTER (wszystkie muszą być obecne), urządzenie jest uznawane za urządzenie mieć klawiaturę kierunkową. Działanie klawiatury kierunkowej jest zgłaszane w zasobie Configuration jako NAVIGATION_DPAD.

• Jeśli urządzenie wejściowe ma klucze zmapowane na KEYCODE_BUTTON_A lub innych klawiszy związanych z padem do gier, uznaje się, że urządzenie ma pada do gier.

Wymagania dotyczące sterownika klawiatury

1. Sterowniki klawiatur powinny rejestrować tylko kody klawiszy, które są używane są obsługiwane. Zarejestrowanie nadmiarowych kodów kluczy może dezorientować urządzenie algorytmu klasyfikacji lub powodują nieprawidłowe wykrycie przez system obsługiwane funkcje klawiatury urządzenia.

2. Sterowniki klawiatur powinny używać identyfikatora EV_KEY do raportowania naciśnięć klawiszy wraz z wartością 0 oznacza, że klucz został zwolniony; wartość 1 oznacza, że po naciśnięciu klawisza i przy użyciu wartości większej lub równej 2 wskazującej przycisk jest powtarzany automatycznie.

3. Android ma własne powtarzanie klawiatury. Funkcja automatycznego powtarzania powinna być wyłączona w sterowniku.

4. Sterowniki klawiatury mogą opcjonalnie wskazywać użycie HID lub skanowanie niskopoziomowe wysyłając kod EV_MSC z parametrem MSC_SCANCODE i wartość wskazującą wykorzystanie lub skanuj kod po naciśnięciu klawisza. Ta informacja nie jest obecnie używane przez Androida.

5. Sterowniki klawiatury powinny obsługiwać ustawianie stanów diody LED po zapisaniu znaków EV_LED do urządzenia. Sterownik hid-input zrobi to automatycznie. W momencie pisania tych wiadomości Android używa: LED_CAPSLOCK, LED_SCROLLLOCK, i LED_NUMLOCK. Te diody LED muszą być obsługiwane tylko wtedy, gdy mają przypisane diody.

6. Sterowniki klawiatur dla wbudowanych klawiatur (np. macierzy GPIO) powinien wysyłać zdarzenia EV_KEY z wartością 0 dla wszystkich kluczy, które nadal są wciśnięte, gdy urządzenie przechodzi w tryb uśpienia. W przeciwnym razie klucze mogą utkną i będą się powtarzać w nieskończoność.

Obsługa klawiatury

Poniżej znajduje się krótkie podsumowanie działania klawiatury w systemie Android.

1. EventHub odczytuje nieprzetworzone zdarzenia ze sterownika evdev i mapuje kody kluczy Linuksa (czasami nazywane kodami skanowania) na kody klawiszy Androida za pomocą mapy układu klawiszy.

2. InputReader przetwarza nieprzetworzone zdarzenia i aktualizuje stan klucza meta. Na przykład jeśli naciśniesz lub zwolnisz lewy klawisz Shift, czytnik odpowiednio ustaw lub zresetuj bity META_SHIFT_LEFT_ON i META_SHIFT_ON.

3. Element InputReader powiadamia usługę InputDispatcher o kluczowym zdarzeniu.

4. InputDispatcher pyta WindowManagerPolicy, co zrobić z kluczem wydarzenia, wywołując WindowManagerPolicy.interceptKeyBeforeQueueing. Ta metoda to część ścieżki krytycznej, która odpowiada za wybudzanie urządzenia, niektóre klawisze. Urządzenie EventHub skutecznie utrzymuje blokadę uśpienia na tej ścieżce krytycznej, aby zapewnić jej pełną realizację.

5. Jeśli InputFilter jest obecnie używany, InputDispatcher nadaje mu na wykorzystanie lub przekształcenie klucza. Interfejs InputFilter może być używany do implementacji niskopoziomowych zasad ułatwień dostępu w całym systemie.

6. InputDispatcher dodaje klucz do kolejki przetwarzania w wątku wysyłki.

7. Gdy InputDispatcher usunie klucz z kolejki, otrzyma WindowManagerPolicy drugą szansę na przechwycenie kluczowego zdarzenia, wywołując WindowManagerPolicy.interceptKeyBeforeDispatching Ta metoda obsługuje system skrótów i innych funkcji.

8. Następnie InputDispatcher identyfikuje cel kluczowego zdarzenia (zaznaczone okno). i czeka, aż będą gotowe. Następnie InputDispatcher przesyła kluczowe zdarzenie do aplikacji.

9. W aplikacji kluczowe zdarzenie jest przekazywane dalej w hierarchii widoku do: aktywny widok wysyłki klucza przed IME.

10. Jeśli kluczowe zdarzenie nie jest obsługiwane w wysyłaniu przed IME i używany jest IME, makro kluczowe zdarzenie jest przekazywane do IME.

11. Jeśli kluczowe zdarzenie nie zostało przetworzone przez edytor IME, zostanie ono przekazane po pełnej hierarchii widoków do widoku ograniczonego do standardowego wysyłania kluczy.

12. Aplikacja przesyła w raportach InputDispatcher informacje, czy klucz zostało wykorzystane. Jeśli zdarzenie nie zostało wykorzystane, InputDispatcher wywołuje funkcję WindowManagerPolicy.dispatchUnhandledKey, aby zastosować „wartość zastępczą” zachowanie użytkownika. W zależności od działania kreacji zastępczej cykl wysyłania kluczowego zdarzenia może zostać ponownie uruchomiony. za pomocą innego kodu. Jeśli na przykład aplikacja nie obsługuje KEYCODE_ESCAPE, system może ponownie wysłać kluczowe zdarzenie jako KEYCODE_BACK.

Konfiguracja klawiatury

Działanie klawiatury zależy od układu klawiszy oraz jej znaku i konfigurację urządzeń wejściowych.

W kolejnych sekcjach znajdziesz więcej informacji o plikach, które uczestniczyć w konfiguracji klawiatury:

• Pliki układu kluczy
• Pliki mapy klawiszy
• Wprowadź pliki konfiguracji urządzenia

Właściwości

W przypadku klawiatur używane są poniższe właściwości konfiguracji urządzenia wejściowego.

klawiatura.układ

Definicja: keyboard.layout = <name>

Określa nazwę pliku układu klucza powiązanego z urządzeniem wejściowym. wykluczając rozszerzenie .kl. Jeśli plik nie zostanie znaleziony, system wejściowy będzie używać domyślnego układu klawiszy.

Podczas wyszukiwania spacje w nazwie są konwertowane na podkreślenia.

Więcej informacji znajdziesz w dokumentacji pliku układu klucza.

klawiatura.characterMap

Definicja: keyboard.characterMap = <name>

Określa nazwę pliku mapy znaków kluczowych powiązanego z urządzeniem wejściowym. wykluczając rozszerzenie .kcm. Jeśli plik nie zostanie znaleziony, system wejściowy będzie używać domyślnej mapy znaków klawiszy.

Podczas wyszukiwania spacje w nazwie są konwertowane na podkreślenia.

Więcej informacji znajdziesz w dokumentacji pliku mapy klawiszy.

klawiatura.orientationAware

Definicja: keyboard.orientationAware = 0 | 1

Określa, czy klawiatura ma reagować na zmiany orientacji wyświetlacza.

• Jeśli wartość to 1, klawisze kierunkowe na klawiaturze są obrócone, gdy powiązanych zmian orientacji wyświetlacza.

• Jeśli wartością jest 0, klawiatura nie jest odporna na zmiany orientacji wyświetlacza.

Wartość domyślna to 0.

Rozpoznawanie orientacji służy do obsługi obracania klawiszy na klawiaturze kierunkowej. takich jak Motorola Droid. Na przykład podczas obracania urządzenia w prawo o 90 stopni od swojej naturalnej orientacji, KEYCODE_DPAD_UP jest do produkowania KEYCODE_DPAD_RIGHT wykorzystano nowe kończy się na wskazówkę „prawo” gdy urządzenie jest trzymane w tej orientacji.

klawiatura.wbudowana

Definicja: keyboard.builtIn = 0 | 1

Określa, czy klawiatura jest wbudowana (podłączona fizycznie) klawiatury.

Wartość domyślna to 1, jeśli nazwa urządzenia kończy się na -keypad. W przeciwnym razie wartość wynosi 0.

Wbudowana klawiatura zawsze ma przypisany identyfikator urządzenia 0. Inne klawiatury które nie są wbudowane, mają unikalne, niezerowe identyfikatory urządzeń.

W przypadku klawiatury wbudowanej identyfikator 0 jest ważny, ponieważ pozwala uniknąć zgodność z polem KeyCharacterMap.BUILT_IN_KEYBOARD, które określa identyfikator wbudowanej klawiatury o wartości 0. To pole zostało wycofane w interfejsie API, ale starsze aplikacje mogą go nadal używać.

Klawiatura ze specjalnymi funkcjami (np. której mapa klawiszy ze znakami towarowymi określa typu SPECIAL_FUNCTION) nigdy nie zostaną zarejestrowane jako klawiatura wbudowana, niezależnie od ustawień tej właściwości. Dzieje się tak, ponieważ funkcja specjalna klawiatura z definicji nie jest przeznaczona do pisania ogólnego.

Przykładowe konfiguracje

# 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

Uwagi dotyczące zgodności

Przed wersją Honeycomb kreator map wprowadzania tekstu z klawiatury nie używał żadnych właściwości konfiguracji. Zakładamy, że wszystkie klawiatury są fizycznie podłączone i rozpoznają orientację. Domyślny układ klawiszy i mapa klawiszy zostały nazwane qwerty, a nie Generic. Klucz format mapy znaków był również zupełnie inny. Pełnoekranowe klawiatury w stylu PC lub klawiatury zewnętrzne.

Przy uaktualnianiu urządzeń do wersji Honeycomb pamiętaj o utworzeniu lub plików konfiguracji i map kluczy.

Zastosowania HID, kody kluczy w systemie Linux i kody kluczy na Androidzie

System odnosi się do kluczy za pomocą kilku różnych identyfikatorów, do warstwy abstrakcji.

W przypadku urządzeń HID z każdym kluczem jest powiązane użycie HID. Linux hid-input za sterownik oraz powiązane sterowniki HID i producenta urządzenia do analizy raportów HID i mapowania zastosowań HID na kody kluczy w systemie Linux.

Android odczytuje zdarzenia EV_KEY z jądra systemu Linux, do odpowiedniego kodu klucza na Androidzie zgodnie z pliku układu klucza urządzenia.

Po wysłaniu kluczowego zdarzenia do aplikacji parametr android.view.KeyEvent zgłasza kod klucza Linuksa jako wartość getScanCode(), a metoda Kod klucza Androida jako wartość getKeyCode(). Na potrzeby platformy, ważna jest tylko wartość getKeyCode().

Pamiętaj, że dane o korzystaniu z HID nie są używane przez sam system Android ani i przekazywane do aplikacji.

Tabele kodu

W tabelach poniżej znajdziesz informacje o zastosowaniach urządzeń HID, kodach kluczy w systemie Linux i Androidzie kody klawiszy są ze sobą powiązane.

Kolumna LKC określa kod klucza systemu Linux w postaci szesnastkowej.

Kolumna AKC określa kod klucza Androida w postaci szesnastkowej.

Kolumna Notatki odnosi się do notatek opublikowanych po tabeli.

Kolumna „Wersja” podaje pierwszą wersję platformy Androida. , aby uwzględnić ten klucz w domyślnej mapie kluczy. Zastosowanie wielu wierszy wyświetlane w przypadkach, gdy domyślna mapa kluczy zmieniła się w kolejnych wersjach. Najstarsza wskazana wersja to 1.6.

• W wersji Gingerbread (2.3) i wcześniejszych domyślną mapą klawiszy było qwerty.kl Ta mapa klawiszy była przeznaczona do użytku wyłącznie z Androidem Emulator nie powinien być używany do obsługi dowolnych zewnętrznych klawiatur. Niektórzy producenci OEM dodali jednak Bluetooth obsługi klawiatury przez platformę qwerty.kl i zobaczyć potrzebne mapowania klawiatury. W związku z tym te zasady starsze mapowania mogą być interesujące dla producentów OEM, urządzeń peryferyjnych do tych konkretnych urządzeń. Pamiętaj, że mapowania znacznie różnią się od bieżących, zwłaszcza w odniesieniu do przetwarzania klucza HOME. Zalecane wszystkie nowe urządzenia peryferyjne są zgodne ze standardem Honeycomb lub najnowsze mapy klawiszy (np. standardowy HID).

• Od wersji Honeycomb (3.0) domyślna mapa klawiszy to Generic.kl. Ta mapa klawiszy została opracowana z myślą o obsłudze klawiatur w stylu PC. Większość funkcji standardowych klawiatur HID powinna po prostu działać. z pudełka.

Mapowanie kodu klucza może się różnić w zależności od wersji jądra systemu Linux i Androida. Jeśli wiadomo, że wprowadzono zmiany w domyślnych mapach klawiszy Androida, są one podawane w kolumnie wersji.

Sterowniki HID i mapy klawiszy powiązane z urządzeniami mogą stosować różne mapowania niż podano tutaj.

Strona klawiatury i klawiatury HID (0x07)

Ogólna strona HID na komputery (0 x 01)

Strona dla konsumenta HID (0 x 0c)

Dodatkowe mapowania inne niż HID

Te mapowania opisują funkcje, które nie występują na HID, ale dla których Linux z kluczami.

Starsze nieobsługiwane klucze

Te mapowania pojawiały się w poprzednich wersjach Androida, ale były niespójne z: HID lub użyte niestandardowe kody kluczy w systemie Linux. Nie są już one obsługiwane.

Uwagi

1. Kod klucza Androida powiązany z typowym kodem alfanumerycznym i symbolicznym klawisze mogą się różnić w zależności od układu klawiatury i języka. Z przyczyn historycznych fizyczne kody skanowania i wykorzystania HID powiązane z klawiszami na klawiaturze są często zdefiniowane położeniem chociaż etykiety nadrukowane na tych kluczach mogą różnić się od z innego języka.

   Na klawiaturze amerykańskiej (QWERTY) klawisz alfabetyczny w lewym górnym rogu to opatrzony etykietą Q. Na klawiaturze francuskiej (AZERTY) klawisz w tym samym pozycja jest oznaczona etykietą A. Pomimo etykiety na obu klawiaturach klawisz alfabetyczny w lewym górnym rogu oznacza użycie HID 0x07 0x0014, który jest zmapowany na kod klucza systemu Linux KEY_Q.

   Jeśli Android jest skonfigurowany z amerykańskim układem klawiatury angielskiej, kod klucza Linuksa KEY_Q zostanie zmapowany na kod klucza Androida KEYCODE_Q i zwróci znaki „Q” i „q”. Jeśli jednak Android jest skonfigurowany z francuskim układem klawiatury, kod klucza Linuksa KEY_Q zostanie zmapowany na kod klucza Androida KEYCODE_A i zwróci znaki „A” i „a”.

   Kod klucza Androida zazwyczaj odzwierciedla interpretacji klucza, więc inny kod klucza Androida może mogą być używane w różnych językach.

2. Element 0x0c 0x022f AC Zoom jest zdefiniowany w HID jako sterowanie liniowe, ale jądro mapuje go jako klucz, co prawdopodobnie jest nieprawidłowe.

3. Klawisze funkcyjne KEY_FN_* w Linuksie są zmapowane na prostsze kodów kluczy, ale są wysyłane z metastanem META_FUNCTION bit ma wartość Prawda.

4. Przed wprowadzeniem na Androida Ice Cream Sandwich 4.0 domyślny układ klawiszy zawierało mapowania kilku dodatkowych kodów kluczy, które nie zostały zdefiniowane w nagłówkach jądra systemu Linux. Te mapowania mają od został usunięty, ponieważ wcześniej niezdefiniowane kody kluczy zostały usunięte ponieważ w nowszych wersjach ma ono inne znaczenie systemu Linux.

Źródła

1. Tabele wykorzystania USB HID w wersji 1.12
2. Jądro Linux 2.6.39: include/linux/input.h, sterowniki/hid/hid-input.c
3. Android ICS: qwerty.kl, general.kl, KeyEvent.java