Notes de version d'Android 9

Cette page récapitule les principales fonctionnalités de la version 9 d'Android et fournit des liens vers des informations supplémentaires. Ces résumés de fonctionnalités sont organisés en fonction de l'emplacement de la documentation de la fonctionnalité sur ce site. Pour obtenir un guide sur le déplacement et le renommage des sections, consultez les mises à jour du site d'août 2018.

Créer

Image système générique (GSI)

Une image système générique (GSI) est une image système dont les configurations ont été ajustées pour les appareils Android. L'image système générique (GSI) inclut des informations sur les différences entre les GSI pour les appareils lancés avec Android 9 et ceux mis à niveau vers Android 9.

Architecture

Couche d'abstraction matérielle (HAL)

Rétrocompatibilité du framework HIDL

La vérification de la rétrocompatibilité du framework HIDL est une méthode permettant de vérifier la rétrocompatibilité du framework.

HAL disponibles de manière dynamique

Les HAL disponibles de manière dynamique permettent l'arrêt dynamique des sous-systèmes matériels Android lorsqu'ils ne sont pas utilisés ou ne sont pas nécessaires.

HIDL

HIDL MemoryBlock

HIDL MemoryBlock est une couche abstraite basée sur hidl_memory, HIDL @1.0::IAllocator et HIDL @1.0::IMapper. Il est conçu pour les services HIDL qui comportent plusieurs blocs de mémoire partageant un même tas de mémoire.

Superpositions d'arborescence de périphériques

Superpositions compressées

Android 9 et versions ultérieures sont compatibles avec les calques compressés dans l'image de calque DTBO (Device Tree Blob Overlay) lorsque vous utilisez la version 1 de l'en-tête de table du Device Tree.

Mises à jour des DTO

Android 9 et versions ultérieures exigent que le bootloader transmette le blob d'arborescence unifiée de l'appareil au noyau avant de modifier les propriétés définies dans les overlays d'arborescence de l'appareil (DTO).

Gestion des versions de l'en-tête de l'image DTBO

Android 9 et versions ultérieures incluent un champ de version dans l'en-tête de l'image DTBO.

Validation du DTBO

Android 9 et versions ultérieures nécessitent une partition DTBO. Pour ajouter des nœuds ou modifier les propriétés du DT du SoC, le bootloader doit superposer dynamiquement un DT spécifique à l'appareil sur le DT du SoC. Pour en savoir plus, consultez Compilation et vérification.

Conformité du noyau

Android 9 et versions ultérieures incluent des exigences qui affectent le noyau, ses interfaces et l'utilisation des DTBO. Pour en savoir plus, consultez les pages suivantes :

NDK du fournisseur

Modifications de la conception

Pour en savoir plus sur les modifications apportées à la conception du VNDK dans Android 9 et versions ultérieures, consultez les pages suivantes :

Vérificateur d'ABI

La page Stabilité de l'ABI décrit le vérificateur d'interface binaire d'application (ABI), qui garantit que les modifications apportées aux bibliothèques VNDK restent conformes à l'ABI.

Instantanés VNDK

Une image système peut utiliser des instantanés VNDK pour fournir les bibliothèques VNDK appropriées aux images du fournisseur, même lorsque les images système et du fournisseur sont créées à partir de différentes versions d'Android.

Objet d'interface du fournisseur (objet VINTF)

Les pages suivantes de la section Objet d'interface du fournisseur décrivent les mises à jour dans Android 9 et versions ultérieures :

Calendrier d'abandon de HIDL

Les pages suivantes décrivent comment Android déprécie et supprime les HAL HIDL :

