Compatibilidad con decoraciones del sistema

A continuación, se proporcionan las actualizaciones que se realizan en estas áreas específicas de la pantalla:

Decoraciones del sistema

Android 10 agrega compatibilidad para la configuración de pantallas para mostrar ciertas decoraciones del sistema, como fondo de pantalla, barra de navegación, y selector. De forma predeterminada, la pantalla principal muestra todas las decoraciones del sistema. las pantallas secundarias muestran aquellas habilitadas opcionalmente. Compatibilidad con un editor de método de entrada (IME) se pueden establecer por separado de otras decoraciones del sistema.

Usa DisplayWindowSettings#setShouldShowSystemDecorsLocked() para agregar compatibilidad con decoraciones del sistema en una pantalla específica un valor predeterminado en /data/system/display_settings.xml. Por ejemplo: consulta Configuración de la ventana de visualización.

Implementación

DisplayWindowSettings#setShouldShowSystemDecorsLocked() también se expone en WindowManager#setShouldShowSystemDecors() para realizar pruebas. Activación de este método con la intención de habilitar decoraciones del sistema no agrega ventanas decorativas que se hayan que faltaban o quitarlos si estaban presentes. En la mayoría casos, el cambio de compatibilidad con las decoraciones del sistema tiene efecto completo solo después de que reiniciar el dispositivo.

Comprueba la compatibilidad de las decoraciones del sistema en la base de código de WindowManager normalmente pasan por DisplayContent#supportsSystemDecorations() mientras comprueba servicios externos (como IU del sistema, para comprobar si la barra de navegación utiliza WindowManager#shouldShowSystemDecors(). Para comprender qué controla este parámetro de configuración, explora los puntos de llamada de estos métodos.

Ventanas de decoración de la IU del sistema

Android 10 agrega compatibilidad con ventanas de decoración del sistema Solo para la barra de navegación, ya que esta es esencial para navegar entre actividades y apps. De forma predeterminada, la barra de navegación muestra Las posibilidades de Atrás y Inicio Esto se incluye solo si la pantalla de destino admite del sistema (consulta DisplayWindowSettings).

La barra de estado es una ventana del sistema más complicada, ya que también incluye Panel de notificaciones, Configuración rápida y Pantalla de bloqueo. En Android 10, no se admite la barra de estado en pantallas secundarias. Por lo tanto, las notificaciones, la configuración y un bloqueo de teclado completo solo están disponibles en la pantalla principal.

La ventana del sistema Vista general/Recientes no se admite en las pantallas. En Android 10, el AOSP solo muestra Recientes en la la pantalla predeterminada y contiene actividades de todas las pantallas. Cuando se inicia desde Recientes, una actividad que estaba en una pantalla secundaria aparece al frente en esa pantalla de forma predeterminada. Este enfoque tiene algunos problemas conocidos, se actualiza inmediatamente cuando las apps aparecen en otras pantallas.

Implementación

Para implementar funciones adicionales de la IU del sistema, los fabricantes de dispositivos deben usar un un único componente de IU del sistema que escucha cuando se agregan o quitan pantallas y presente contenido apropiado.

Un componente de IU del sistema compatible con pantallas múltiples (MD) debe controlar las los siguientes casos:

  • Inicialización de varias pantallas al inicio
  • Se agregó la pantalla durante el tiempo de ejecución
  • Se quitó la pantalla durante el tiempo de ejecución

Cuando la IU del sistema detecta la adición de una pantalla antes de WindowManager, crea una condición de carrera. Esto se puede evitar implementando una devolución de llamada personalizada de WindowManager a la IU del sistema cuando se agrega una pantalla en lugar de suscribirte a DisplayManager.DisplayListener. Para una implementación de referencia, Consulta CommandQueue.Callbacks#onDisplayReady para obtener información sobre la compatibilidad con la barra de navegación. y WallpaperManagerInternal#onDisplayReady para los fondos de pantalla.

Además, Android 10 proporciona las siguientes actualizaciones:

  • La clase NavigationBarController controla todas las funciones específicas de las barras de navegación.
  • Para ver una barra de navegación personalizada, consulta CarStatusBar.
  • TYPE_NAVIGATION_BAR ya no está restringido a un solo y se puede usar por pantalla.
  • Se actualizó IWindowManager#hasNavigationBar() para incluir El parámetro displayId solo para la IU del sistema.

Selector

En Android 10, cada pantalla configurada para admitir del sistema tiene una pila de inicio dedicada para las actividades del selector con el tipo WindowConfiguration#ACTIVITY_TYPE_HOME, de forma predeterminada. Cada pantalla usa una instancia separada de la actividad iniciadora.

Figura 1: Ejemplo de selector de varias pantallas para platform/development/samples/MultiDisplay

La mayoría de los selectores existentes no admiten varias instancias y no están optimizados para tamaños de pantalla grandes. Además, a menudo se espera un tipo diferente en pantallas secundarias/externas. Para proporcionar una actividad dedicada para actividades pantallas, Android 10 introduce la categoría SECONDARY_HOME en intents filtros. Las instancias de esta actividad se utilizan en todas las pantallas que admiten el sistema decoraciones, una por pantalla. 

