Compatibilité avec l'éditeur de mode de saisie

Les modifications apportées à ces zones spécifiques à l'affichage sont indiquées ci-dessous :

Android 10 est compatible avec le clavier logiciel pour les applications exécutées sur un écran autre que l'écran par défaut.

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

Il existe différents modes d'affichage du clavier logiciel de l'éditeur de méthode de saisie (IME). Le clavier logiciel s'affiche sur:

  • Écran identique sur lequel l'application active s'affiche.
  • 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 apparaît. Pour en savoir plus, consultez les pages suivantes:

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

Figure 1 : Clavier 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 passer d'un écran à l'autre pour suivre l'attention 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'écran lors de leur création.

Si une connexion est active sur l'écran A et qu'un champ de saisie demande la sélection de la saisie 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 affichage est sélectionné pour le IME. Si l'écran B est compatible avec l'affichage de l'IME et qu'il est autorisé à l'afficher, l'écran B est utilisé. Sinon, l'écran de l'appareil principal est sélectionné.
  4. Si l'écran sélectionné ne provient pas de l'écran A, la connexion est rétablie. InputMethodService est détruit, puis créé à nouveau.

Restriction de sécurité

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

Implémentation

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

L'implémentation dans WindowManager suit la fenêtre du mode de saisie (la fenêtre de l'IME dans laquelle le clavier virtuel est dessiné) et la cible du mode de saisie (la fenêtre dans laquelle 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 vers InputMethodService (IMS) et reconfigurer la disposition du clavier au moment de l'exécution lorsque vous déplacez le focus vers un autre écran.

Pour effectuer le basculement de la fenêtre IME entre les écrans, Android 10 implémente les éléments suivants:

  • La fenêtre cible de l'IME et de la saisie est désormais suivie par écran dans DisplayContent#mInputMethodWindow et DisplayContent#mInputMethodTarget, afin que WindowManager (WM) puisse gérer l'état de focus de l'IME indépendamment de chaque écran.
  • Côté IMMS, lorsque la requête de mise au point d'un client d'application à partir 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 le lie à nouveau pour rattacher le nouveau jeton de fenêtre IME pour l'écran externe dans onServiceConnected().
  • Côté 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 des modifications de configuration d'affichage au niveau du processus à l'aide de WindowProcessController au processus IME pour remplacer les ressources et les métriques d'affichage.
    • 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.