Obsługa edytora metod wprowadzania

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

Android 10 obsługuje klawiaturę programową dla aplikacji działających na ekranie innym 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:

  • Ten sam ekran, na którym pojawia się wybrana aplikacja.
  • Domyślny ekran, gdy aplikacja, na której ma fokus, działa na ekranie innym 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. Klawiatura oprogramowania IME wyświetlana na dodatkowym wyświetlaczu, w tym aplikacja docelowa

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 jest niszczony, a następnie ponownie tworzony.

Ograniczenia bezpieczeństwa

System nie wyświetli edytora IME na wirtualnych wyświetlaczach, które nie są własnością systemu. Wynika to z obawy o bezpieczeństwo, że złośliwa aplikacja może utworzyć wirtualny wyświetlacz z włączoną obsługą dekoracji systemu i odczytywać z powierzchni informacje wrażliwe dla użytkownika, takie jak przewidywania pisania i niestandardowe tła.

Realizacja

W systemie Android 9 (i niższych) edytor IME był dostępny tylko na ekranie domyślnym, zgodnie z opisem w sekcji Metody wprowadzania na ekranie . W systemie Android 10 (i nowszych) 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.

Implementacja w WindowManager śledzi okno metody wprowadzania (okno IME, w którym rysowana jest klawiatura programowa) oraz cel metody wprowadzania (okno, do którego trafia wejście IME), aby zarządzać stanem IME.

W przypadku InputMethodManagerService (IMMS) żaden inny wbudowany mechanizm nie może propagować zmiany wyświetlania do InputMethodService (IMS) i ponownie konfigurować układu klawiatury w czasie wykonywania podczas przenoszenia fokusu na inny ekran.

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

  • Edytor IME i okno docelowe wprowadzania są teraz śledzone na ekran w DisplayContent#mInputMethodWindow i DisplayContent#mInputMethodTarget , dzięki czemu WindowManager (WM) może zarządzać stanem fokusu IME niezależnie od każdego ekranu.
  • Po stronie IMMS, gdy żądanie skupienia klienta aplikacji z wyświetlacza zewnętrznego zostanie odebrane przez ViewRootImpl#handleWindowFocusChanged -> InputMethodManager#onPostWindowFocus -> IMMS#startInputOrWindowGainedFocus , najpierw rozwiązuje bieżącą usługę metody wprowadzania, a następnie ponownie dołącza nową usługę do IME token okna dla zewnętrznego wyświetlacza w onServiceConnected() .
  • Po stronie IMS po IMS#attachToken następuje następujący przepływ:
    • ContextImpl#updateDisplay jest wywoływana w celu zaktualizowania wyświetlania kontekstu usługi w InputMethodService#attachToken() . Wywołuje to ViewGroup#addView() w celu zrewidowania układu klawiatury i dostosowania się do docelowego ekranu, sprawdzając bieżący kontekst.
    • Po DisplayContent#setInputMethodWindowLocked() implementacja wysyła zmiany konfiguracji wyświetlania na poziomie procesu za pomocą WindowProcessController do procesu IME w celu zastąpienia zasobów i metryk wyświetlania.
    • Klient InputMethodService pobiera poprawną konfigurację z poprawnymi metrykami wyświetlania po onConfigurationChanged() i ViewGroup#addView() w celu ponownego zainicjowania widoku 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:

Rysunek 2. Przykładowy wielosesyjny IME

Rysunek 3. Przykładowy wielosesyjny IME

Obsługa fokusu na ekran 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 można używać istniejących edytorów IME dla Androida zbudowanych na bazie klasy InputMethodService , ponieważ założenie, że pojedynczy klient IME może być skoncentrowany w tym samym czasie, zostało przyjęte przed wprowadzeniem interfejsów API Android IME w systemie Android 1.5 i wielu publicznych interfejsów API w InputMethodService już mocno opierał się na tym założeniu. Jednak zaktualizowanie klasy InputMethodService w celu obsługi scenariusza z wieloma klientami jest trudne, ponieważ:

  1. Spowoduje to wprowadzenie niedopuszczalnej ilości złożoności do InputMethodService , która jest już trudna 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 jednosesyjnego (zwykłego) edytora IME, sterowanie wyświetlaniem IME na poszczególnych ekranach odbywa się za pomocą DisplayWindowSettings .

Istnieje przykładowy wielosesyjny edytor IME znajdujący się w development/samples/MultiClientInputMethod .

Aby przetestować wielosesyjny edytor IME:

  1. Ustaw config_perDisplayFocusEnabled na 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 szczegóły implementacji.