Prise en charge de l'éditeur de méthode d'entrée

Les mises à jour apportées à ces zones spécifiques à l'affichage sont fournies ci-dessous :

Android 10 prend en charge le clavier logiciel pour les applications exécutées sur un écran autre que celui par défaut.

Applications exécutées sur un affichage autre que celui par défaut

En ce qui concerne l'affichage qui affiche le clavier logiciel de l'éditeur de méthode d'entrée (IME), il existe différents modes. Le clavier logiciel est affiché sur :

  • Même affichage sur lequel l’application ciblée apparaît.
  • Affichage par défaut lorsque l'application ciblée s'exécute sur un affichage autre que celui par défaut.
  • Aucun affichage du tout.

Le système détermine le mode à utiliser en fonction des paramètres de l'écran sur lequel l'application ciblée apparaît. Pour plus de détails, voir :

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

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

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

S'il existe une connexion active sur l'écran A et qu'un champ de saisie demande le focus de saisie sur l'écran B, le flux suivant se produit :

  1. Une nouvelle connexion d'entrée provient du champ de saisie sur l'écran B.
  2. InputMethodManagerService vérifie si la connexion doit être approuvée.
  3. Un affichage est sélectionné pour l'IME. Si l'affichage B prend en charge l'affichage de l'IME et est autorisé à l'afficher, alors B est utilisé. Sinon, l'affichage principal du périphérique est sélectionné.
  4. Si l'affichage sélectionné ne provient pas de l'affichage A, alors la connexion est rétablie. InputMethodService est détruit puis recréé.

Restriction de sécurité

Le système n'affichera pas d'IME sur les écrans virtuels qui n'appartiennent pas au système. Cela est dû à un problème de sécurité selon lequel une application malveillante pourrait créer un affichage virtuel avec la prise en charge activée des décorations système et lire des informations sensibles pour l'utilisateur à partir de la surface, telles que les prédictions de frappe et les arrière-plans personnalisés.

Mise en œuvre

Sous 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 basculer entre différents champs de texte de saisie sur différents écrans en changeant le focus, et la fenêtre IME se déplace vers les écrans secondaires.

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

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

Pour réaliser le basculement de fenêtre IME entre les affichages, Android 10 implémente les éléments suivants :

  • L'IME et la fenêtre cible d'entrée sont désormais suivis par affichage dans DisplayContent#mInputMethodWindow et DisplayContent#mInputMethodTarget , afin que WindowManager (WM) puisse gérer l'état du focus IME indépendamment de chaque affichage.
  • Du côté IMMS, lorsque la demande de focus d'un client d'application provenant de l'écran externe est reçue via ViewRootImpl#handleWindowFocusChanged -> InputMethodManager#onPostWindowFocus -> IMMS#startInputOrWindowGainedFocus , elle dissocie d'abord le service de méthode d'entrée actuel, puis relie à nouveau le service pour rattacher le nouvel IME. jeton de fenêtre pour l’affichage externe dans onServiceConnected() .
  • Du côté IMS, après la réception du IMS#attachToken , 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 disposition du clavier et l'adapter à l'affichage cible en vérifiant le contexte actuel.
    • Après l'appel DisplayContent#setInputMethodWindowLocked() , l'implémentation envoie les modifications de configuration d'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 correctes après onConfigurationChanged() et l'appel ViewGroup#addView() pour réinitialiser la vue d'entrée.