Compatibilidad con el editor de métodos de entrada

Las actualizaciones realizadas en estas áreas específicas de visualización se proporcionan a continuación:

Android 10 es compatible con el teclado de software para aplicaciones que se ejecutan en una pantalla no predeterminada.

Aplicaciones que se ejecutan en una pantalla no predeterminada

En cuanto a qué pantalla muestra el teclado de software del Editor de métodos de entrada (IME), existen diferentes modos. El teclado del software se muestra en:

  • Misma pantalla en la que aparece la aplicación enfocada.
  • Pantalla predeterminada mientras la aplicación enfocada se ejecuta en una pantalla no predeterminada.
  • No hay pantalla en absoluto.

El sistema determina qué modo usar en función de la configuración de la pantalla en la que aparece la aplicación enfocada. Para más detalles, consulte:

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

Figura 1. Teclado de software IME tal como aparece en la pantalla secundaria, incluida la aplicación de destino

El sistema usa un solo IME, pero puede cambiar entre pantallas para seguir el enfoque del usuario. Android 10 espera automáticamente que todos los IME propios y de terceros revisen el diseño y cambien el tamaño de acuerdo con el nuevo tamaño de pantalla cuando se crean.

Si hay una conexión activa en la pantalla A y un campo de entrada solicita el enfoque de entrada en la pantalla B, se produce el siguiente flujo:

  1. Una nueva conexión de entrada proviene del campo de entrada en la pantalla B.
  2. InputMethodManagerService comprueba si se debe aprobar la conexión.
  3. Se selecciona una pantalla para el IME. Si la pantalla B admite mostrar el IME y se le permite mostrarlo, entonces se usa B. De lo contrario, se selecciona la pantalla del dispositivo principal.
  4. Si la pantalla seleccionada no es de la pantalla A, se restablece la conexión. InputMethodService se destruye y luego se vuelve a crear.

Restricción de seguridad

El sistema no mostrará un IME en pantallas virtuales que no sean propiedad del sistema. Esto se debe a un problema de seguridad de que una aplicación maliciosa podría crear una pantalla virtual con compatibilidad con decoraciones del sistema habilitadas y leer información confidencial del usuario desde la superficie, como escribir predicciones y fondos personalizados.

Implementación

En Android 9 (y versiones anteriores), el IME solo estaba disponible en la pantalla predeterminada, como se describe en Métodos de entrada en pantalla . En Android 10 (y versiones posteriores), un usuario puede cambiar entre diferentes campos de texto de entrada en diferentes pantallas cambiando el enfoque, y la ventana IME se mueve a las pantallas secundarias.

La implementación en WindowManager rastrea la ventana del método de entrada (la ventana IME donde se dibuja el teclado en pantalla) y el destino del método de entrada (la ventana donde va la entrada IME) para administrar el estado IME.

Para InputMethodManagerService (IMMS), ningún otro mecanismo integrado puede propagar el cambio de visualización a InputMethodService (IMS) y reconfigurar la distribución del teclado en tiempo de ejecución al mover el foco a otra pantalla.

Para lograr el cambio de ventana IME entre pantallas, Android 10 implementa lo siguiente:

  • El IME y la ventana de destino de entrada ahora se rastrean por pantalla en DisplayContent#mInputMethodWindow y DisplayContent#mInputMethodTarget , de modo que WindowManager (WM) puede administrar el estado de enfoque de IME independientemente de cada pantalla.
  • En el lado de IMMS, cuando la solicitud de enfoque de un cliente de aplicación desde la pantalla externa se recibe a través de ViewRootImpl#handleWindowFocusChanged -> InputMethodManager#onPostWindowFocus -> IMMS#startInputOrWindowGainedFocus , primero desvincula el servicio de método de entrada actual y luego vuelve a vincular el servicio para volver a conectar el nuevo IME token de ventana para la pantalla externa en onServiceConnected() .
  • En el lado de IMS, después de recibir IMS#attachToken , ocurre el siguiente flujo:
    • Se llama ContextImpl#updateDisplay para actualizar la visualización del contexto del servicio en InputMethodService#attachToken() . Esto llama a ViewGroup#addView() para revisar el diseño del teclado y adaptarlo a la pantalla de destino comprobando el contexto actual.
    • Después de llamar a DisplayContent#setInputMethodWindowLocked() , la implementación envía los cambios de configuración de visualización a nivel de proceso mediante WindowProcessController al proceso IME para anular los recursos y mostrar las métricas.
    • El cliente InputMethodService obtiene la configuración correcta con las métricas de visualización correctas después de onConfigurationChanged() y la llamada ViewGroup#addView() para reinicializar la vista de entrada.