Bootloader (chargeur d'amorçage)

Partitions de produits

Android 9 et versions ultérieures permettent de créer des partitions /product à l'aide du système de compilation Android. Auparavant, Android 8.x imposait la séparation des composants spécifiques au système sur puce (SoC) de la partition /system vers la partition /vendor sans consacrer d'espace aux composants spécifiques à l'OEM créés à partir du système de compilation Android.

Conformité avec le motif de démarrage canonique

La page Motif de démarrage canonique décrit les modifications apportées à la spécification du motif de démarrage du bootloader dans Android 9 et versions ultérieures.

Système en tant que racine

Tous les appareils lancés avec Android 9 ou version ultérieure doivent utiliser system-as-root, qui fusionne ramdisk.img dans system.img (également appelé no-ramdisk), qui est ensuite monté en tant que rootfs.

Gestion des versions de l'en-tête de l'image de démarrage

Dans Android 9 et versions ultérieures, l'en-tête de l'image de démarrage contient un champ indiquant la version de l'en-tête. Le bootloader doit vérifier ce champ de version et analyser l'en-tête en conséquence.

DTBO en mode récupération

Pour éviter les échecs de mise à jour OTA dus à des incohérences entre l'image de récupération et la partition DTBO sur les appareils non A/B, l'image de récupération doit contenir des informations provenant de l'image DTBO.

Écran

Encoches

Les encoches permettent aux développeurs d'applications de créer des expériences immersives de bord à bord tout en laissant de l'espace pour les capteurs importants à l'avant des appareils.

Faire pivoter les suggestions

Mises à jour du comportement de la rotation de l'écran Android 9 et versions ultérieures incluent une commande visible par l'utilisateur pour épingler la rotation de l'écran en mode Paysage ou Portrait, même si la position de l'appareil change.

Transitions d'applications synchronisées

Les transitions d'applications synchronisées permettent de nouvelles animations de transition d'applications.

Classification de texte (anciennement TEXTCLASSIFIER)

Android 9 et versions ultérieures incluent un service de classification de texte, qui est la méthode recommandée pour implémenter la classification de texte, ainsi qu'une implémentation de service par défaut.

Couleurs à large gamme

Android 9 et versions ultérieures sont compatibles avec les couleurs à large gamme, y compris :

  • HDR (High Dynamic Range)
  • Traitement du contenu dans l'espace colorimétrique BT2020, mais pas en tant qu'espace de données cible final

Pour utiliser une large gamme de couleurs, la pile d'affichage complète d'un appareil (écran, compositeur matériel, GPU, etc.) doit prendre en charge les formats de mémoire tampon ou les couleurs à large gamme. Les appareils ne sont pas tenus de déclarer la prise en charge du contenu à large gamme de couleurs, même si le matériel le permet. Toutefois, la large gamme de couleurs doit être activée pour profiter pleinement du matériel. Pour éviter une expérience visuelle incohérente, la gamme de couleurs étendue ne doit pas être désactivée lors de l'exécution.

Compatibilité

Document de définition de la compatibilité Android

Le document de définition de compatibilité (CDD) Android 9 s'appuie sur les versions précédentes en apportant des modifications aux exigences pour les fonctionnalités déjà publiées et en ajoutant de nouvelles fonctionnalités.

Paramètres

Des widgets d'application améliorés

Le framework de widget d'application Android offre une visibilité accrue sur les interactions des utilisateurs, en particulier lorsqu'ils suppriment ou ajoutent manuellement des widgets. Cette fonctionnalité est disponible par défaut avec Launcher3.

Les fabricants doivent mettre à jour leurs applications de lanceur d'applications (fournies avec les appareils) pour qu'elles soient compatibles avec cette fonctionnalité si elles ne sont pas basées sur Launcher3. Les OEM doivent prendre en charge le nouveau champ widgetFeatures dans leur lanceur d'applications par défaut.

Notez que la fonctionnalité ne fonctionne de bout en bout que lorsque les lanceurs l'implémentent comme prévu. AOSP inclut un exemple d'implémentation. Consultez l'AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca pour obtenir l'exemple de code fourni.

Notifications de changement d'état de l'appareil envoyées aux installateurs de packages

Une diffusion système protégée peut être envoyée aux applications qui détiennent l'autorisation INSTALL_PACKAGES chaque fois que des propriétés telles que les paramètres régionaux ou la densité d'affichage sont modifiées. Les récepteurs peuvent être enregistrés dans le fichier manifeste, et un processus se déclenche pour recevoir la diffusion. Cela est utile pour les programmes d'installation de packages qui souhaitent installer des composants supplémentaires d'applications lors de tels changements, ce qui est rare, car les changements de configuration éligibles pour déclencher cette diffusion sont rares.

Le code source de la notification de changement d'état de l'appareil se trouve aux emplacements suivants sous platform/frameworks/base :

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

Architecture de l'information

Les modifications apportées à l'architecture de l'information de l'application Paramètres offrent plus de fonctionnalités et une implémentation plus facile.

Tests

Atest

L'outil de ligne de commande Atest vous permet de créer, d'installer et d'exécuter des tests Android en local, ce qui accélère considérablement les réexécutions de tests sans nécessiter de connaître les options de ligne de commande du harnais de test Trade Federation.

Compatibility Test Suite

Téléchargements CTS

Les packages de la suite de tests de compatibilité (CTS) compatibles avec Android 9 sont disponibles sur la page Téléchargements CTS. Le code source des tests inclus peut être synchronisé avec le tag android-cts-9.0_r1 dans l'arborescence Open Source.

Options CTS

Pour Android 9, CTS v2 gagne la commande et l'argument suivants :

  • run retry réexécute tous les tests qui ont échoué ou qui n'ont pas été exécutés lors des sessions précédentes.
  • ‘--shard-count segmente une exécution CTS en un nombre donné de blocs indépendants, à exécuter en parallèle sur plusieurs appareils.

De plus, la commande --retry-type, qui n'était pas documentée auparavant, a été ajoutée à la même référence de commande de console CTS v2.

Service de composant sécurisé

Le service Secure Element recherche les éléments sécurisés compatibles avec la plate-forme mondiale en identifiant si les appareils disposent d'une implémentation SE HAL et, le cas échéant, combien. Il sert de base pour tester l'API et l'implémentation de l'élément sécurisé sous-jacent.

Boîtier de fusion des capteurs

Le boîtier de fusion de capteurs est utilisé dans le test de fusion de capteurs et le test de synchronisation multicaméra de la suite de tests d'image de caméra (Camera ITS). Il fournit un environnement de test cohérent pour mesurer la précision de l'horodatage de la caméra et d'autres capteurs pour les téléphones Android. Pour en savoir plus, consultez les pages suivantes :

ITS-in-a-box avec champ de vision grand-angle

Le système ITS-in-a-box à grand angle de vue est un système automatisé conçu pour tester les systèmes de caméras à grand angle de vue (WFoV) et à angle de vue normal (RFoV) dans Camera ITS.

Suite de tests du fournisseur

Architecture du contrôleur hôte

L'architecture du contrôleur hôte VTS (Vendor Test Suite) est l'architecture du framework de test VTS intégrée à son service de diffusion de tests basé sur le cloud.

Tests HAL qui tiennent compte des noms de service

Les tests HAL compatibles avec les noms de service VTS permettent d'obtenir le nom de service d'une instance HAL donnée en fonction de l'appareil sur lequel les tests VTS sont exécutés.

Vérification de la testabilité HAL

La vérification de la testabilité VTS HAL inclut une méthode d'exécution permettant d'utiliser la configuration de l'appareil pour identifier les tests VTS à ignorer pour cette cible d'appareil.

Infrastructure de tests automatisés

L'infrastructure de test automatisé est une infrastructure VTS permettant de tester automatiquement VTS, CTS ou d'autres tests sur des appareils partenaires exécutant l'image système générique (GSI) AOSP.

Débogage

Télémétrie avancée

Dans Android, la télémétrie est le processus de collecte automatique d'informations sur l'utilisation et le diagnostic de l'appareil, du système Android et des applications. Dans les versions précédentes d'Android, la pile de télémétrie était limitée et ne capturait pas les informations nécessaires pour identifier et résoudre les problèmes de fiabilité du système, ainsi que les problèmes liés aux appareils ou aux applications. Il était donc difficile, voire impossible, d'identifier les causes profondes des problèmes.

Android 9 inclut la fonctionnalité de télémétrie statsd, qui résout ce problème en collectant de meilleures données plus rapidement. statsd collecte l'utilisation des applications, les statistiques sur la batterie et les processus, ainsi que les plantages. Les données sont analysées et utilisées pour améliorer les produits, le matériel et les services.

Pour en savoir plus, consultez frameworks/base/cmds/statsd/.

Fonctionnalités de sécurité

Signature d'application

Le schéma de signature des fichiers APK v3 est compatible avec la rotation des clés APK.

Compatibilité avec l'authentification biométrique

Android 9 inclut la classe publique BiometricPrompt, que les applications peuvent utiliser pour intégrer la prise en charge de l'authentification biométrique de manière indépendante de l'appareil et de la modalité. Pour en savoir plus sur l'intégration de votre pile biométrique afin d'inclure BiometricPrompt, consultez Biométrie.

Analyse dynamique

Android 9 est compatible avec davantage d'outils d'analyse et d'atténuation des failles d'exploitation.

Intégrité du flux de contrôle (CFI)

L'intégrité du flux de contrôle (CFI) est un mécanisme de sécurité qui interdit toute modification du graphique de flux de contrôle d'origine d'un binaire compilé, ce qui rend les attaques de ce type beaucoup plus difficiles à réaliser.

Kernel CFI

En plus de la CFI système, qui est activée par défaut, Android 9 et versions ultérieures sont compatibles avec l'intégrité du flux de contrôle (CFI) du noyau.

Chiffrement

Chiffrement basé sur les fichiers

Le chiffrement basé sur les fichiers (FBE, File-Based Encryption) est mis à jour pour fonctionner avec le stockage adaptable. Les nouveaux appareils doivent utiliser le chiffrement basé sur les fichiers au lieu du chiffrement complet du disque.

Chiffrement des métadonnées

Android 9 et versions ultérieures sont compatibles avec le chiffrement des métadonnées lorsque le matériel le permet. Avec le chiffrement des métadonnées, une seule clé présente au moment du démarrage utilise le chiffrement basé sur les fichiers pour chiffrer tout contenu non chiffré.

Keystore

Android 9 et versions ultérieures incluent Keymaster 4, qui propose ces fonctionnalités.

StrongBox

Android 9 et versions ultérieures sont compatibles avec les clés Android Keystore stockées et utilisées dans un processeur physiquement distinct conçu pour les applications à haute sécurité, comme un élément sécurisé (SE) intégré. StrongBox Keymaster est une implémentation du HAL Keymaster dans un matériel sécurisé discret. Un StrongBox comporte :

  • Processeur discret
  • Stockage sécurisé intégré
  • Générateur de nombres aléatoires de haute qualité
  • Emballage inviolable
  • Résistance aux canaux auxiliaires

Importation sécurisée de clés

Pour importer une clé de manière sécurisée dans Keymaster 4, une clé créée hors de l'appareil est chiffrée avec une spécification des autorisations qui définissent la façon dont la clé peut être utilisée.

Compatibilité avec 3DES

Keymaster 4 inclut 3DES pour la compatibilité avec les anciens systèmes qui utilisent 3DES.

Liaison de version

Pour prendre en charge la structure modulaire de Treble et rompre la liaison de system.img à boot.img, Keymaster 4 a modifié le modèle de liaison de la version de la clé pour qu'il comporte des niveaux de correctifs distincts pour chaque partition. Cela permet de mettre à jour chaque partition indépendamment tout en offrant une protection contre le rollback.

API Android Protected Confirmation

Les appareils compatibles lancés avec Android 9 installé permettent aux développeurs d'utiliser l'API Android Protected Confirmation. Avec cette API, les applications peuvent utiliser une instance de ConfirmationPrompt pour afficher une invite demandant à l'utilisateur d'approuver une courte déclaration. Cette déclaration permet à une application de réaffirmer que l'utilisateur souhaite effectuer une transaction sensible, comme un paiement.

SELinux

Bac à sable SELinux par application

Le bac à sable d'application dispose de nouvelles protections et de nouveaux cas de test pour s'assurer que toutes les applications non privilégiées ciblant Android 9 et versions ultérieures exécutent des bacs à sable SELinux individuels.

Modifications de SELinux pour Treble

Les mises à jour de Treble SELinux dans Android 9 et versions ultérieures sont documentées sur plusieurs pages de la section SELinux.

Initialisation du fournisseur

Vendor init comble le trou dans la séparation système/fournisseur de Treble en utilisant un domaine SELinux distinct pour exécuter les commandes /vendor avec des autorisations spécifiques au fournisseur.

Propriétés système

Android 9 limite le partage inutile des propriétés système entre les partitions system et vendor, et fournit une méthode pour assurer la cohérence entre les propriétés système partagées.

Tests d'attributs SELinux

Android 9 inclut de nouveaux tests au moment de la compilation qui garantissent que tous les fichiers situés à des emplacements spécifiques possèdent les attributs appropriés. Par exemple, tous les fichiers de sysfs possèdent l'attribut sysfs_type requis.

Audio

Effets audio haute résolution

Les mises à jour des effets audio haute résolution incluent la conversion du traitement des effets du format int16 au format float, ainsi que l'augmentation du nombre de pistes de sortie client simultanées, de la mémoire client/serveur maximale et du nombre total de pistes mixées.

Appareil photo

Caméras USB externes

Android 9 et versions ultérieures permettent d'utiliser des caméras USB plug-and-play (c'est-à-dire des webcams) à l'aide de l'API Android Camera2 standard et de l'interface HIDL de l'appareil photo.

