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 écran 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 deux modes différents. Le clavier logiciel est affiché sur :

  • Même écran 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.

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 :

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

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 passer d'un affichage à l'autre pour suivre l'attention de l'utilisateur. Android 10 s'attend automatiquement à ce que tous les IME propriétaires et tiers modifient la mise en page et redimensionnent en fonction de la nouvelle taille d'affichage lors de la création.

S'il existe une connexion active sur l'écran A et qu'un champ de saisie demande le focus 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 de l'appareil principal est sélectionné.
  4. Si l'affichage sélectionné ne provient pas de l'affichage A, 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 des décorations système activée et lire des informations sensibles pour l'utilisateur à partir de la surface, telles que des prédictions de frappe et des arrière-plans personnalisés.

Mise en œuvre

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 basculer entre différents champs de texte de saisie sur différents écrans en changeant de focus, et la fenêtre IME passe aux écrans secondaires.

L'implémentation dans WindowManager suit la fenêtre de la méthode d'entrée (la fenêtre IME où le clavier logiciel est dessiné) et la cible de la méthode d'entrée (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 le changement d'affichage vers InputMethodService (IMS) et reconfigurer la disposition du clavier lors de l'exécution lors du déplacement du focus vers un autre affichage.

Pour réaliser le basculement de la fenêtre IME entre les écrans, Android 10 implémente ce qui suit :

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

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

Les implémentations de dispositifs avec plusieurs affichages censés être utilisés simultanément par plusieurs utilisateurs pour fournir des sources d'entrée appropriées peuvent être configurées pour afficher simultanément plusieurs éditeurs de méthode d'entrée (IME), au plus un par affichage. Les deux figures suivantes montrent un exemple d'IME multisession sur deux écrans :

Figure 2. Exemple d'IME multisession

Figure 3. Exemple d'IME multisession

La prise en charge de la mise au point par affichage est une condition préalable à cette fonctionnalité. Sinon, cette fonctionnalité ne peut pas être activée. En raison de restrictions de sécurité, la limitation de la mise au point par écran a limité cette fonctionnalité à un petit sous-ensemble d'appareils.

Dans Android 10, la prise en charge des IME multisession est implémentée avec des services système distincts avec un ensemble d'API différent et des fonctionnalités réduites. L'IME multisession n'est pas compatible avec les IME existants. Le service multi-session ou mono-session peut être utilisé, mais pas les deux.

Il n'est pas possible d'utiliser les IME Android existants construits au-dessus de la classe InputMethodService car l'hypothèse selon laquelle un seul client IME peut être ciblé en même temps a été faite avant l'introduction des API IME Android dans Android 1.5 et de nombreuses API publiques dans InputMethodService ont s'appuyait déjà beaucoup sur cette hypothèse. Cependant, la mise à jour de la classe InputMethodService pour prendre en charge un scénario multi-client est difficile car :

  1. Cela introduirait une complexité inacceptable dans InputMethodService , qui est déjà difficile à maintenir.
  2. Les développeurs IME doivent encore mettre à jour leur implémentation pour pouvoir prendre en charge les requêtes parallèles de plusieurs clients IME ciblés, ce qui peut nécessiter une refonte non triviale de leur côté (comme le décodeur d'entrée et la base de données d'historique de frappe).
  3. Les cas d'utilisation réels des clients multi-IME devraient évoluer rapidement, de sorte que le nouveau protocole n'est pas stable et n'est pas prêt à être exposé en tant qu'API publiques.

Comme avec l'IME à session unique (régulier), le contrôle de l'affichage de l'IME sur des écrans individuels est effectué à l'aide DisplayWindowSettings .

Il existe un exemple d'IME multisession situé dans development/samples/MultiClientInputMethod .

Pour tester l'IME multisession :

  1. Définissez config_perDisplayFocusEnabled sur true .
  2. Exécutez ces commandes :
    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. Essayez plusieurs scénarios de saisie de texte.

Mise en œuvre

Voir MultiClientInputMethodManagerService pour les détails d'implémentation.

