Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Soporte de decoraciones del sistema

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

Decoraciones del sistema

Android 10 agrega soporte para configurar pantallas secundarias para mostrar ciertas decoraciones del sistema, como fondo de pantalla, barra de navegación y lanzador. Por defecto, la pantalla principal muestra todas las decoraciones del sistema, y ​​las pantallas secundarias muestran aquellas habilitadas opcionalmente. La compatibilidad con un Editor de métodos de entrada (IME) se puede configurar por separado de otras decoraciones del sistema.

Use DisplayWindowSettings#setShouldShowSystemDecorsLocked() para agregar soporte para decoraciones del sistema en una pantalla específica o proporcionar un valor predeterminado en /data/system/display_settings.xml . Para ver ejemplos, consulte Configuración de la ventana de visualización .

Implementación

DisplayWindowSettings#setShouldShowSystemDecorsLocked() también se expone en WindowManager#setShouldShowSystemDecors() para realizar pruebas. La activación de este método con la intención de habilitar decoraciones del sistema no agrega ventanas de decoración que faltaban anteriormente, ni las elimina si estaban presentes previamente. En la mayoría de los casos, el cambio de soporte de decoraciones del sistema tiene efecto completo solo después de reiniciar el dispositivo.

Las comprobaciones de compatibilidad de las decoraciones del sistema en la base de código de WindowManager generalmente pasan por DisplayContent#supportsSystemDecorations() mientras que las comprobaciones de servicios externos (como la interfaz de usuario del sistema para verificar si se debe mostrar la barra de navegación) usan WindowManager#shouldShowSystemDecors() . Para comprender lo que controla esta configuración, explore los puntos de llamada de estos métodos.

Ventanas decorativas de la interfaz de usuario del sistema

Android 10 añade soporte ventana de la decoración sistema para sólo la barra de navegación, debido a que la barra de navegación es esencial para navegar entre las actividades y aplicaciones. Por defecto, la barra de navegación muestra las posibilidades de Atrás y Inicio. Esto se incluye solo si la pantalla de destino admite decoraciones del sistema (consulte DisplayWindowSettings ).

La barra de estado es una ventana del sistema más complicada, porque también contiene Sombra de notificaciones, Configuración rápida y 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 bloqueo de teclado completo solo están disponibles en la pantalla principal.

La ventana del sistema Visión general / 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 coloca al frente en esa pantalla, de manera predeterminada. Este enfoque tiene algunos problemas conocidos, como no actualizarse inmediatamente cuando las aplicaciones aparecen en otras pantallas.

Implementación

Para implementar características adicionales de la interfaz de usuario del sistema, los fabricantes de dispositivos deben usar un solo componente de la interfaz de usuario del sistema que escuche la adición / eliminación de pantallas y presente el contenido apropiado.

Un componente de la interfaz de usuario del sistema que admita Multi-Display (MD) debe manejar los siguientes casos:

  • Inicialización de múltiples pantallas al inicio
  • Pantalla agregada en tiempo de ejecución
  • Pantalla eliminada en 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 desde WindowManager a la interfaz de usuario del sistema cuando se agrega una pantalla en lugar de suscribirse a los eventos DisplayManager .DisplayListener . Para una implementación de referencia, vea CommandQueue.Callbacks#onDisplayReady para soporte de la barra de navegación y WallpaperManagerInternal#onDisplayReady para 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, vea 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.

Lanzacohetes

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

Figura 1. Ejemplo de platform/development/samples/MultiDisplay pantallas múltiples para platform/development/samples/MultiDisplay

La mayoría de los lanzadores existentes no admiten múltiples instancias y no están optimizados para pantallas de gran tamaño. Además, a menudo se espera un tipo diferente de experiencia en pantallas secundarias / externas. Para proporcionar una actividad dedicada para pantallas secundarias, Android 10 presenta la categoría SECONDARY_HOME en los filtros de intención. Las instancias de esta actividad se utilizan en todas las pantallas que admiten decoraciones del sistema, una por 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 evite múltiples instancias y se espera que se adapte a diferentes tamaños de pantalla. El modo de inicio no puede ser singleInstance o singleTask .

