Prise en charge de l'éditeur de mode de saisie

Vous trouverez ci-dessous les modifications apportées à ces zones spécifiques à l'affichage :

Android 10 est compatible avec le clavier virtuel pour les applications s'exécutant sur un écran autre que celui par défaut.

Applications s'exécutant sur un écran autre que celui par défaut

Il existe différents modes pour déterminer sur quel écran le clavier virtuel de l'éditeur de mode de saisie (IME) s'affiche. Le clavier virtuel s'affiche sur :

  • Même : l'application sélectionnée s'affiche sur le même écran.
  • Affichage par défaut lorsque l'application sélectionnée s'exécute sur un écran autre que celui par défaut.
  • Aucun affichage.

Le système détermine le mode à utiliser en fonction des paramètres de l'écran sur lequel l'application sélectionnée s'affiche. Pour en savoir plus, consultez les ressources suivantes :

  • WindowManager#setDisplayImePolicy()
  • WindowManager#getDisplayImePolicy()

Figure 1. Clavier virtuel IME tel qu'il apparaît sur l'écran secondaire, y compris l'application cible

Le système utilise un seul IME, mais peut passer d'un écran à l'autre pour suivre la sélection de l'utilisateur. Android 10 s'attend automatiquement à ce que tous les IME propriétaires et tiers révisent la mise en page et la redimensionnent en fonction de la nouvelle taille d'affichage lors de leur création.

Si une connexion active est établie sur l'écran A et qu'un champ de saisie demande le focus d'entrée sur l'écran B, le flux suivant se produit :

  1. Une nouvelle connexion d'entrée provient du champ de saisie de l'écran B.
  2. InputMethodManagerService vérifie si la connexion doit être approuvée.
  3. Un écran est sélectionné pour l'IME. Si l'écran B est compatible avec l'IME et est autorisé à l'afficher, il est utilisé. Sinon, l'écran de l'appareil principal est sélectionné.
  4. Si l'écran sélectionné n'est pas l'écran A, la connexion est rétablie. InputMethodService est détruit, puis recréé.

Restriction de sécurité

Le système n'affiche pas d'IME sur les écrans virtuels qui ne lui appartiennent pas. Cela est dû à un problème de sécurité : une application malveillante pourrait créer un écran virtuel avec la prise en charge des décorations système activée et lire des informations sensibles de la surface, telles que les prédictions de saisie et les arrière-plans personnalisés.

Implémentation

Dans Android 9 (et versions antérieures), l'IME n'était disponible que sur l'écran par défaut, comme décrit dans Méthodes de saisie à l'écran. Dans Android 10 (et versions ultérieures), un utilisateur peut passer d'un champ de saisie de texte à un autre sur différents écrans en changeant de focus, et la fenêtre IME se déplace vers les écrans secondaires.

L'implémentation dans WindowManager suit la fenêtre de méthode de saisie (la fenêtre IME où le clavier virtuel est dessiné) et la cible de méthode de saisie (la fenêtre où la saisie IME est effectuée) pour gérer l'état de l'IME.

Pour InputMethodManagerService (IMMS), aucun autre mécanisme intégré ne peut propager le changement d'affichage à InputMethodService (IMS) et reconfigurer la disposition du clavier au moment de l'exécution lorsque le focus est déplacé vers un autre écran.

Pour que la fenêtre IME puisse basculer entre les écrans, Android 10 implémente les éléments suivants :

  • L'IME et la fenêtre cible de saisie sont désormais suivis par écran dans DisplayContent#mInputMethodWindow et DisplayContent#mInputMethodTarget, afin que le WindowManager (WM) puisse gérer l'état de focus de l'IME indépendamment de chaque écran.
  • Du côté de l'IMMS, lorsqu'une requête de focus d'un client d'application provenant de l'écran externe est reçue via ViewRootImpl#handleWindowFocusChanged -> InputMethodManager#onPostWindowFocus -> IMMS#startInputOrWindowGainedFocus, le service de méthode de saisie actuel est d'abord dissocié, puis réassocié pour rattacher le nouveau jeton de fenêtre IME pour l'écran externe dans onServiceConnected().
  • Du côté de l'IMS, une fois le IMS#attachToken reçu, le flux suivant se produit :
    • ContextImpl#updateDisplay est appelé pour mettre à jour l'affichage du contexte de service dans InputMethodService#attachToken(). Cela appelle ViewGroup#addView() pour réviser la mise en page du clavier et s'adapter à l'écran cible en vérifiant le contexte actuel.
    • Une fois DisplayContent#setInputMethodWindowLocked() appelé, l'implémentation envoie les modifications de configuration de l'affichage au niveau du processus à l'aide de WindowProcessController au processus IME pour remplacer les ressources et afficher les métriques.
    • Le client InputMethodService obtient la configuration correcte avec les métriques d'affichage appropriées après onConfigurationChanged() et l'appel ViewGroup#addView() pour réinitialiser la vue d'entrée.