Suivi des mouvements

Les caméras peuvent annoncer leur capacité de suivi des mouvements.

Compatibilité avec plusieurs caméras

La compatibilité avec plusieurs caméras inclut la compatibilité de l'API avec les appareils multi-caméras via un nouvel appareil photo logique composé de deux appareils photo physiques ou plus pointant dans la même direction.

Paramètres de session

L'implémentation des paramètres de session peut réduire les délais en permettant aux clients de caméras de configurer activement un sous-ensemble de paramètres de requête coûteux lors de la phase d'initialisation de la session de capture.

Tampon avec un seul producteur et plusieurs consommateurs

Le transport de mémoire tampon de caméra à producteur unique et à plusieurs consommateurs est un ensemble de méthodes qui permet aux clients de la caméra d'ajouter et de supprimer des surfaces de sortie de manière dynamique pendant que la session de capture est active et que le flux de caméra est en cours.

Connectivité

Appels et messages

Implémenter des forfaits de données

Android 9 et versions ultérieures offrent une meilleure compatibilité pour les opérateurs qui implémentent des forfaits Internet à l'aide des API SubscriptionPlan.

Applications d'appel tierces

Android 9 et versions ultérieures fournissent des API qui permettent aux applications d'appel tierces de gérer les appels entrants simultanés des opérateurs et d'enregistrer les appels dans le journal d'appels système.

