Klawiatury

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Android obsługuje różne klawiatury, w tym specjalne klawiatury funkcyjne (sterowanie głośnością i zasilaniem), kompaktowe wbudowane klawiatury QWERTY oraz w pełni funkcjonalne klawiatury zewnętrzne w stylu komputera.

Ten dokument dotyczy tylko klawiatur fizycznych. Informacje o klawiaturze ekranowej (edytorach metod wprowadzania) znajdziesz w pakiecie Android SDK.

Klasyfikacja klawiatury

Urządzenie wejściowe jest klasyfikowane jako klawiatura, jeśli spełnia co najmniej jeden z tych warunków:

• Urządzenie wejściowe zgłasza obecność dowolnych kodów klawiszy Linux używanych na klawiaturach, w tym 0–0xff lub KEY_OK–KEY_MAX.

• Urządzenie wejściowe zgłasza obecność dowolnych kodów klawiszy Linux używanych na joystickach i kontrolerach, w tym BTN_0–BTN_9, BTN_TRIGGER–BTN_DEAD, BTN_A–BTN_THUMBR.

Obecnie joysticki są klasyfikowane jako klawiatury, ponieważ przyciski joysticków i kontrolerów są rejestrowane przez zdarzenia EV_KEY w taki sam sposób jak przyciski klawiatury. Dlatego joysticki i pady również korzystają z plików map klawiszy do konfiguracji.

Gdy urządzenie wejściowe zostanie zaklasyfikowane jako klawiatura, system wczyta plik konfiguracji urządzenia wejściowego i układ klawiatury.

Następnie system próbuje określić dodatkowe cechy urządzenia.

• Jeśli urządzenie wejściowe ma jakiekolwiek klawisze mapowane na KEYCODE_Q, jest ono uznawane za urządzenie z klawiaturą alfabetyczną (a nie numeryczną). Funkcja klawiatury alfabetycznej jest raportowana w zasobie Configuration jako KEYBOARD_QWERTY.

• Jeśli urządzenie wejściowe ma jakiekolwiek klawisze mapowane na KEYCODE_DPAD_UP, KEYCODE_DPAD_DOWN, KEYCODE_DPAD_LEFT, KEYCODE_DPAD_RIGHT i KEYCODE_DPAD_CENTER (wszystkie muszą być obecne), urządzenie jest uważane za mające klawiaturę kierunkową. Funkcja klawiatury kierunkowej jest raportowana w obiekcie zasobu Configuration jako NAVIGATION_DPAD.

• Jeśli urządzenie wejściowe ma jakiekolwiek przyciski mapowane na KEYCODE_BUTTON_Alub inne przyciski związane z padami, jest ono uznawane za urządzenie z padami.

Wymagania dotyczące sterownika klawiatury

1. Sterowniki klawiatury powinny rejestrować tylko kody klawiszy, które faktycznie obsługują. Rejestrowanie nadmiarowych kodów kluczy może dezorientować algorytm klasyfikacji urządzenia lub powodować nieprawidłowe wykrywanie obsługiwanych funkcji klawiatury przez system.

2. Sterowniki klawiatury powinny używać EV_KEY do zgłaszania naciśnięć klawiszy, używając wartości 0, aby wskazać, że klawisz został zwolniony, wartości 1, aby wskazać, że klawisz jest naciśnięty, oraz wartości większej lub równej 2, aby wskazać, że klawisz jest powtarzany automatycznie.

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

4. Sterowniki klawiatury mogą opcjonalnie wskazywać użycie HID lub kod skanowania na niskim poziomie, wysyłając EV_MSC z MSC_SCANCODE i wartością wskazującą użycie lub kod skanowania, gdy klawisz jest wciśnięty. Te informacje nie są obecnie używane przez Androida.

5. Sterowniki klawiatury powinny obsługiwać ustawianie stanów diod LED, gdy na urządzenie jest zapisywany parametr EV_LED. Sterownik hid-input zrobi to automatycznie. W momencie pisania tego tekstu Android używał LED_CAPSLOCK, LED_SCROLLLOCK i LED_NUMLOCK. Te diody LED muszą być obsługiwane tylko wtedy, gdy klawiatura rzeczywiście ma powiązane diody.

6. Sterowniki klawiatur w przypadku wbudowanych klawiatur (np. korzystających z matrycy GPIO) powinny wysyłać zdarzenia EV_KEY o wartości 0 w przypadku wszystkich klawiszy, które są nadal wciśnięte, gdy urządzenie przechodzi w stan uśpienia. W przeciwnym razie klawisze mogą się zablokować i automatycznie powtarzać w nieskończoność.

Działanie klawiatury

