Jetpack WindowManager permet aux développeurs d'applications de prendre en charge de nouveaux facteurs de forme d'appareil et les environnements multifenêtres.
Les extensions (extensions) WindowManager sont un module de plate-forme Android à activer.
active diverses fonctionnalités de Jetpack WindowManager. Le module est implémenté
dans AOSP dans frameworks/base/libs/WindowManager/Jetpack
et livrés sur des appareils
compatibles avec les fonctionnalités de WindowManager.
Distribution du module d'extensions
Les extensions sont compilées dans une bibliothèque .jar
et placées dans system_ext
.
sur un appareil si les extensions sont activées dans le fichier makefile de l'appareil.
Pour activer les extensions sur un appareil, ajoutez les éléments suivants à celui-ci makefile:
$(call inherit-product, $(SRC_TARGET_DIR)/product/window_extensions.mk)
Cela permet d'activer androidx.window.extensions
et androidx.window.sidecar
.
packages sur l'appareil et définit la propriété persist.wm.extensions.enabled
.
L'inclusion de ces packages dans le
fichier makefile place également les déclarations dans
etc/permissions/
, ce qui les met à la disposition des processus d'application. Normalement,
modules sont chargés et exécutés dans le cadre du processus d'application
lorsqu'il est utilisé par la bibliothèque Jetpack WindowManager.
semblable au code du framework côté client, comme illustré dans
figure:
![](https://source.android.google.cn/static/docs/core/display/images/wm_extensions_in_app_process.png?authuser=8&hl=fr)
Le module androidx.window.extensions
est le module d'extensions actuel sous
un développement actif. Le module androidx.window.sidecar
est un ancien module
pour assurer la compatibilité avec les premières versions de Jetpack WindowManager.
mais le side-car n'est plus activement maintenu.
La figure suivante illustre la logique permettant de déterminer l'utilisation
androidx.window.extensions
ou androidx.window.sidecar
.
![](https://source.android.google.cn/static/docs/core/display/images/wm_extensions_decision_tree.png?authuser=8&hl=fr)
androidx.window.extensions
ou androidx.window.sidecar
.
Modules d'extensions
Les extensions fournissent des fonctionnalités de fenêtrage pour les appareils pliables à grand écran et les appareils qui prennent en charge le fenêtrage sur des écrans externes. Les fonctionnalités concernées sont les suivantes:
Les implémentations d'extensions OEM peuvent fournir des composants ou des composants nuls
les implémentations par défaut ou bouchons des méthodes dans
WindowExtensions
interface si le matériel de l’appareil
n’est pas compatible avec les fonctionnalités correspondantes,
à moins que la fonctionnalité ne soit spécifiquement demandée
Document de définition de compatibilité (CDD) 7.1.1.1.
Extensions et API Jetpack
Le module d'extensions WindowManager fournit sa propre surface d'API,
les API de la plate-forme publique. Le module Extensions est développé publiquement
non destiné aux développeurs androidx.window.extensions
la bibliothèque Jetpack, afin que Jetpack WindowManager
(androidx.window
)
vous pouvez créer un lien vers celui-ci
au moment de la compilation. La surface de l'API Extensions est généralement
fournit des API de niveau inférieur.
Les API fournies par les extensions sont destinées à être utilisées par le Jetpack Bibliothèque WindowManager uniquement. Les API Extensions ne sont pas destinées à être appelées par aux développeurs d'applications. La bibliothèque d'extensions ne doit pas être ajoutée d'une application dans le fichier de compilation Gradle pour garantir de Google Cloud. Éviter de précompiler la bibliothèque d'extensions dans une application directement ; Utilisez plutôt le chargement de l'environnement d'exécution pour éviter qu'un mélange de classes d'extensions précompilées et fournies par l'environnement d'exécution.
Jetpack WindowManager (androidx.window
) est destiné à être ajouté en tant qu'application
et fournit les API publiques destinées aux développeurs, y compris celles
pour les fonctionnalités des extensions WindowManager. La bibliothèque WindowManager
charge les extensions dans le processus de l'application et encapsule le niveau inférieur
les API d'extensions en abstractions de niveau supérieur et plus ciblées
de commande. Les API Jetpack WindowManager respectent les normes des technologies modernes
de développement d'applications Android et sont conçus pour fournir
l'interopérabilité grâce à une intégration parfaite avec les codebases qui utilisent d'autres
bibliothèques.
Versions et mises à jour des extensions
Le module Extensions peut être mis à jour avec la plate-forme Android une fois par an ou des mises à jour trimestrielles. Les mises à jour trimestrielles permettent au niveau d'API Extensions d'être entre les mises à jour de l'API de la plate-forme Android, ce qui permet d'accélérer l'itération et Offrir aux OEM la possibilité d'ajouter un accès API officiel à de nouvelles fonctionnalités peu de temps avant les lancements de matériel.
Le tableau suivant répertorie les versions de l'API androidx.window.extensions
pour
différentes versions d'Android.
Version de la plate-forme Android | Niveau d'API des extensions WindowManager | Version de l'API androidx.window.extensions |
---|---|---|
Android 15 | 6 | 1.5.0 (bientôt disponible) |
Android 14 QPR3 | 5 | 1.4.0 (bientôt disponible) |
Android 14 QPR1 | 4 | 1.3.0 |
Android 14 | 3 | 1.2.0 |
Android 13 QPR3 | 2 | 1.1.0 |
Android 13 | 1 | 1.0.0 |
Android 12L | 1 | 1.0.0 |
Le niveau de l'API Extensions (colonne centrale) augmente chaque fois qu'une de la surface d'API stable existante (colonne de droite).
<ph type="x-smartling-placeholder">Rétrocompatibilité.
Jetpack WindowManager gère la complexité liée au traitement des niveaux d'API fréquents les mises à jour, l'évolution rapide des API et la rétrocompatibilité. Lorsque le code de la bibliothèque est exécutée dans le processus d'application, la bibliothèque vérifie les l'API Extensions et permet d'accéder aux fonctionnalités selon d'application.
Pour protéger une application contre les plantages au moment de l'exécution, WindowManager une vérification de la réflexion Java de l'environnement d'exécution des API Extensions disponibles selon niveau d'API Extensions déclaré. En cas de non-concordance, WindowManager peut désactiver l'utilisation des extensions (en partie ou en totalité) et signaler les fonctionnalités non disponibles pour l'application.
Les extensions WindowManager sont implémentées en tant que module system_ext
qui utilise
des API de plate-forme privée
pour appeler le noyau de WindowManager,
DeviceStateManager
,
et d'autres services système dans l'implémentation
des fonctionnalités des extensions.
Il est possible que la compatibilité ne puisse pas être maintenue avec les versions préliminaires des extensions.
avant la version trimestrielle ou annuelle correspondante de la plate-forme Android,
pour lesquelles les versions sont finalisées. Vous pouvez consulter l'historique complet des API Extensions
trouvé dans la branche de version
Fichiers texte de l'API window:extensions:extensions
.
Les versions plus récentes des extensions doivent continuer à fonctionner avec les anciennes versions de WindowManager compilé dans des applications pour maintenir la compatibilité ascendante À s'assure que c'est le cas, toute nouvelle version de l'API Extensions n'ajoute que de nouvelles API et ne supprime pas les plus anciens. Par conséquent, les applications avec d'anciennes versions de WindowManager peuvent continuer à utiliser les anciennes API Extensions depuis lesquelles les applications ont été compilées. par rapport à.
La vérification CTS garantit que, pour toute version déclarée des API Extensions sur le toutes les API pour cette version et les versions antérieures sont présentes et fonctionnelles.
Performances
À partir d'Android 14 (niveau d'API 34), le module Extensions est mis en cache par défaut dans les chargeurs de classe système non bootclasspath. Le chargement du module en mémoire au démarrage de l'application n'a donc aucun impact sur les performances. L'utilisation de fonctionnalités de module individuelles peut avoir une légère influence sur les caractéristiques de performances des applications lorsque des appels IPC supplémentaires sont effectués entre le client et le serveur.
Modules
Intégration d'activités
L'intégration d'activités fournit un ensemble de fonctionnalités permettant aux applications d'organiser de la fenêtre d'activité dans les limites de l'application parente. Ce inclut l'affichage simultané de deux activités côte à côte dans une une mise en page à plusieurs volets facilitant l'optimisation pour les anciens écrans sur grand écran ; applications.
Le composant d'intégration d'activités doit être disponible sur tous les appareils dotés d'un
écran intégré dont la taille est supérieure ou égale à sw600 dp
.
L'intégration d'activités doit également être activée sur les appareils compatibles avec l'affichage externe
car l'application peut s'afficher en plus grand format
les écrans sont connectés au moment de l'exécution.
Configuration de l'appareil
Aucune configuration spécifique de l'appareil n'est nécessaire, sauf pour activer les extensions comme décrit dans la section Distribution des modules d'extensions . Il est judicieux d'activer les extensions sur tous les appareils compatibles mode multifenêtre. Les extensions seront probablement disponibles dans les prochaines versions d'Android requise sur les configurations courantes des appareils portables et des appareils à grand écran.
Informations sur la mise en page des fenêtres
Le composant d'informations sur la mise en page des fenêtres identifie la position et l'état sur un appareil pliable lorsque la charnière traverse une fenêtre d'application. Les informations de mise en page des fenêtres permettent aux applications de répondre et d'afficher mises en page en mode sur table sur les appareils pliables. Voir Rendre votre application pliable pour en savoir plus sur son utilisation.
Appareils Android pliables dotés d'une charnière qui permet de connecter des appareils
les zones d'affichage continu doivent indiquer des informations sur la charnière
disponibles pour les applications via WindowLayoutComponent
.
La position et les limites de la charnière doivent être indiquées par rapport à l'application.
identifiée par un Context
transmis à l'API. Si la fenêtre de l'application
les limites de la charnière n'entrent pas
DisplayFeature
ne doivent pas être signalées. Il est également acceptable de ne pas signaler les fonctionnalités d'affichage
lorsque leur position risque de ne pas être rapportée de manière fiable, par exemple lorsqu'une application
la fenêtre peut être déplacée librement par l'utilisateur en mode multifenêtre ou
de compatibilité avec le format letterbox.
Concernant les fonctionnalités de pliage,
les mises à jour de l'état doivent être signalées lorsque la position de la charnière change entre les
des états stables. Par défaut, dans un état d'affichage plat, l'API doit indiquer
FoldingFeature.State.FLAT
Si le matériel de l'appareil peut rester stable à moitié plié,
L'API doit signaler FoldingFeature.State.HALF_OPENED
.
Il n'y a pas d'état fermé dans l'API, car dans ce cas, la fenêtre de l'application
ne seraient pas visibles
ou ne traverseraient pas les limites de la charnière.
Configuration de l'appareil
Pour permettre l'implémentation de la fonctionnalité de pliage, les OEM doivent procéder comme suit:
Configurez les états des appareils dans
device_state_configuration.xml
qui seront utilisés parDeviceStateManagerService
VoirDeviceStateProviderImpl.java
pour référence.Si les implémentations par défaut de
DeviceStateProvider
ouDeviceStatePolicy
ne conviennent pas à l'appareil, vous pouvez utiliser une implémentation personnalisée.Activez le module Extensions comme décrit dans les Distribution des modules d'extensions.
Spécifiez l'emplacement des éléments géographiques d'affichage dans
com.android.internal.R.string.config_display_features
ressource de chaîne (généralement dansframeworks/base/core/res/res/values/config.xml
) en superposition sur l'appareil).Le format attendu pour la chaîne est le suivant:
<type>-[<left>,<top>,<right>,<bottom>]
Le
type
peut êtrefold
ouhinge
. Valeurs pourleft
,top
etright
etbottom
sont des coordonnées entières en pixels dans l'espace de coordonnées de l'écran l'orientation naturelle de l'écran. La chaîne de configuration peut contenir plusieurs séparez les caractéristiques par un point-virgule.Exemple :
<!-- Jetpack WindowManager display features --> <string name="config_display_features" translatable="false">fold-[1000,0,1000,2000]</string>
Définissez le mappage entre les identifiants d'état internes de l'appareil utilisés dans
DeviceStateManager
et les constantes d'état public envoyées aux développeurs danscom.android.internal.R.array.config_device_state_postures
Le format attendu pour chaque entrée est le suivant:
<device_specific_state_identifier>:<Jetpack WindowManager state identifier>
Les identifiants d'état acceptés sont les suivants:
COMMON_STATE_NO_FOLDING_FEATURES = 1
: l'état n'a pas de caractéristiques de pliage à . Par exemple, il peut s'agir de l'état fermé d'un modèle classique appareil avec l’écran principal à l’intérieur.COMMON_STATE_HALF_OPENED = 2
: la fonctionnalité de pliage est à moitié ouverte.COMMON_STATE_FLAT = 3
: le pliage est plat. Par exemple, il peut s'agir de l'état ouvert d'un appareil pliable classique avec l'écran principal du côté intérieur.COMMON_STATE_USE_BASE_STATE = 1000
: dans Android 14, une valeur pouvant être utilisée pour l'émulation où l'état de la charnière est dérivé de l'état de base, tel que défini dansCommonFoldingFeature.java
Pour en savoir plus, consultez
DeviceStateManager.DeviceStateCallback#onBaseStateChanged(int)
.Exemple :
<!-- Map of System DeviceState supplied by DeviceStateManager to WindowManager posture.--> <string-array name="config_device_state_postures" translatable="false"> <item>0:1</item> <!-- CLOSED : COMMON_STATE_NO_FOLDING_FEATURES --> <item>1:2</item> <!-- HALF_OPENED : COMMON_STATE_HALF_OPENED --> <item>2:3</item> <!-- OPENED : COMMON_STATE_FLAT --> <item>3:1</item> <!-- REAR_DISPLAY : COMMON_STATE_NO_FOLDING_FEATURES --> <item>4:1000</item> <!-- CONCURRENT : COMMON_STATE_USE_BASE_STATE --> </string-array>
Zone de la fenêtre
Le composant "Zone de fenêtre" fournit un ensemble de fonctionnalités qui permettent aux applications l'accès à des écrans et zones d'affichage supplémentaires sur certains appareils pliables et appareils multi-écrans.
Le mode d'affichage arrière permet à une application d'afficher l'interface utilisateur d'aperçu de l'appareil photo sur le affichage couvert d'un appareil pliable pour permettre l'utilisation de l'appareil photo principal de l'appareil des selfies et des vidéos. Appareils dotés d'un système d'exploitation Android (telles que définies par le CDD Android en termes d'attributs tels que la taille, la densité les affordances de navigation disponibles) recouvrent un écran aligné avec l'appareil arrière ; les caméras doivent permettre l'accès au mode d'affichage arrière.
Sous Android 14, le mode double affichage permet aux applications exécutées sur l'écran intérieur d'un appareil pliable d'afficher du contenu supplémentaire sur l'écran de couverture, face aux autres utilisateurs. Par exemple, l'écran de couverture peut montrer l'aperçu de l'appareil photo à la personne photographiée ou enregistrée.
Configuration de l'appareil
Pour permettre l'implémentation de la fonctionnalité de pliage, les OEM doivent procéder comme suit:
Configurez les états des appareils dans
device_state_configuration.xml
qui seront utilisés parDeviceStateManagerService
VoirDeviceStateProviderImpl.java
pour en savoir plus.Si l'implémentation par défaut de
DeviceStateProvider
ouDeviceStatePolicy
n'est pas adaptée à l'appareil, vous pouvez utiliser une implémentation personnalisée.Pour les appareils pliables compatibles avec le mode ouvert ou plat, indiquez identifiants d'état dans
com.android.internal.R.array.config_openDeviceStates
.Pour les appareils pliables compatibles avec l'état plié, listez les identifiants d'état dans
com.android.internal.R.array.config_foldedDeviceStates
.Pour les appareils pliables qui prennent en charge un mode à moitié plié (charnière à moitié ouverte) comme un ordinateur portable), répertoriez les états correspondants dans
com.android.internal.R.array.config_halfFoldedDeviceStates
Pour les appareils compatibles avec le mode d'affichage arrière:
- Répertoriez les états correspondants dans
com.android.internal.R.array.config_rearDisplayDeviceStates
pourDeviceStateManager
. - Indiquez l'adresse physique d'affichage de l'écran arrière dans le champ
com.android.internal.R.string.config_rearDisplayPhysicalAddress
. - Spécifiez l'identifiant d'état dans
com.android.internal.R.integer.config_deviceStateRearDisplay
qui sera utilisé par les extensions. - Ajoutez l'identifiant d'état dans
com.android.internal.R.array.config_deviceStatesAvailableForAppRequests
pour le rendre disponible pour les applications.
- Répertoriez les états correspondants dans
Sous Android 14, pour les appareils compatibles avec le mode d'affichage double (simultané) :
- Définissez
com.android.internal.R.bool.config_supportsConcurrentInternalDisplays
surtrue
. - Indiquez l'adresse physique d'affichage de l'écran arrière dans le champ
com.android.internal.R.config_deviceStateConcurrentRearDisplay
. - Spécifiez l'identifiant d'état dans
com.android.internal.R.integer.config_deviceStateConcurrentRearDisplay
qui sera utilisé par les extensions si l'identifiant est destiné aux applications. - Ajoutez l'identifiant d'état dans
com.android.internal.R.array.config_deviceStatesAvailableForAppRequests
pour le rendre disponible pour les applications.
- Définissez
Validation
Les OEM doivent vérifier leurs implémentations pour s'assurer que le comportement attendu est commun. différents scénarios. Les OEM ont accès aux tests CTS et aux tests utilisant Jetpack WindowManager. pour tester les implémentations.
Tests CTS
Pour exécuter les tests CTS, consultez Exécuter des tests CTS. La CTS
les tests liés à Jetpack WindowManager se trouvent sous cts/tests/framework/base/windowmanager/jetpack/
.
Le nom du module de test est CtsWindowManagerJetpackTestCases
.
Tests WindowManager
Pour télécharger les tests Jetpack WindowManager, suivez le
Instructions pour Android Jetpack
Les tests se trouvent dans la bibliothèque de fenêtres sous le module window:window
: window/window/src/androidTest/
.
Pour exécuter les tests d'appareil pour le module window:window
à partir de la ligne de commande, procédez comme suit :
les éléments suivants:
- Branchez un appareil sur lequel les options pour les développeurs et le débogage USB sont activés.
- Autorisez l'ordinateur à déboguer l'appareil.
- Ouvrez un shell dans le répertoire racine du dépôt androidx.
- Remplacez le répertoire par
framework/support
. - Exécutez la commande suivante:
./gradlew window:window:connectedAndroidTest
. - Analysez les résultats.
Pour exécuter les tests à partir d'Android Studio, procédez comme suit:
- Ouvrez Android Studio.
- Branchez un appareil sur lequel les options pour les développeurs et le débogage USB sont activés.
- Autorisez l'ordinateur à déboguer l'appareil.
- Accédez à un test dans la bibliothèque de fenêtres du module de fenêtre.
- Ouvrez une classe de test et exécutez-la à l'aide des flèches vertes situées à droite éditeur.
Vous pouvez également créer une configuration dans Android Studio pour exécuter un test une classe de test, ou tous les tests d'un module.
Les résultats peuvent être analysés manuellement en consultant la sortie du shell. Un peu les tests sont ignorés si l'appareil ne répond pas à certaines hypothèses. Les résultats sont enregistré dans un emplacement standard, et les analystes peuvent écrire un script pour automatiser une analyse des résultats.