Opérateur

Identification de l'opérateur

Dans Android 9, AOSP ajoute une base de données d'ID d'opérateur pour faciliter l'identification des opérateurs. La base de données minimise la logique en double et les expériences d'application fragmentées en fournissant un moyen commun d'identifier les opérateurs.

eSIM

La carte SIM intégrée (eSIM ou eUICC) est la dernière technologie permettant aux utilisateurs mobiles de télécharger un profil d'opérateur et d'activer son service sans avoir de carte SIM physique. Dans Android 9 et les versions ultérieures, le framework Android fournit des API standards pour accéder à l'eSIM et gérer les profils d'abonnement sur l'eSIM. Pour en savoir plus, voir :

Prise en charge de plusieurs cartes SIM pour les paramètres IMS

Android 9 et versions ultérieures apportent des améliorations aux paramètres utilisateur du sous-système multimédia IP (IMS). Vous pouvez configurer la VoLTE (Voice over LTE), les appels vidéo et les appels Wi-Fi pour chaque abonnement au lieu de partager ces paramètres pour tous les abonnements.

Diffusions de l'état de la carte SIM

Dans Android 9 et versions ultérieures, Intent.ACTION_SIM_STATE_CHANGED est obsolète. Deux diffusions distinctes pour l'état de la carte et l'état de l'application de la carte sont ajoutées : TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED et TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.