Poniżej znajdziesz krótkie podsumowanie działania klawiatury na Androidzie.

1. EventHub odczytuje nieprzetworzone zdarzenia z sterownika evdev i przypisze kody klawiszy Linuksa (czasami nazywane kodami skanowania) do kodów klawiszy Androida, korzystając z mapy rozmieszczenia klawiszy na klawiaturze.

2. InputReader przetwarza nieprzetworzone zdarzenia i aktualizuje stan klucza meta. Jeśli na przykład naciśniesz lub puścisz lewy klawisz Shift, czytnik odpowiednio ustawi lub wyzeruje bity META_SHIFT_LEFT_ON i META_SHIFT_ON.

3. InputReader powiadamia InputDispatcher o wystąpieniu kluczowego zdarzenia.

4. InputDispatcher pyta WindowManagerPolicy, co zrobić z kluczowym zdarzeniem, wywołując funkcję WindowManagerPolicy.interceptKeyBeforeQueueing. Ta metoda jest częścią ścieżki krytycznej, która odpowiada za wybudzenie urządzenia po naciśnięciu określonych klawiszy. EventHub skutecznie blokuje tryb czuwania na tej ścieżce krytycznej, aby zapewnić jej dokładne wykonanie.

5. Jeśli klucz InputFilter jest obecnie używany, obiekt InputDispatcher daje mu możliwość wykorzystania lub przekształcenia klucza. InputFilter może służyć do wdrażania niskopoziomowych zasad ułatwień na poziomie systemu.

6. InputDispatcher umieszcza klucz w kolejce do przetwarzania w wątku wysyłki.

7. Gdy InputDispatcher usunie klucz z kolejki, da to WindowManagerPolicy drugą szansę na przechwycenie kluczowego zdarzenia przez wywołanie funkcji WindowManagerPolicy.interceptKeyBeforeDispatching. Ta metoda obsługuje skróty systemowe i inne funkcje.

8. Następnie InputDispatcher określa cel kluczowego zdarzenia (okno skupienia) i czeka, aż będzie gotowy. Następnie InputDispatcher przekazuje kluczowe zdarzenie do aplikacji.

9. W aplikacji kluczowe zdarzenie jest przekazywane w dół hierarchii widoków do widoku skupionego w celu wysłania klucza przed IME.

10. Jeśli kluczowe zdarzenie nie jest obsługiwane w ramach przesyłania przed IME, a IME jest używane, to zdarzenie jest przekazywane do IME.

11. Jeśli zdarzenie kluczowe nie zostało wykorzystane przez IME, rozprzestrzenia się w dół hierarchii widoków do widoku skupionego w celu standardowego rozsyłania klucza.

12. Aplikacja informuje InputDispatcher, czy kluczowe zdarzenie zostało wywołane. Jeśli zdarzenie nie zostało wykorzystane, InputDispatcher wywołuje WindowManagerPolicy.dispatchUnhandledKey, aby zastosować zachowanie „zapasowe”. W zależności od działania zastępczego cykl przetwarzania kluczowych zdarzeń może zostać wznowiony za pomocą innego kodu klucza. Jeśli na przykład aplikacja nie obsługuje zdarzenia KEYCODE_ESCAPE, system może ponownie wysłać kluczowe zdarzenie jako zdarzenie KEYCODE_BACK.

Konfiguracja klawiatury

Zachowanie klawiatury zależy od układu klawiszy, mapy znaków i konfiguracji urządzenia wejściowego.

Więcej informacji o plikach, które uczestniczą w konfiguracji klawiatury, znajdziesz w tych sekcjach:

• Pliki układu klucza
• Pliki mapy kluczy postaci
• Pliki konfiguracji urządzeń wejściowych

Właściwości

W przypadku klawiatur używane są te właściwości konfiguracji urządzenia wejściowego:

keyboard.layout

Definicja: keyboard.layout = <name>

Określa nazwę pliku z rozkładem klawiszy powiązanego z urządzeniem wejściowym, z wyjątkiem rozszerzenia .kl. Jeśli nie uda się go znaleźć, system wejściowy użyje domyślnego układu klawiszy.

Odstępy w nazwie są konwertowane na podkreślenia podczas wyszukiwania.

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

keyboard.characterMap

Definicja: keyboard.characterMap = <name>

Określa nazwę pliku mapy znaków klawiszy powiązanego z urządzeniem wejściowym (z wyjątkiem rozszerzenia .kcm). Jeśli nie uda się go znaleźć, system wejściowy użyje domyślnej mapy znaków.

Odstępy w nazwie są konwertowane na podkreślenia podczas wyszukiwania.

Więcej informacji znajdziesz w dokumentacji pliku mapy znaków klucza.

