Compatibilidad con decoraciones del sistema

Las actualizaciones realizadas en estas áreas específicas de la pantalla se proporcionan en esta página.

Decoraciones del sistema

Android 10 agrega compatibilidad para configurar pantallas secundarias para mostrar ciertas decoraciones del sistema, como el fondo de pantalla, la barra de navegación y el selector. De forma predeterminada, la pantalla principal muestra todas las decoraciones del sistema, y las pantallas secundarias muestran las que están habilitadas de forma opcional. Puedes configurar la compatibilidad con un editor de método de entrada (IME) por separado de otras decoraciones del sistema.

Usa DisplayWindowSettings#setShouldShowSystemDecorsLocked para agregar compatibilidad con las decoraciones del sistema en una pantalla específica o proporcionar un valor predeterminado en /data/system/display_settings.xml. Para ver ejemplos, consulta Configuración de la ventana de visualización.

Implementación

DisplayWindowSettings#setShouldShowSystemDecorsLocked también se expone en WindowManager#setShouldShowSystemDecors para realizar pruebas. Activar este método con la intención de habilitar las decoraciones del sistema no agrega ventanas de decoración que faltaban anteriormente ni las quita si estaban presentes. En la mayoría de los casos, el cambio de compatibilidad con las decoraciones del sistema entra en vigencia solo después de reiniciar el dispositivo.

Las verificaciones de compatibilidad con las decoraciones del sistema en la base de código de WindowManager suelen pasar por DisplayContent#supportsSystemDecorations, mientras que las verificaciones de servicios externos (como la IU del sistema para verificar si se debe mostrar la barra de navegación) usan 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 la ventana de decoración del sistema solo para la barra de navegación, ya que es esencial para navegar entre actividades y apps. De forma predeterminada, la barra de navegación muestra las opciones Atrás y Principal. La barra de navegación solo se incluye si la pantalla de destino admite decoraciones del sistema (consulta DisplayWindowSettings).

La barra de estado es una ventana del sistema más complicada, ya que también contiene el panel de notificaciones, la configuración rápida y la pantalla de bloqueo. En Android 10, la barra de estado no es compatible con pantallas secundarias. Por lo tanto, las notificaciones, la configuración y un protector de pantalla completo solo están disponibles en la pantalla principal.

La ventana del sistema Resumen o Recientes no es compatible con pantallas secundarias. En Android 10, AOSP solo muestra Recientes en la pantalla predeterminada y contiene actividades de todas las pantallas. Cuando se inicia desde Recientes, una actividad que estaba en una pantalla secundaria se muestra en primer plano en esa pantalla, de forma predeterminada. Este enfoque tiene algunos problemas conocidos, como no actualizarse de inmediato 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 solo componente de la IU del sistema que escuche la adición o eliminación de pantallas y presente el contenido adecuado.

Un componente de la IU del sistema que admite pantallas múltiples (MD) debe controlar los siguientes casos:

  • Inicialización de varias pantallas al inicio
  • Pantalla agregada en el tiempo de ejecución
  • Pantalla quitada en el tiempo de ejecución

Cuando la IU del sistema detecta la adición de una pantalla antes que WindowManager, crea una condición de carrera. Para evitar esto, implementa una devolución de llamada personalizada de WindowManager a la IU del sistema cuando se agrega una pantalla en lugar de suscribirte a eventos DisplayManager.DisplayListener. Para obtener una implementación de referencia, consulta CommandQueue.Callbacks#onDisplayAddSystemDecorations para la compatibilidad con la barra de navegación y WallpaperManagerInternal#onDisplayAddSystemDecorations para los fondos de pantalla.

Además, Android 10 proporciona estas 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 una sola instancia y se puede usar por pantalla.
  • IWindowManager#hasNavigationBar se actualiza para incluir el parámetro displayId solo para la IU del sistema.

Launcher

En Android 10, cada pantalla configurada para admitir decoraciones del sistema tiene una pila principal 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 del selector:

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 de experiencia diferente en pantallas secundarias o externas. Para proporcionar una actividad dedicada para las pantallas secundarias, Android 10 introdujo la categoría SECONDARY_HOME en los filtros de intents. Las instancias de esta actividad se utilizan en todas las pantallas que admiten decoraciones del sistema, una por cada pantalla. 

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

La actividad debe tener un modo de inicio que no impida múltiples instancias y que pueda adaptarse 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 el intent 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 del selector según el selector seleccionado actualmente y puede usar el valor 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 la posibilidad de que una app maliciosa cree una pantalla virtual con decoraciones del sistema habilitadas y lea información sensible del usuario desde la superficie, el selector solo aparece en las pantallas virtuales que son propiedad del sistema. El selector no muestra contenido en pantallas virtuales que no son del sistema.