Grâce à ces modifications, les récepteurs qui n'ont besoin de savoir si une carte est présente n'ont pas besoin d'écouter les changements d'état de l'application, et les récepteurs qui n'ont besoin de savoir si les applications de carte sont prêtes n'ont pas besoin d'écouter les changements d'état de la carte.

Les deux nouvelles diffusions sont @SystemApis et ne sont pas permanentes. Seuls les récepteurs disposant de l'autorisation READ_PRIVILEGED_PHONE_STATE peuvent recevoir les diffusions.

Les intents ne sont pas rediffusés lorsque vous déverrouillez l'appareil. Les récepteurs qui dépendent des diffusions envoyées avant le déverrouillage doivent utiliser directBootAware ou interroger l'état après le déverrouillage par l'utilisateur. Les états peuvent être interrogés à l'aide des API correspondantes dans TelephonyManager, getSimCardState() et getSimApplicationState().

Wi-Fi

Wi-Fi de l'opérateur

La fonctionnalité Wi-Fi de l'opérateur permet aux appareils de se connecter automatiquement aux réseaux Wi-Fi implémentés par l'opérateur. Dans les zones très encombrées ou avec une couverture mobile minimale, comme un stade ou une station de métro souterraine, le Wi-Fi de l'opérateur permet d'améliorer la connectivité et de décharger le trafic.

Randomisation de l'adresse MAC

La randomisation de l'adresse MAC permet aux appareils d'utiliser des adresses MAC aléatoires lorsqu'ils recherchent de nouveaux réseaux alors qu'ils ne sont pas actuellement associés à un réseau. Dans Android 9 et versions ultérieures, une option pour les développeurs peut être activée pour qu'un appareil utilise une adresse MAC aléatoire lorsqu'il se connecte à un réseau Wi-Fi.

Activation automatique du Wi‑Fi

Lorsque la fonctionnalité Activation automatique du Wi-Fi est activée, le Wi-Fi est automatiquement réactivé chaque fois que l'appareil se trouve à proximité d'un réseau Wi-Fi enregistré dont l'indicateur d'intensité du signal reçu (RSSI) est suffisamment élevé.

Délai aller-retour du Wi-Fi