<activity>
    ...
    <intent-filter>
        <category android:name="android.intent.category.SECONDARY_HOME" />
        ...
    </intent-filter>
</activity>

La actividad debe tener un modo de lanzamiento que no impida que varias y se espera que se adapte a diferentes tamaños de pantalla. El modo de lanzamiento no puede ser singleInstance ni singleTask.

Implementación

En Android 10, RootActivityContainer#startHomeOnDisplay() selecciona automáticamente el componente y la intención deseados según la pantalla en la que se inicia la pantalla principal. RootActivityContainer#resolveSecondaryHomeActivity() contiene la lógica para buscar el componente de la actividad iniciadora según la configuración y puede usar el selector predeterminado del sistema, si es necesario (consulta ActivityTaskManagerService#getSecondaryHomeIntent()).

Restricciones de seguridad

Además de las restricciones que se aplican a las actividades en pantallas secundarias, para evitar que una app maliciosa cree una pantalla virtual con la función Decoraciones del sistema y leer información sensible del usuario desde la superficie, el selector solo aparece en pantallas virtuales que son propiedad del sistema. El selector no muestra contenido en pantallas virtuales ajenas al sistema.

Fondos de pantalla

En Android 10 (y versiones posteriores), se admiten los fondos de pantalla en pantallas secundarias:

Figura 2: Fondo de pantalla animado en la imagen interna (arriba) y externa pantallas (debajo)

Los desarrolladores pueden declarar su compatibilidad con la función de fondo de pantalla proporcionando android:supportsMultipleDisplays="true" en Definición XML de WallpaperInfo. Los desarrolladores de fondos de pantalla también se espera que carguen los recursos usando el contexto de visualización en WallpaperService.Engine#getDisplayContext()

El framework crea una instancia de WallpaperService.Engine. por pantalla, de modo que cada motor tenga su propio contexto de superficie y visualización. El el desarrollador debe asegurarse de que cada motor pueda dibujar de manera independiente, al con distintas velocidades de fotogramas en función de VSYNC.

Cómo seleccionar fondos de pantalla para pantallas individuales

Android 10 no proporciona compatibilidad directa con la plataforma para seleccionar fondos de pantalla para pantallas individuales. Para lograr esto, se usa un identificador de pantalla estable necesario para conservar la configuración del fondo de pantalla por pantalla. Display#getDisplayId() es dinámico, por lo que no hay garantía de que un la pantalla física tendrá el mismo ID después del reinicio.

Sin embargo, Android 10 agregó DisplayInfo.mAddress, que contiene identificadores estables para pantallas físicas y se puede utilizar para una para implementarlos en el futuro. Por desgracia, es demasiado tarde para implementar la lógica para Android 10. La solución sugerida:

  1. Usa la API de WallpaperManager para establecer los fondos de pantalla.
  2. WallpaperManager se obtiene de un Context objeto, y cada objeto Context tiene información sobre los datos pantalla (Context#getDisplay()/getDisplayId()). Por lo tanto, puedes obtener displayId de una instancia de WallpaperManager sin agregar nuevos métodos.
  3. En el lado del framework, usa displayId obtenido de un Context y asígnalo a un identificador estático (como un puerto de una pantalla física). Usa el identificador estático para conservar el fondo de pantalla elegido.

En esta solución alternativa, se usan implementaciones existentes para los selectores de fondo de pantalla. Si se abrió en una pantalla específica y usa el contexto correcto, y luego, cuando llamadas para establecer un fondo de pantalla, el sistema puede identificar la pantalla automáticamente.

Si necesitas establecer un fondo de pantalla para una pantalla que no sea la actual Display y, luego, crea un objeto Context nuevo para la visualización de destino. (Context#createDisplayContext) y obtén la WallpaperManager de esa pantalla.

Restricciones de seguridad

El sistema no mostrará fondos de pantalla en pantallas virtuales que no sean de su propiedad. Esto se debe a un problema de seguridad de que una aplicación maliciosa podría crear una red con decoraciones habilitadas del sistema y leer un mensaje sensible información de la superficie (como una foto personal).

Implementación

En Android 10, IWallpaperConnection#attachEngine() y IWallpaperService#attach() aceptan las Parámetro displayId para crear conexiones por pantalla. WallpaperManagerService.DisplayConnector encapsula una vista por pantalla el motor y la conexión del fondo de pantalla. En WindowManager, los controladores del fondo de pantalla son para cada objeto DisplayContent en la construcción, en lugar de un una sola WallpaperController para todas las pantallas.

Algunas de las implementaciones públicas del método WallpaperManager (como WallpaperManager#getDesiredMinimumWidth()) se actualizaron para calcular y proporciona información para las pantallas correspondientes. WallpaperInfo#supportsMultipleDisplays() y un nombre de campo se agregaron atributos de recursos para que los desarrolladores de apps puedan informar qué los fondos de pantalla están listos para usarse en varias pantallas.

Si el servicio de fondo de pantalla que se muestra en la pantalla predeterminada no es compatible varias pantallas, el sistema muestra el fondo de pantalla predeterminado en la pantalla pantallas.

Figura 3: Lógica de resguardo de fondo de pantalla para pantallas secundarias