keyboard.orientationAware

Definicja: keyboard.orientationAware = 0 | 1

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

• Jeśli wartość to 1, przyciski klawiatury kierunkowej są obracane, gdy zmienia się powiązana orientacja wyświetlacza.

• Jeśli wartość to 0, klawiatura jest odporna na zmiany orientacji wyświetlacza.

Wartość domyślna to 0.

Orientacja jest używana do obsługi obracania klawiszy kierunkowych na klawiaturze, na przykład w przypadku telefonu Motorola Droid. Jeśli na przykład urządzenie zostanie obrócone o 90 stopni zgodnie z kierunkiem ruchu wskazówek zegara od naturalnej orientacji, przycisk KEYCODE_DPAD_UP zostanie przemapowany na KEYCODE_DPAD_RIGHT, ponieważ przycisk „w górę” będzie wskazywać w prawo, gdy urządzenie będzie trzymane w tej orientacji.

keyboard.builtIn

Definicja: keyboard.builtIn = 0 | 1

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

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

Wbudowanej klawiaturze zawsze przypisywany jest identyfikator urządzenia 0. Innym klawiaturom, które nie są wbudowane, przypisuje się unikalne identyfikatory urządzeń o wartościach innych niż 0.

Używanie identyfikatora 0 dla wbudowanej klawiatury jest ważne ze względu na zgodność z polem KeyCharacterMap.BUILT_IN_KEYBOARD, które określa identyfikator wbudowanej klawiatury i ma wartość 0. To pole zostało wycofane z interfejsu API, ale starsze aplikacje mogą z niego nadal korzystać.

Klawiatura o funkcji specjalnej (czyli taka, której mapa klawiszy określa typ SPECIAL_FUNCTION) nigdy nie zostanie zarejestrowana jako wbudowana klawiatura, niezależnie od ustawienia tej właściwości. Dzieje się tak, ponieważ klawiatura do specjalnych funkcji nie jest z założenia przeznaczona do ogólnego pisania.

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 maper danych wejściowych klawiatury nie używał żadnych właściwości konfiguracji. Zakładano, że wszystkie klawiatury są fizycznie podłączone i mają rozpoznawanie orientacji. Domyślny układ klawiszy i mapa znaków klawiszy miały nazwę qwerty zamiast Generic. Format mapy klawiszy był też bardzo różny, a ramka nie obsługiwała pełnych klawiatur w stylu komputera PC ani klawiatur zewnętrznych.

Podczas aktualizacji urządzeń do Honeycomb utwórz lub zaktualizuj niezbędne pliki konfiguracji i mapy kluczy.

Zastosowania HID, kody klawiszy Linux i Android

System odwołuje się do kluczy za pomocą kilku różnych identyfikatorów, w zależności od poziomu abstrakcji.

W przypadku urządzeń HID każdemu kluczowi odpowiada jedno użycie. Za parsowanie raportów HID i mapowanie ich zastosowań na kody klawiszy Linuxa odpowiadają sterownik hid-input w Linuxie oraz powiązane z nim sterowniki HID producenta i urządzenia.

Gdy Android odczytuje zdarzenia EV_KEY z jądra Linuksa, przekształci każdy kod klawisza Linuksa w odpowiadający mu kod klawisza Androida zgodnie z plikiem układu klawiszy urządzenia.

Gdy kluczowe zdarzenie zostanie wysłane do aplikacji, instancja android.view.KeyEvent zgłasza kod klucza Linuxa jako wartość parametru getScanCode(), a kod klucza Androida jako wartość parametru getKeyCode(). W ramach tego frameworka istotna jest tylko wartość getKeyCode().

Pamiętaj, że informacje o użyciu interfejsu HID nie są używane przez system Android ani przekazywane aplikacjom.

Tabele kodu

Poniższe tabele pokazują, jak powiązane są ze sobą zastosowania HID, kody klawiszy Linux i kody klawiszy Android.

Kolumna LKC określa kod klucza Linuksa w formacie szesnastkowym.

Kolumna AKC określa kod klucza Androida w formacie szesnastkowym.

Kolumna Notatki odnosi się do notatek opublikowanych po tabeli.

Kolumna Wersja określa pierwszą wersję platformy Android, która uwzględniła ten klucz w domyślnej mapie kluczy. W przypadku, gdy domyślna mapa klawiszy zmieniła się między wersjami, wyświetlane są 2 wiersze. Najstarsza wskazana wersja to 1.6.