Le temps d'aller-retour Wi-Fi (RTT) permet aux appareils de mesurer la distance qui les sépare d'autres appareils compatibles, qu'il s'agisse de points d'accès (PA) ou de pairs Wi-Fi Aware (si Wi-Fi Aware est compatible sur l'appareil). Cette fonctionnalité est basée sur le protocole IEEE 802.11mc et permet aux applications d'utiliser une précision et une connaissance de la position améliorées.

Améliorations de la notation du Wi-Fi

Les modèles de notation Wi-Fi améliorés déterminent rapidement et précisément quand un appareil doit quitter un réseau Wi-Fi connecté ou rejoindre un nouveau réseau Wi-Fi. Ces modèles offrent une expérience fiable et fluide aux utilisateurs en évitant les interruptions de connectivité.

Examinez et ajustez les valeurs RSSI dans les ressources config.xml, en particulier les suivantes :

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

Concurrence Wi-Fi STA/AP

La concurrence Wi-Fi STA/AP permet aux appareils de fonctionner simultanément en mode station (STA) et point d'accès (AP). Pour les appareils compatibles avec le Wi-Fi double bande simultané (DBS), cela ouvre des possibilités telles que la non-interruption du Wi-Fi STA lorsqu'un utilisateur souhaite activer un point d'accès (SoftAP).

Améliorations apportées à WiFiStateMachine

WifiStateMachine est la classe principale utilisée pour contrôler l'activité Wi-Fi, coordonner les saisies utilisateur (modes de fonctionnement : point d'accès, recherche, connexion ou désactivé) et contrôler les actions du réseau Wi-Fi (comme la recherche ou la connexion).

Dans Android 9 et versions ultérieures, le code du framework Wi-Fi et l'implémentation de WifiStateMachine ont été réarchitecturés, ce qui a permis de réduire la taille du code, de faciliter la logique de contrôle du Wi-Fi, d'améliorer la précision du contrôle et d'accroître la couverture et la qualité des tests unitaires.