Fondos de pantalla

En Android 10 y versiones posteriores, los fondos de pantalla son compatibles con pantallas secundarias:

Figura 2: Fondo animado en pantallas internas (arriba) y externas (abajo).

Los desarrolladores pueden declarar compatibilidad con la función de fondo de pantalla proporcionando android:supportsMultipleDisplays="true" en la definición XML de WallpaperInfo. También se espera que los desarrolladores de fondos de pantalla carguen elementos usando el contexto de la pantalla en WallpaperService.Engine#getDisplayContext.

El framework crea una instancia de WallpaperService.Engine por pantalla, por lo que cada motor tiene su propia superficie y contexto de pantalla. El desarrollador debe asegurarse de que cada motor pueda dibujar de forma independiente, a diferentes velocidades de fotogramas, respetando VSync.

Selecciona 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 necesita un identificador de pantalla estable 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 una pantalla física tenga el mismo ID después de reiniciar.

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

  1. Usa la clase WallpaperManager para configurar los fondos de pantalla.

    WallpaperManager se obtiene de un objeto Context, y cada objeto Context tiene información sobre la pantalla correspondiente (Context#getDisplay/getDisplayId). Por lo tanto, puedes obtener displayId de una instancia WallpaperManager sin agregar métodos nuevos.

  2. En el framework, usa displayId obtenido de un objeto 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.

Esta solución alternativa usa implementaciones existentes para selectores de fondos de pantalla. Si se abrió en una pantalla específica y usa el contexto correcto, cuando llama para configurar un fondo de pantalla, el sistema puede identificar automáticamente la pantalla.

Si es necesario configurar el fondo de pantalla para una pantalla que no sea la actual pantalla, crea un objeto Context nuevo para la pantalla de destino (Context#createDisplayContext) y obtén la WallpaperManager instancia 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 que podría crear una app maliciosa que cree una pantalla virtual con compatibilidad con decoraciones del sistema habilitada y lea información sensible del usuario desde la superficie (como una foto personal).

Implementación

En Android 10, las interfaces IWallpaperConnection#attachEngine y IWallpaperService#attach aceptan el parámetro displayId para crear conexiones por pantalla. WallpaperManagerService.DisplayConnector encapsula un motor y una conexión de fondo de pantalla por pantalla. En WindowManager, los controladores de fondo de pantalla se crean para cada objeto DisplayContent en la construcción en lugar de un solo WallpaperController para todas las pantallas.

Se actualizaron algunas de las implementaciones públicas del método WallpaperManager (como WallpaperManager#getDesiredMinimumWidth) para calcular y proporcionar información para las pantallas correspondientes. Se agregaron WallpaperInfo#supportsMultipleDisplays y un atributo de recurso correspondiente para que los desarrolladores de apps puedan informar qué fondos de pantalla están listos para varias pantallas.

Si el servicio de fondo de pantalla que se muestra en la pantalla predeterminada no admite varias pantallas, el sistema muestra el fondo de pantalla predeterminado en las pantallas secundarias:

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

Habilita la compatibilidad con fondos animados

En Android 10 y versiones posteriores (API 29), los desarrolladores pueden usar el android:supportsMultipleDisplays atributo para indicar si su fondo de pantalla puede abarcar varias pantallas. En entornos de ventanas de escritorio, donde la multitarea es densa, renderizar fondos de pantalla animados en pantallas externas puede afectar significativamente la GPU y la sobrecarga de memoria.

Para preservar los recursos del sistema, el sistema no renderiza fondos de pantalla animados en pantallas conectadas de forma predeterminada. Cuando un fondo animado está restringido por la configuración del sistema o el manifiesto de la app, el sistema renderiza un fondo de pantalla estático de resguardo.

Los OEM pueden ajustar esta experiencia habilitando la compatibilidad con fondos animados para hardware de alta gama o personalizando el resguardo estático para una apariencia de marca.

Si tu hardware puede renderizar varias instancias de fondos animados, anula la siguiente configuración:

Ruta de acceso a recursos frameworks/base/core/res/res/values/config.xml
Config Name config_isLiveWallpaperSupportedInDesktopExperience

Personaliza el fondo de pantalla de resguardo

Si los fondos de pantalla animados están inhabilitados o no son compatibles con el proveedor, el sistema usa un componente predeterminado. Puedes dirigir esto a tu propio proveedor de fondos de pantalla estáticos:

Ruta de acceso a recursos frameworks/base/core/res/res/values/config.xml
Config Name fallback_wallpaper_component

Implementa la compatibilidad con fondos de pantalla

Para aplicar estos cambios, usa una superposición de recursos en el tiempo de compilación en tu carpeta específica del dispositivo, que suele ser device/<vendor>/<product>/overlay/frameworks/base/core/res/res/values/.