Obsługa edytora metod wprowadzania

Aktualizacje wprowadzone w tych obszarach specyficznych dla wyświetlacza są przedstawione poniżej:

Android 10 podpory klawiatura oprogramowania dla aplikacji uruchomionych na wyświetlaczu niż domyślny.

Aplikacje działające na ekranie innym niż domyślny

Jeśli chodzi o to, który wyświetlacz pokazuje klawiaturę programową edytora Input Method Editor (IME), istnieją dwa różne tryby. Klawiatura oprogramowania jest pokazana na:

  • Na którym pojawia się skupiony aplikacja sama wyświetlacz.
  • Domyślny ekran podczas gdy aplikacja jest uruchomiona skupiony na wyświetlaczu niż domyślny.

System określa, którego trybu użyć, na podstawie ustawień wyświetlacza, na którym pojawia się wybrana aplikacja. Aby uzyskać więcej informacji, zobacz:

  • DisplayWindowSettings#shouldShowImeLocked()
  • DisplayWindowSettings#setShouldShowImeLocked()

Rysunek 1. IME klawiatura oprogramowania, gdyż pojawia się na wyświetlaczu pomocniczym, w tym aplikacji docelowej

System korzysta z pojedynczego edytora IME, ale może przełączać się między ekranami, aby podążać za fokusem użytkownika. Android 10 automatycznie oczekuje, że wszystkie edytory IME własne i innych firm zmienią układ i zmienią rozmiar zgodnie z nowym rozmiarem ekranu po utworzeniu.

Jeśli istnieje aktywne połączenie na ekranie A, a pole wejściowe żąda fokusu wprowadzania na ekranie B, następuje następujący przepływ:

  1. Nowe połączenie wejściowe pochodzi z pola wejściowego na wyświetlaczu B.
  2. InputMethodManagerService sprawdza, czy połączenie powinno zostać zatwierdzone.
  3. Wyświetlacz jest wybrany dla edytora IME. Jeśli wyświetlacz B obsługuje wyświetlanie edytora IME i może go wyświetlać, wówczas używany jest wyświetlacz B. W przeciwnym razie wybierany jest główny wyświetlacz urządzenia.
  4. Jeśli wybrany wyświetlacz nie pochodzi z wyświetlacza A, połączenie zostanie ponownie nawiązane. InputMethodService zostaje zniszczona, a następnie utworzony ponownie.

Ograniczenia bezpieczeństwa

System nie wyświetli edytora IME na wirtualnych wyświetlaczach, które nie są własnością systemu. Wynika to z troski zabezpieczeń złośliwy aplikacja może stworzyć wirtualny wyświetlacz z włączoną Systemu Wsparcia Dekoracje i czytać obsługi wrażliwych informacji z powierzchni, takiej jak przewidywaniami typowania i niestandardowych środowisk.

Realizacja

W Androidzie 9 (i mniejsze), edytor IME był dostępny tylko na ekranie domyślnym, jak opisano w metodach wprowadzania danych na ekranie . W systemie Android 10 (i nowszym) użytkownik może przełączać się między różnymi wejściowymi polami tekstowymi na różnych ekranach, przełączając fokus, a okno IME przenosi się na ekrany dodatkowe.

Realizacja w WindowManager śledzi okno IME (okno IME gdzie klawiatura jest rysowany) i cel (input method okno, w którym wejście IME idzie) do zarządzania stan IME.

Dla InputMethodManagerService (IMIM), żaden inny wbudowany mechanizm może propagować zmiany wyświetlania na InputMethodService (IMS) i rekonfiguracji układu klawiatury w czasie wykonywania przy przenoszeniu ostrość na inny wyświetlacz.