De manière générale,WifiStateMachine permet au Wi-Fi d'être dans l'un des quatre états suivants :

  • Mode client (peut se connecter et analyser)
  • Mode Analyse uniquement
  • Mode SoftAP (point d'accès Wi-Fi)
  • Désactivé (Wi-Fi complètement désactivé)

Chaque mode Wi-Fi a des exigences différentes pour l'exécution des services et doit être configuré de manière cohérente, en ne gérant que les événements pertinents pour son fonctionnement. La nouvelle implémentation limite le code aux événements liés à ce mode, ce qui réduit le temps de débogage et le risque d'introduction de nouveaux bugs en raison de la complexité. En plus de la gestion explicite de la fonctionnalité de mode, la gestion des threads est traitée de manière cohérente et l'utilisation de canaux asynchrones est éliminée en tant que mécanisme de synchronisation.

Mise à jour des autorisations Wi-Fi

Dans Android 9 et versions ultérieures, l'autorisation de l'application CHANGE_WIFI_STATE est activée par défaut. Vous pouvez désactiver l'autorisation pour n'importe quelle application sur la page des paramètres dans Paramètres > Applications et notifications > Accès spécifiques des applications > Contrôle du Wi-Fi.

Les applications doivent pouvoir gérer les cas où l'autorisation CHANGE_WIFI_STATE n'est pas accordée.

Pour valider ce comportement, exécutez les tests Robolectric et manuels.

Pour les tests manuels :

  1. Accédez à Paramètres > Applications et notifications > Accès spéciaux des applis > Contrôle du Wi-Fi.
  2. Sélectionnez l'autorisation pour votre application, puis désactivez-la.
  3. Vérifiez que votre application peut gérer le scénario dans lequel l'autorisation CHANGE_WIFI_STATE n'est pas accordée.

Obsolescence du WPS

En raison de problèmes de sécurité, la configuration Wi-Fi protégée (WPS) dans WiFiManager est obsolète et désactivée dans Android 9 et versions ultérieures. Toutefois, WiFiDirect utilise toujours WPS dans le supplicant WPA.

Graphiques

Implémentation

API Vulkan 1.1

Android 9 et les versions ultérieures permettent d'implémenter l'API graphique Vulkan 1.1.

Outil WinScope pour le traçage des transitions de fenêtres

Android 9 et versions ultérieures incluent l'outil WinScope pour tracer les transitions de fenêtres. WinScope fournit une infrastructure et des outils permettant d'enregistrer et d'analyser l'état du gestionnaire de fenêtres pendant et après les transitions. Il permet d'enregistrer et de parcourir les transitions de fenêtres, tout en enregistrant l'état du gestionnaire de fenêtres pertinent dans un fichier de trace. Vous pouvez utiliser ces données pour relire et parcourir la transition.

Le code source de l'outil WinScope se trouve à l'adresse platform/development/tools/winscope.

Interaction

Audio automobile

Automotive Audio décrit l'architecture audio pour les implémentations Android liées à l'automobile.

Le HAL Neural Networks (NN) définit une abstraction des différents accélérateurs. Les pilotes de ces accélérateurs doivent être conformes à cette HAL.

HAL véhicule

Propriétés du véhicule décrit les modifications apportées à l'interface HAL du véhicule.

Sélection des satellites GNSS

Lorsque vous utilisez de nouvelles HAL (Hardware Abstraction Layer) GNSS (Global Navigation Satellite System) (v1.1 et versions ultérieures), le framework Android surveille les paramètres Android. Les partenaires peuvent modifier les paramètres à partir des services Google Play ou d'autres mises à jour du système. Ces paramètres indiquent à la couche HAL GNSS si certains satellites GNSS ne doivent pas être utilisés. Cela peut être utile en cas d'erreurs persistantes liées aux constellations ou aux satellites GNSS, ou pour réagir plus rapidement aux problèmes d'implémentation GNSS HAL qui peuvent survenir lors du mélange de constellations utilisant différents systèmes temporels et événements externes, tels que les secondes intercalaires, les jours ou les changements de numéro de semaine.

Modèle du matériel GNSS

Dans Android 9, la version 1.1 ou ultérieure du GNSS HAL peut transmettre des informations sur l'API matérielle à la plate-forme. La plate-forme doit implémenter l'interface IGnssCallback et transmettre un handle au HAL. La couche HAL GNSS transmet les informations sur le modèle matériel via la méthode LocationManager#getGnssHardwareModelName(). Les fabricants d'appareils doivent collaborer avec leurs fournisseurs GNSS HAL pour fournir ces informations dans la mesure du possible.

Autorisations

Configurer les mises à jour du contrôle d'accès discrétionnaire

La section Configurer le contrôle d'accès discrétionnaire (DAC) contient des informations mises à jour sur le mécanisme des ID Android (AID) pour étendre les capacités du système de fichiers.

Ajouter des autorisations d'applications privilégiées à la liste blanche

Dans Android 9 et versions ultérieures, s'il existe des autorisations qui doivent être refusées, modifiez le fichier XML pour utiliser la balise deny-permission au lieu de la balise permission utilisée dans les versions précédentes.

Données

Améliorations apportées à l'estimation de la bande passante

Android 9 offre une meilleure prise en charge de l'estimation de la bande passante. Les applications Android peuvent définir des paramètres de résolution plus appropriés pour les appels vidéo et le streaming vidéo si elles ont accès à la bande passante disponible.

Sur les appareils équipés d'Android 6.0 ou version ultérieure, un appelant souhaitant obtenir une estimation de la bande passante pour un réseau mobile appelle ConnectivityManager.requestBandwidthUpdate(), et le framework peut fournir une estimation de la bande passante descendante.

Toutefois, sur les appareils exécutant Android 9 ou version ultérieure, le rappel onCapabilitiesChanged() se déclenche automatiquement en cas de changement important de la bande passante estimée, et l'appel de requestBandwidthUpdate() est une opération sans effet. Les getLinkDownstreamBandwidthKbps() et getLinkUpstreamBandwidthKbps() associés sont renseignés avec les informations mises à jour fournies par la couche physique.

De plus, les appareils peuvent vérifier les bandes passantes des cellules LTE via ServiceState.getCellBandwidths(). Cela permet aux applications de déterminer la bande passante (fréquence) disponible sur une cellule donnée. Les informations sur la bande passante des cellules sont disponibles dans un menu caché afin que les testeurs sur le terrain puissent consulter les informations les plus récentes.

Surveillance du trafic eBPF

L'outil de trafic réseau eBPF utilise une combinaison d'implémentations de l'espace noyau et de l'espace utilisateur pour surveiller l'utilisation du réseau sur un appareil depuis le dernier démarrage de l'appareil. Cet outil offre des fonctionnalités supplémentaires telles que le taggage de sockets, la séparation du trafic de premier plan/d'arrière-plan et un pare-feu par UID pour empêcher les applications d'accéder au réseau en fonction de l'état de l'appareil.

Restaurer vers des API inférieures

Les appareils peuvent désormais être restaurés à partir de versions ultérieures du système d'exploitation. Cela est particulièrement utile lorsque les utilisateurs ont changé de téléphone, mais l'ont ensuite perdu ou cassé.

Si un OEM modifie les agents de sauvegarde pour l'un des packages système (android, system, settings), ces agents doivent gérer la restauration des ensembles de sauvegarde qui ont été effectués sur des versions plus récentes de la plate-forme sans planter et en restaurant au moins certaines données.

Envisagez d'utiliser un validateur pour rechercher les valeurs non valides d'un élément de données de sauvegarde donné et ne restaurer que les données valides, comme dans core/java/android/provider/SettingsValidators.java.

Cette fonctionnalité est activée par défaut. La compatibilité de SettingsBackupAgent pour la restauration à partir de versions ultérieures peut être désactivée via Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION. Aucune implémentation supplémentaire n'est requise, sauf si le fabricant de l'appareil étend l'un des agents de sauvegarde inclus dans la ROM (ou ajoute un agent personnalisé).

Cette fonctionnalité permet de restaurer le système à partir de versions ultérieures de la plate-forme. Toutefois, il est raisonnable de s'attendre à ce que les données restaurées ne soient pas complètes. Les instructions suivantes s'appliquent aux agents de sauvegarde suivants :

  • PackageManagerBackupAgent est compatible avec les futures versions des données de sauvegarde via le versionnage du format. Les extensions ici doivent être compatibles avec le code de restauration actuel ou suivre les instructions de la classe, qui incluent l'incrémentation des constantes appropriées.

  • SystemBackupAgent spécifie restoreAnyVersion = false dans Android 9 et versions ultérieures. Il n'est pas compatible avec la restauration à partir de versions ultérieures de l'API.

  • SettingsBackupAgent spécifie restoreAnyVersion = true dans Android 9 et versions ultérieures. La prise en charge partielle existe via les validateurs. Un paramètre peut être restauré à partir d'une version d'API supérieure si un validateur existe pour celui-ci dans l'OS cible. Tout paramètre ajouté doit être accompagné de son validateur. Pour en savoir plus, consultez le cours.

  • Tout agent de sauvegarde personnalisé inclus dans la ROM doit incrémenter son code de version chaque fois qu'une modification incompatible est apportée au format des données de sauvegarde et s'assurer que restoreAnyVersion = false (la valeur par défaut) est utilisé si son agent n'est pas prêt à traiter les données de sauvegarde d'une future version de son code.

Entreprise

Améliorations apportées aux profils gérés

Les modifications apportées à l'UX pour les profils gérés permettent aux utilisateurs d'identifier, d'accéder et de contrôler plus facilement le profil géré.

Suspendre les OTA

Une nouvelle @SystemApi permet aux propriétaires d'appareils de suspendre indéfiniment les mises à jour OTA, y compris les mises à jour de sécurité.

Performances

Santé 2.0

Android 9 et versions ultérieures incluent android.hardware.health HAL 2.0, une mise à niveau majeure de la version health@1.0 HAL. Pour en savoir plus, consultez les pages suivantes :

Solution de mise en cache des APK

Android 9 et versions ultérieures incluent une solution de mise en cache des APK pour l'installation rapide des applications préchargées sur un appareil compatible avec les partitions A/B. Les OEM peuvent placer des applications préchargées et populaires dans le cache APK, qui est principalement stocké dans la partition B vide des nouveaux appareils partitionnés A/B, sans impacter l'espace de données destiné aux utilisateurs.

Optimisation guidée par le profil

Android 9 et versions ultérieures permettent d'utiliser l'optimisation guidée par profil (PGO) de Clang sur les modules Android natifs qui comportent des règles de compilation Blueprint.

Journalisation WAL

Un mode spécial de SQLiteDatabase appelé journalisation WAL (Write-Ahead Logging) compatible permet à une base de données d'utiliser journal_mode=WAL tout en conservant un maximum d'une connexion par base de données.

Temps de démarrage

Android 9 modifie l'optimisation du temps de démarrage, comme décrit dans Optimiser les temps de démarrage.

Puissance

Restrictions d'arrière-plan

Android 9 et versions ultérieures incluent des restrictions en arrière-plan qui permettent aux utilisateurs de limiter les applications susceptibles de décharger la batterie. Le système peut également suggérer de désactiver les applications qui affectent négativement l'état d'un appareil.

Appareils sans batterie

Android 9 gère les appareils sans batterie plus élégamment que dans les versions précédentes. Android 9 supprime le code pour les appareils sans batterie qui supposaient par défaut qu'une batterie était présente, chargée à 100 % et en bon état, avec une température normale sur sa thermistance.