• W wersji Gingerbread (2.3) i wcześniejszych domyślną mapą kluczy byłaqwerty.kl. Ta mapa klawiszy była przeznaczona tylko do użytku z emulatorem Androida i nie była przeznaczona do obsługi dowolnych zewnętrznych klawiatur. Mimo to kilku producentów OEM wprowadziło na platformie obsługę klawiatury Bluetooth, korzystając z funkcji qwerty.kl do mapowania klawiatury. W związku z tym starsze mapowania mogą być przydatne dla producentów sprzętu oryginalnego, którzy tworzą urządzenia peryferyjne do tych konkretnych urządzeń. Pamiętaj, że mapowania te znacznie różnią się od obecnych, zwłaszcza w przypadku traktowania klucza HOME. Zaleca się, aby wszystkie nowe urządzenia peryferyjne były opracowywane zgodnie z schematem Honeycomb lub nowszymi mapami klawiszy (np. standardem HID).

• Od wersji Honeycomb (3.0) domyślną mapą kluczy jest Generic.kl. Ta mapa klawiszy została zaprojektowana z myślą o klawiaturach w pełnej wersji dla komputerów PC. Większość funkcji standardowych klawiatur HID powinna działać od razu po podłączeniu.

Mapowanie kodu klawiszy może się różnić w zależności od wersji jądra Linuksa i Androida. Jeśli wiadomo, że w domyślnych mapach kluczy Androida zaszły zmiany, są one wskazywane w kolumnie wersji.

Sterowniki HID i mapy klawiszy przeznaczone dla konkretnego urządzenia mogą stosować inne mapowania niż te wskazane tutaj.

Strona klawiatury i klawiatury numerycznej HID (0x07)

Ogólna strona komputera na urządzeniu HID (0x01)

Strona konsumenta HID (0x0c)

Dodatkowe mapowania inne niż HID

Te mapowania opisują funkcje, które nie pojawiają się w HID, ale istnieją dla nich kody klawiszy Linuxa.

Starsze nieobsługiwane klucze

Te mapowania pojawiły się w poprzednich wersjach Androida, ale były niezgodne z HID lub używały niestandardowych kodów klawiszy Linuxa. Nie są one już obsługiwane.

Uwagi

1. Kod klawisza Androida powiązany ze wspólnymi klawiszami alfanumerycznymi i symbolicznymi może się różnić w zależności od układu i języka klawiatury. Ze względów historycznych fizyczne kody skanowania i użycia HID związane z klawiszami na klawiaturze są często definiowane na podstawie pozycji, mimo że etykiety na tych klawiszach mogą się różnić w zależności od języka.

   Na klawiaturze QWERTY w języku angielskim (USA) lewy górny klawisz alfabetyczny jest oznaczony literą Q. Na klawiaturze francuskiej (AZERTY) klawisz w tej samej pozycji ma oznaczenie A. Pomimo etykiety na obu klawiaturach klawisz alfabetyczny w lewym górnym rogu jest określany za pomocą kodu użycia HID 0x07 0x0014, który jest mapowany na kod klawisza Linux KEY_Q.

   Jeśli Android jest skonfigurowany z użyciem układu klawiatury angielskiej (amerykańskiej), kod klawisza Linux KEY_Q zostanie przypisany do kodu klawisza Androida KEYCODE_Q i będzie generować znaki „Q” i „q”. Jeśli jednak Android jest skonfigurowany z użyciem układu klawiatury francuskiej, kod klawisza Linux KEY_Q zostanie przypisany do kodu klawisza Androida KEYCODE_A i będzie generować znaki „A” i „a”.

   Kod klucza Androida zwykle odzwierciedla interpretację klucza w danym języku, więc w różnych językach może być używany inny kod klucza Androida.

2. 0x0c 0x022f AC Zoom jest zdefiniowany w HID jako element sterujący liniowy, ale jądro mapuje go jako klawisz, co jest prawdopodobnie nieprawidłowe.

3. Klawisze funkcyjne Linuxa KEY_FN_* są mapowane na prostsze kody klawiszy, ale są wysyłane z metastanem META_FUNCTION, w którym bit ustawiony jest na „prawda”.

4. Przed wersją Androida Ice Cream Sandwich 4.0 domyślny układ klawiszy zawierał mapowania niektórych dodatkowych kodów klawiszy, które nie były zdefiniowane w głównych nagłówkach jądra Linuksa. Te mapowania zostały usunięte, ponieważ wcześniej niezdefiniowane kody kluczy zostały przypisane do innych znaczeń w nowszych wersjach jądra Linuksa.

Źródła

1. Tabele wykorzystania interfejsu HID USB w wersji 1.12
2. Rdzeń Linuksa 2.6.39: include/linux/input.h, drivers/hid/hid-input.c
3. Android ICS: qwerty.kl, Generic.kl, KeyEvent.java