Aby uzyskać przełączanie okna IME między wyświetlaczami, Android 10 implementuje następujące elementy:

  • Okno docelowe IME i wejścia są obecnie śledzone na wyświetlaczu w DisplayContent#mInputMethodWindow i DisplayContent#mInputMethodTarget , tak że managerem okien (WM) może zarządzać stan IME ostrości niezależnie od każdego wyświetlacza.
  • Na stronie IMIM, gdy aplikacja klienta żądanie ostrości z wyświetlacza zewnętrznego jest odbierany przez ViewRootImpl#handleWindowFocusChanged -> InputMethodManager#onPostWindowFocus -> IMMS#startInputOrWindowGainedFocus , najpierw usuwa powiązanie aktualną usługę metodę wprowadzania, a następnie ponowne powiązanie usługę ponownie przymocować nową IME okno żeton na zewnętrznym wyświetlaczu w onServiceConnected() .
  • Na stronie IMS, po IMS#attachToken otrzymaniu następujący przepływ następuje:
    • ContextImpl#updateDisplay nazywa zaktualizować wyświetlacz kontekście usług w InputMethodService#attachToken() . Wymaga to ViewGroup#addView() , aby zmienić układ klawiatury i przystosować do wyświetlania docelowego sprawdzania aktualnego kontekstu.
    • Po DisplayContent#setInputMethodWindowLocked() jest wywoływana, realizacja wysyła proces konfiguracji wyświetlacz poziomu zmienia pomocą WindowProcessController do IME proces zasobów zastępują i wyświetlania danych.
    • InputMethodService klient dostaje prawidłową konfigurację z prawidłowymi danymi wyświetlaczu po onConfigurationChanged() i ViewGroup#addView() wezwanie do ponownego zainicjowania widok wejściowego.

Obsługa wielosesyjnego edytora metod wprowadzania

Implementacje urządzeń z wieloma wyświetlaczami, które mają być jednocześnie używane przez wielu użytkowników w celu zapewnienia odpowiednich źródeł wejściowych, można skonfigurować do jednoczesnego wyświetlania wielu edytorów metod wprowadzania (IME), maksymalnie jeden na wyświetlacz. Poniższe dwa rysunki przedstawiają przykładowy wielosesyjny edytor IME na dwóch wyświetlaczach:

Figura 2. Próbka wielosesyjności IME

Rysunek 3. Próbka wielosesyjności IME

Wsparcie dla Per-display ostrości jest warunkiem wstępnym dla tej funkcji. Jeśli nie, tej funkcji nie można włączyć. Ze względu na ograniczenia bezpieczeństwa ograniczenie ostrości na ekran ograniczyło tę funkcję do niewielkiego podzbioru urządzeń.

W systemie Android 10 obsługa wielosesyjnych edytorów IME jest zaimplementowana za pomocą oddzielnych usług systemowych z innym zestawem interfejsów API i ograniczoną funkcjonalnością. Wielosesyjny edytor IME nie jest zgodny z istniejącymi edytorami IME. Można użyć usługi wielosesyjnej lub jednosesyjnej, ale nie obu.

Nie jest możliwe wykorzystanie istniejącego systemu Android IME zbudowane na górze InputMethodService klasy ponieważ założenie, że jeden klient IME mogą być skoncentrowane w tym samym czasie powstał przed Android IME API zostały wprowadzone w Androidzie 1.5 i wiele API publicznych w InputMethodService mają już mocno opierał się na tym założeniu. Jednak aktualizowanie InputMethodService klasę wspierać scenariusz multi-client jest wyzwaniem, ponieważ:

  1. Dzięki temu można by wprowadzić niedopuszczalną ilość złożoności do InputMethodService , który jest już trudne do utrzymania.
  2. Deweloperzy IME nadal muszą zaktualizować swoją implementację, aby móc obsługiwać równoległe żądania od wielu skoncentrowanych klientów IME, co może wymagać nietrywialnego przeprojektowania po ich stronie (takiego jak dekoder wejściowy i baza danych historii wpisywania).
  3. Oczekuje się, że rzeczywiste przypadki użycia dla klientów z wieloma IME będą szybko ewoluować, więc nowy protokół nie jest stabilny i nie jest gotowy do udostępnienia jako publiczne interfejsy API.

Podobnie jak w przypadku pojedynczej sesji (regularny) IME, kontrola nad pokazując IME na poszczególnych wyświetlaczach jest wykonywana przy użyciu DisplayWindowSettings .

Jest to próba wielosesyjności IME się na development/samples/MultiClientInputMethod .

Aby przetestować wielosesyjny edytor IME:

  1. Zestaw config_perDisplayFocusEnabled się true .
  2. Uruchom te polecenia:
    1. $ make -j MultiClientInputMethod
    2. $ adb install -r $OUT/system/priv-app/MultiClientInputMethod/MultiClientInputMethod.apk
    3. $ adb root
    4. $ adb shell setprop persist.debug.multi_client_ime \
      com.example.android.multiclientinputmethod/.MultiClientInputMethod
    5. $ adb reboot
  3. Wypróbuj wiele scenariuszy wprowadzania tekstu.

Realizacja

Zobacz MultiClientInputMethodManagerService do szczegółów implementacyjnych.