,

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 écran 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 deux modes différents. Le clavier logiciel est affiché sur :

  • Même écran 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.

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 :

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

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 passer d'un affichage à l'autre pour suivre l'attention de l'utilisateur. Android 10 s'attend automatiquement à ce que tous les IME propriétaires et tiers modifient la mise en page et redimensionnent en fonction de la nouvelle taille d'affichage lors de la création.

S'il existe une connexion active sur l'écran A et qu'un champ de saisie demande le focus 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 de l'appareil principal est sélectionné.
  4. Si l'affichage sélectionné ne provient pas de l'affichage A, 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 des décorations système activée et lire des informations sensibles pour l'utilisateur à partir de la surface, telles que des prédictions de frappe et des arrière-plans personnalisés.

Mise en œuvre

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 basculer entre différents champs de texte de saisie sur différents écrans en changeant de focus, et la fenêtre IME passe aux écrans secondaires.

L'implémentation dans WindowManager suit la fenêtre de la méthode d'entrée (la fenêtre IME où le clavier logiciel est dessiné) et la cible de la méthode d'entrée (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 le changement d'affichage vers InputMethodService (IMS) et reconfigurer la disposition du clavier lors de l'exécution lors du déplacement du focus vers un autre affichage.

Pour réaliser le basculement de la fenêtre IME entre les écrans, Android 10 implémente ce qui suit :

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

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

Les implémentations de dispositifs avec plusieurs affichages censés être utilisés simultanément par plusieurs utilisateurs pour fournir des sources d'entrée appropriées peuvent être configurées pour afficher simultanément plusieurs éditeurs de méthode d'entrée (IME), au plus un par affichage. Les deux figures suivantes montrent un exemple d'IME multisession sur deux écrans :

Figure 2. Exemple d'IME multisession

Figure 3. Exemple d'IME multisession

La prise en charge de la mise au point par affichage est une condition préalable à cette fonctionnalité. Sinon, cette fonctionnalité ne peut pas être activée. En raison de restrictions de sécurité, la limitation de la mise au point par écran a limité cette fonctionnalité à un petit sous-ensemble d'appareils.

Dans Android 10, la prise en charge des IME multisession est implémentée avec des services système distincts avec un ensemble d'API différent et des fonctionnalités réduites. L'IME multisession n'est pas compatible avec les IME existants. Le service multi-session ou mono-session peut être utilisé, mais pas les deux.

Il n'est pas possible d'utiliser les IME Android existants construits au-dessus de la classe InputMethodService car l'hypothèse selon laquelle un seul client IME peut être ciblé en même temps a été faite avant l'introduction des API IME Android dans Android 1.5 et de nombreuses API publiques dans InputMethodService ont s'appuyait déjà beaucoup sur cette hypothèse. Cependant, la mise à jour de la classe InputMethodService pour prendre en charge un scénario multi-client est difficile car :

  1. Cela introduirait une complexité inacceptable dans InputMethodService , qui est déjà difficile à maintenir.
  2. Les développeurs IME doivent encore mettre à jour leur implémentation pour pouvoir prendre en charge les requêtes parallèles de plusieurs clients IME ciblés, ce qui peut nécessiter une refonte non triviale de leur côté (comme le décodeur d'entrée et la base de données d'historique de frappe).
  3. Les cas d'utilisation réels des clients multi-IME devraient évoluer rapidement, de sorte que le nouveau protocole n'est pas stable et n'est pas prêt à être exposé en tant qu'API publiques.

Comme avec l'IME à session unique (régulier), le contrôle de l'affichage de l'IME sur des écrans individuels est effectué à l'aide DisplayWindowSettings .

Il existe un exemple d'IME multisession situé dans development/samples/MultiClientInputMethod .

Pour tester l'IME multisession :

  1. Définissez config_perDisplayFocusEnabled sur true .
  2. Exécutez ces commandes :
    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. Essayez plusieurs scénarios de saisie de texte.

Mise en œuvre

Voir MultiClientInputMethodManagerService pour les détails d'implémentation.