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ámetrodisplayId
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:
- Usa la API de
WallpaperManager
para establecer los fondos de pantalla. WallpaperManager
se obtiene de unContext
objeto, y cada objetoContext
tiene información sobre los datos pantalla (Context#getDisplay()/getDisplayId()
). Por lo tanto, puedes obtenerdisplayId
de una instancia deWallpaperManager
sin agregar nuevos métodos.- En el lado del framework, usa
displayId
obtenido de unContext
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