Vous trouverez ci-dessous les modifications apportées à ces zones spécifiques au Réseau Display:
- Décorations du système
- Fenêtres de décoration de l'UI du système
- Lanceur d'applications
- Fonds d'écran
Décorations système
Android 10 prend désormais en charge la configuration affiche certaines décorations système, comme le fond d'écran, la barre de navigation, et lanceur d'applications. Par défaut, l'écran principal affiche toutes les décorations du système et les écrans secondaires affichent ceux qui sont activés en option. Compatibilité avec un éditeur de mode de saisie (IME) peuvent être définis séparément des autres décorations système.
Utiliser DisplayWindowSettings#setShouldShowSystemDecorsLocked()
pour ajouter la prise en charge des décorations
système sur un écran spécifique ou fournir
une valeur par défaut dans /data/system/display_settings.xml
. Par exemple,
consultez la section Paramètres de la fenêtre d'affichage.
Implémentation
DisplayWindowSettings#setShouldShowSystemDecorsLocked()
est également exposé dans
WindowManager#setShouldShowSystemDecors()
à des fins de test. Déclenchement de cette méthode
avec l'intention d'activer les décors système n'ajoute pas de fenêtres de décoration qui étaient
ou les supprimer s'ils étaient présents. Dans la plupart des cas
dans certains cas, la prise en charge des décorations système
ne prend pleinement effet qu'après
de l'appareil.
Vérifie la compatibilité des décorations système dans le code base WindowManager
passent généralement par DisplayContent#supportsSystemDecorations()
alors que
des services externes (tels que l'UI du système, pour vérifier si la barre de navigation
à afficher) utilisez WindowManager#shouldShowSystemDecors()
.
Pour comprendre ce qui est contrôlé par ce paramètre, explorez les points d'appel de
ces méthodes.
Fenêtres de décoration de l'UI du système
Android 10 ajoute la prise en charge des fenêtres de décoration système
de la barre de navigation uniquement, car celle-ci est essentielle
pour naviguer entre les activités et les applications. Par défaut, la barre
de navigation affiche
affordances "retour" et "domicile". Cette valeur n'est incluse que si l'affichage cible est compatible avec
des décorations système (voir DisplayWindowSettings
).
La barre d'état est une fenêtre système plus compliquée, car elle contient également le volet des notifications, les Réglages rapides et l'écran de verrouillage. Sur Android 10, la barre d'état n'est pas compatible avec les écrans secondaires. Par conséquent, les notifications, les paramètres et le verrouillage du clavier ne sont disponibles que sur la l'écran principal.
La fenêtre système Aperçu/Éléments récents n'est pas compatible avec les applications secondaires écrans. Sous Android 10, AOSP n'affiche que les éléments récents l'affichage par défaut et contient les activités de tous les affichages. Lorsqu'elle est lancée depuis "Récentes", une activité qui se trouvait sur un écran secondaire est mise au premier plan sur qui s'affichent par défaut. Cette approche présente certains problèmes connus, se mettent à jour immédiatement lorsque les applications apparaissent sur d'autres écrans.
Implémentation
Pour implémenter des fonctionnalités supplémentaires de l'UI du système, les fabricants d'appareils doivent utiliser un composant unique d'UI du système qui écoute l'ajout/la suppression d'écrans et présente un contenu approprié ;
Un composant d'UI du système compatible avec le mode multi-écran doit gérer les cas suivants:
- Initialisation de plusieurs écrans au démarrage
- Écran ajouté au moment de l'exécution
- Écran supprimé au moment de l'exécution
Lorsque l'UI du système détecte l'ajout d'un écran avant WindowManager, elle crée
une condition de concurrence. Pour éviter cela, implémentez un rappel personnalisé à partir de
WindowManager à l'UI du système lorsqu'un écran est ajouté au lieu de s'abonner à
Événements DisplayManager.DisplayListener
. Pour une implémentation de référence,
Voir CommandQueue.Callbacks#onDisplayReady
pour la prise en charge de la barre de navigation
et WallpaperManagerInternal#onDisplayReady
pour les fonds d'écran.
En outre, Android 10 fournit les mises à jour suivantes:
- La classe
NavigationBarController
contrôle toutes les fonctionnalités spécifiques aux barres de navigation. - Pour afficher une barre de navigation personnalisée, consultez
CarStatusBar
. TYPE_NAVIGATION_BAR
n'est plus restreint à un seul et peuvent être utilisées par écran.IWindowManager#hasNavigationBar()
est mis à jour pour inclure la ParamètredisplayId
pour l'UI du système uniquement.
Lanceur d'applications
Sous Android 10, chaque écran configuré pour prendre en charge
système decorations dispose d'une pile d'accueil dédiée aux activités de lanceur d'applications avec
WindowConfiguration#ACTIVITY_TYPE_HOME
, par défaut. Chaque écran
utilise une instance distincte
de l'activité du lanceur d'applications.
Figure 1 : Exemple de lanceur multi-écran pour
platform/development/samples/MultiDisplay
La plupart des lanceurs existants ne prennent pas en charge plusieurs instances et ne sont pas optimisés
pour les grands écrans. De plus, une expérience différente
est souvent attendue
sur les écrans secondaires ou externes. Pour fournir une activité dédiée aux services
écrans, Android 10 introduit la catégorie SECONDARY_HOME
dans l'intent
des filtres. Les instances de cette activité sont utilisées sur tous les écrans compatibles avec le système
une par écran.
<activity> ... <intent-filter> <category android:name="android.intent.category.SECONDARY_HOME" /> ... </intent-filter> </activity>
L'activité doit avoir un mode de lancement qui n'empêche pas plusieurs
et doit s'adapter à différentes tailles d'écran. Mode de lancement
ne peut pas être singleInstance
ni singleTask
.
Implémentation
Sous Android 10, RootActivityContainer#startHomeOnDisplay()
sélectionne automatiquement le composant et l'intent souhaités en fonction de l'affichage
où l'écran d'accueil est lancé. RootActivityContainer#resolveSecondaryHomeActivity()
contient la logique permettant de rechercher le composant d'activité du lanceur d'applications en fonction
le lanceur d'applications sélectionné et peut utiliser la valeur par défaut du système, si nécessaire (voir
ActivityTaskManagerService#getSecondaryHomeIntent()
).
Restrictions de sécurité
Outre les restrictions qui s'appliquent aux activités sur les écrans secondaires, pour éviter qu'une application malveillante crée un affichage virtuel avec l'option Décorations du système et la lecture d'informations sensibles à partir de la surface, le lanceur d'applications n'apparaît sur des écrans virtuels appartenant au système. Le lanceur d'applications n'affiche aucun contenu sur des écrans virtuels non-système.
Fonds d'écran
Sous Android 10 (ou version ultérieure), les fonds d'écran sont compatibles sur les écrans secondaires:
Figure 2. Fond d'écran animé (interne (ci-dessus) et externe) s'affiche (ci-dessous)
Les développeurs peuvent déclarer la prise en charge de la fonctionnalité de fond d'écran en fournissant
android:supportsMultipleDisplays="true"
dans la
Définition XML WallpaperInfo
. Les développeurs de fonds
d'écran sont également
chargé de charger les éléments à l'aide du contexte d'affichage
WallpaperService.Engine#getDisplayContext()
Le framework crée une instance WallpaperService.Engine
.
par écran, afin que chaque moteur dispose de sa propre surface et de son propre contexte d'affichage. La
le développeur doit s'assurer que chaque moteur peut dessiner de manière indépendante,
différentes fréquences d'images, en respectant VSYNC.
Sélectionner des fonds d'écran pour chaque écran
Android 10 ne prend pas directement en charge la plate-forme pour la sélection des fonds d'écran
pour les écrans individuels. Pour ce faire, un identifiant
d'affichage stable est
nécessaires pour conserver les paramètres
de fond d'écran par écran.
Display#getDisplayId()
est dynamique. Il n'y a donc aucune garantie qu'une
l'écran physique aura le même ID
après le redémarrage.
Cependant, Android 10 a ajouté DisplayInfo.mAddress
,
qui contient des identifiants stables pour les écrans physiques et peut être utilisé
mise en œuvre à l'avenir. Malheureusement, il est trop tard pour implémenter la logique
pour Android 10. Solution suggérée:
- Utilisez l'API
WallpaperManager
pour définir les fonds d'écran. WallpaperManager
est obtenu à partir d'unContext
. et chaque objetContext
contient des informations sur les l'écran (Context#getDisplay()/getDisplayId()
). Par conséquent, vous pouvez obtenirdisplayId
à partir d'une instanceWallpaperManager
sans ajouter de nouvelles méthodes.- Côté framework, utilisez
displayId
, obtenu à partir d'unContext
et le mapper à un identifiant statique (comme un port de un écran physique). Utilisez l'identifiant statique pour conserver le fond d'écran choisi.
Cette solution utilise des implémentations existantes pour les sélecteurs de fond d'écran. Si a été ouvert sur un écran spécifique et utilise le contexte approprié, pour définir un fond d'écran, le système peut identifier automatiquement l'écran.
S'il est nécessaire de définir un fond d'écran pour un autre écran
puis créez un objet Context
pour l'écran cible.
(Context#createDisplayContext
) et d'obtenir la valeur
WallpaperManager
sur cet écran.
Restrictions de sécurité
Le système n'affiche pas sur les écrans virtuels les fonds d'écran dont il n'est pas propriétaire. Cela est dû à un problème de sécurité : une application malveillante pourrait créer un s'affichent avec les décorations système activées et lisent un contenu informations visibles à l'écran (une photo personnelle, par exemple).
Implémentation
Sous Android 10, le IWallpaperConnection#attachEngine()
et IWallpaperService#attach()
acceptent les
displayId
pour créer des connexions par écran.
WallpaperManagerService.DisplayConnector
encapsule un écran par écran.
un moteur de fond d'écran et une connexion. Dans WindowManager, les contrôleurs de fond d'écran
est créée pour chaque objet DisplayContent
lors de sa construction au lieu d'une
une seule WallpaperController
pour tous les écrans.
Certaines implémentations publiques de la méthode WallpaperManager
(comme
WallpaperManager#getDesiredMinimumWidth()
) ont été mises à jour pour calculer
et de fournir des informations
pour les écrans correspondants.
WallpaperInfo#supportsMultipleDisplays()
et une
de ressource ont été ajoutés, afin que les développeurs d'applications puissent signaler les
les fonds d'écran sont prêts
pour plusieurs écrans.
Si le service de fond d'écran affiché sur l'écran par défaut n'est pas compatible sur plusieurs écrans, le système affiche le fond d'écran par défaut s'affiche.
Figure 3. Logique de remplacement de fond d'écran pour les écrans secondaires