Implementación

En Android 10, RootActivityContainer#startHomeOnDisplay() selecciona automáticamente el componente deseado y la intención según la pantalla donde se inicia la pantalla de inicio. RootActivityContainer#resolveSecondaryHomeActivity() contiene la lógica para buscar el componente de actividad del RootActivityContainer#resolveSecondaryHomeActivity() seleccionado actualmente y puede usar el valor predeterminado del sistema, si es necesario (consulte 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 aplicación maliciosa cree una pantalla virtual con decoraciones del sistema habilitadas y lea información sensible del usuario desde la superficie, el iniciador solo aparece en pantallas virtuales que son propiedad del sistema. El iniciador no muestra contenido en pantallas virtuales que no sean del sistema.

Fondos de pantalla

En Android 10 (y superior), los fondos de pantalla son compatibles con pantallas secundarias:

Figura 2. Fondo de pantalla en vivo en pantallas internas (arriba) y externas (abajo)

Los desarrolladores pueden declarar la 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 activos utilizando el contexto de visualización en WallpaperService.Engine#getDisplayContext() .

El marco crea una instancia de WallpaperService.Engine por pantalla, por lo que cada motor tiene su propia superficie y contexto de visualización. El desarrollador debe asegurarse de que cada motor pueda dibujar independientemente, a diferentes velocidades de cuadro, respetando VSYNC.

Seleccionar fondos de pantalla para pantallas individuales

Android 10 no proporciona soporte directo de plataforma para seleccionar fondos de pantalla para pantallas individuales. Para lograr esto, se necesita un identificador de pantalla estable para mantener la configuración del fondo de pantalla por pantalla. Display#getDisplayId() es dinámica, por lo que no hay garantía de que una pantalla física tenga la misma 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 implementación completa en el futuro. Desafortunadamente, es demasiado tarde para implementar la lógica para Android 10. La solución sugerida:

  1. Use la API WallpaperManager para configurar los fondos de pantalla.
  2. WallpaperManager se obtiene de un objeto Context , y cada objeto Context tiene información sobre la visualización correspondiente ( Context#getDisplay()/getDisplayId() ). Por lo tanto, puede obtener displayId desde una instancia de WallpaperManager sin agregar nuevos métodos.
  3. En el lado del marco, use displayId obtenido de un objeto Context y displayId un identificador estático (como un puerto de una pantalla física). Use el identificador estático para conservar el fondo de pantalla elegido.

Esta solución utiliza implementaciones existentes para los recolectores de papel tapiz. Si se abrió en una pantalla específica y utiliza el contexto correcto, cuando llama para establecer un fondo de pantalla, el sistema puede identificar automáticamente la pantalla.

Si es necesario establecer un fondo de pantalla para una pantalla que no sea la pantalla actual, cree un nuevo objeto Context para la pantalla de destino ( Context#createDisplayContext ) y obtenga la instancia de WallpaperManager de esa pantalla.

Restricciones de seguridad

El sistema no mostrará fondos de pantalla en pantallas virtuales que no posee. Esto se debe a la preocupación de seguridad de que una aplicación maliciosa podría crear una pantalla virtual con soporte de decoraciones del sistema habilitado y leer una información sensible del usuario desde la superficie (como una foto personal).

Implementación

En Android 10, las IWallpaperConnection#attachEngine() y IWallpaperService#attach() aceptan el parámetro displayId para crear conexiones por pantalla. WallpaperManagerService.DisplayConnector encapsula un motor de papel tapiz por pantalla y una conexión. 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.

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

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

Figura 3. Lógica alternativa de fondo de pantalla para pantallas secundarias