Notes de version d'Android 9

Cette page récapitule les principales fonctionnalités de la version Android 9 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 connaître le détail de la procédure, 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 sont 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 les appareils qui passent à 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 dynamiquement

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

MemoryBlock HIDL

MemoryBlock HIDL 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 seul tas de mémoire.

Superpositions de l'arborescence des appareils

Superpositions compressées

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

Mises à jour des DTO

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

Gestion des versions des en-têtes d'image DTBO

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

Vérification de la DTBO

Android 9 ou version ultérieure nécessite 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 la section Compilation et validation.

Conformité du noyau

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

NDK du fournisseur

Modifications de conception

Pour en savoir plus sur les modifications de 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 de l'interface binaire d'application (ABI), qui garantit que les modifications apportées aux bibliothèques VNDK respectent la conformité de 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 fournisseur (objet VINTF)

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

Calendrier d'abandon de HIDL

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

Bootloader (chargeur d'amorçage)

Partitions de produits

Android 9 et versions ultérieures prennent en charge la création de 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 réserver d'espace pour les composants spécifiques à l'OEM créés à partir du système de compilation Android.

Conformité avec la raison 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 avec system.img (également appelé "no-ramdisk"), qui est à son tour installé en tant que rootfs.

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

Sous 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 récupération

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

Écran

Encoches

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

Suggestions de rotation

Les mises à jour du comportement de rotation de l'écran sous Android 9 et versions ultérieures incluent la prise en charge d'une commande destinée à 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'application synchronisées

Les transitions d'application synchronisées permettent de créer de nouvelles animations de transition d'application.

Classification de texte (anciennement TEXTCLASSIFIER)

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

Couleur à 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

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

Compatibilité

Document de définition de la compatibilité Android

Le document de définition de la compatibilité Android 9 (CDD) s'appuie sur les versions précédentes avec des mises à jour des nouvelles fonctionnalités et des modifications des exigences pour les fonctionnalités publiées précédemment.

Paramètres

Meilleurs widgets d'application

Le framework de widgets d'application Android offre une visibilité accrue sur les interactions utilisateur, en particulier lorsqu'un utilisateur supprime ou ajoute manuellement des widgets. Cette fonctionnalité est fournie par défaut avec Launcher3.

Les fabricants doivent mettre à jour leurs applications de lanceur (qui sont fournies avec les appareils) pour prendre en charge cette fonctionnalité si elle n'est pas basée sur Launcher3. Les OEM doivent prendre en charge le nouveau champ widgetFeatures dans leur lanceur 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'ID de modification AOSP Iccd6f965fa3d61992244a365efc242122292c0ca pour l'exemple de code fourni.

Notifications de changement d'état de l'appareil aux programmes d'installation de paquets

Une diffusion système protégée peut être envoyée aux applications qui disposent de l'autorisation INSTALL_PACKAGES chaque fois qu'une propriété est modifiée, comme la langue ou la densité d'affichage. Les récepteurs peuvent être enregistrés dans le fichier manifeste, et un processus se réveille 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 ces modifications, ce qui est inhabituel, car les modifications de configuration pouvant 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 localement, ce qui accélère considérablement les nouvelles exécutions de tests sans nécessiter de connaissances sur les options de ligne de commande du banc d'essais Trade Federation.

Compatibility Test Suite

Téléchargements CTS

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

Options CTS

Pour Android 9, CTS v2 bénéficie des commandes et arguments suivants:

  • run retry relance tous les tests qui ont échoué ou qui n'ont pas été exécutés à partir des sessions précédentes.
  • ‘--shard-count divise une exécution CTS en un nombre donné de segments 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é (SE)

Le service d'élément sécurisé recherche les éléments sécurisés compatibles avec la plate-forme globale en déterminant 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 de capteurs

La boîte de fusion de capteurs est utilisée dans le test de fusion de capteurs et le test de synchronisation multicaméra de la suite de tests d'images de l'appareil photo (Camera ITS). Elle fournit un environnement de test cohérent pour mesurer la précision du code temporel de l'appareil photo et des autres capteurs des téléphones Android. Pour en savoir plus, consultez les pages suivantes:

Système ITS tout-en-un à grand champ de vision

Le système ITS tout-en-un à champ de vision large est un système automatisé conçu pour tester à la fois les systèmes de caméras à champ de vision large (WFoV) et à champ de vision régulier (RFoV) dans l'ITS de caméra.

Suite de tests du fournisseur

Architecture du contrôleur hôte

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

Test HAL tenant compte du nom du service

Les tests HAL tenant compte du nom 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é du HAL

La vérification de la testabilité du HAL VTS 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 test automatisé

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

Débogage

Télémétrie avancée

Sous Android, la télémétrie est le processus de collecte automatique d'informations d'utilisation et de diagnostic sur l'appareil, le système Android et les 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 à l'appareil ou à l'application. Cela rendait l'identification des causes profondes des problèmes difficile, voire impossible.

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 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 pour inclure BiometricPrompt, consultez la section Biométrie.

Analyse dynamique

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

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'un binaire compilé, ce qui rend ces attaques beaucoup plus difficiles à effectuer.

CFI du noyau

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

Chiffrement

Chiffrement basé sur les fichiers

Le chiffrement basé sur les fichiers (FBE) est mis à jour pour fonctionner avec le stockage adoptable. Les nouveaux appareils doivent utiliser le chiffrement basé sur les fichiers plutôt que le chiffrement de disque.

Chiffrement des métadonnées

Android 9 et les versions ultérieures sont compatibles avec le chiffrement des métadonnées lorsque la compatibilité matérielle est disponible. Avec le chiffrement des métadonnées, une seule clé présente au 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 dispose de ces fonctionnalités.

StrongBox

Android 9 et versions ultérieures prennent en charge 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 composant sécurisé (SE) intégré. StrongBox Keymaster est une implémentation du HAL Keymaster dans du matériel sécurisé discret. Un StrongBox possède les caractéristiques suivantes:

  • Processeur distinct
  • Stockage sécurisé intégré
  • Générateur de nombres aléatoires de haute qualité
  • Emballage anti-piratage
  • Résistance aux attaques par canal auxiliaire

Importation de clés sécurisée

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 comment la clé peut être utilisée.

Compatibilité avec 3DES

Keymaster 4 inclut le chiffrement 3DES pour assurer la compatibilité avec les anciens systèmes qui l'utilisent.

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 version de clé pour disposer de niveaux de correctifs distincts pour chaque partition. Cela permet à chaque partition d'être mise à jour indépendamment, tout en offrant une protection contre le rollback.

API Android Protected Confirmation

Les appareils compatibles qui démarrent avec Android 9 installé permettent aux développeurs d'utiliser l'API Confirmation de protection Android. 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 apportées à SELinux dans Treble

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

Initialisation du fournisseur

Vendor init comble la faille dans la répartition système/fournisseur de Treble en utilisant un domaine SELinux distinct pour exécuter des commandes /vendor avec des autorisations spécifiques au fournisseur.

Propriétés système

Android 9 empêche le partage inutile des propriétés système entre les partitions system et vendor, et fournit une méthode permettant de garantir la cohérence entre les propriétés système partagées.

Tests des attributs SELinux

Android 9 inclut de nouveaux tests au moment de la compilation qui garantissent que tous les fichiers situés dans des emplacements spécifiques disposent des attributs appropriés. Par exemple, tous les fichiers de sysfs disposent de 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 sont compatibles avec l'utilisation de 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 appareils photo peuvent annoncer la fonctionnalité de suivi des mouvements.

Compatibilité avec plusieurs caméras

La compatibilité multicaméra inclut la prise en charge des appareils multicaméra par l'API via un nouvel appareil photo logique composé de deux appareils photo physiques ou plus orientés dans la même direction.

Paramètres de session

L'implémentation de 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 à producteur unique et plusieurs consommateurs

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

Connectivité

Appels et messages

Implémenter des plans de données

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

Applications d'appel tierces

Android 9 et versions ultérieures fournit des API qui permettent aux applications d'appel tierces de gérer les appels entrants du transporteur simultanés et de consigner les appels dans le journal des appels du 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 de l'opérateur. 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 le service d'un opérateur sans avoir de carte SIM physique. Sous Android 9 et 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 améliorent les paramètres utilisateur du sous-système multimédia IP (IMS). Vous pouvez configurer la voix sur LTE (VoLTE), les appels vidéo et les appels Wi-Fi par abonnement au lieu de partager ces paramètres pour tous les abonnements.

Diffusions de l'état de la carte SIM

Sous Android 9 et versions ultérieures, Intent.ACTION_SIM_STATE_CHANGED est obsolète, et 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.

Avec ces modifications, les récepteurs qui ne doivent savoir que si une carte est présente n'ont pas besoin d'écouter les changements d'état de l'application, et les récepteurs qui ne doivent savoir que 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 persistantes. Seuls les récepteurs disposant de l'autorisation READ_PRIVILEGED_PHONE_STATE peuvent recevoir les annonces.

Les intents ne sont pas retransmis 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 de 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é Réseau 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 de forte congestion ou avec une couverture cellulaire minimale, comme un stade ou une gare de métro, le Wi-Fi de l'opérateur permet d'améliorer la connectivité et de décharger le trafic.

Sélection aléatoire 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 associés à un réseau. Sous 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 lors de la connexion à 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é avec un indicateur de l'intensité du signal reçu (RSSI) suffisamment élevé.

Délai aller-retour sur le Wi-Fi

La latence aller-retour Wi-Fi (RTT) permet aux appareils de mesurer la distance par rapport aux autres appareils compatibles, qu'il s'agisse de points d'accès (PA) ou d'pairs Wi-Fi Aware (si Wi-Fi Aware est compatible avec l'appareil). Cette fonctionnalité repose 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 l'évaluation 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 en rejoindre un nouveau. Ces modèles offrent aux utilisateurs une expérience fiable et fluide en évitant les lacunes 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

Concurrency Wi-Fi STA/AP

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

Améliorations de WiFiStateMachine

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

Sous Android 9 et versions ultérieures, le code du framework Wi-Fi et l'implémentation de WifiStateMachine sont repensés, ce qui réduit la taille du code, facilite la logique de contrôle du Wi-Fi, améliore la granularité de contrôle et améliore 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 effectuer des recherches)
  • Mode "Analyser 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 les services en cours d'exécution 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'introduire de nouveaux bugs en raison de la complexité. En plus de la gestion explicite des fonctionnalités de mode, la gestion des threads est gérée de manière cohérente et l'utilisation de canaux asynchrones est éliminée en tant que mécanisme de synchronisation.

Mises à jour des autorisations Wi-Fi

Sous Android 9 ou version ultérieure, l'autorisation d'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 Settings > Apps & notifications > Special app access > Wi-Fi control (Paramètres > Applications et notifications > Accès spéciaux 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 roboelectric 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 et désactivez l'autorisation pour votre application.
  3. Vérifiez que votre application peut gérer le scénario où l'autorisation CHANGE_WIFI_STATE n'est pas accordée.

Abandon de 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 versions ultérieures permettent d'implémenter l'API graphique Vulkan 1.1.

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

Android 9 et versions ultérieures incluent l'outil WinScope pour le traçage des transitions de fenêtre. 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 d'effectuer des étapes dans les transitions de fenêtre, tout en enregistrant tout état de gestionnaire de fenêtres pertinent dans un fichier de suivi. Vous pouvez utiliser ces données pour relire la transition et la suivre étape par étape.

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

Interaction

Audio pour véhicules

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

Le HAL Réseaux de neurones (NN) définit une abstraction des différents accélérateurs. Les pilotes de ces accélérateurs doivent se conformer à ce HAL.

HAL véhicule

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

Sélection du satellite GNSS

Lorsque vous travaillez avec de nouveaux HAL GNSS (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 au HAL GNSS si certains satellites GNSS ne doivent pas être utilisés. Cela peut être utile en cas d'erreurs persistantes sur les satellites ou les constellations GNSS, ou pour réagir plus rapidement aux problèmes d'implémentation du HAL GNSS pouvant survenir lors du mélange de constellations utilisant différents systèmes temporels et des événements externes, tels que les secondes intercalaires, les jours ou les rollovers de numéros de semaine.

Modèle matériel GNSS

Sous Android 9, la version 1.1 ou ultérieure du HAL GNSS peut transmettre des informations sur l'API matérielle à la plate-forme. La plate-forme doit implémenter l'interface IGnssCallback et transmettre un gestionnaire au HAL. Le 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 de HAL GNSS pour fournir ces informations dans la mesure du possible.

Autorisations

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

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

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

Sous Android 9 et versions ultérieures, si des autorisations 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 compatibilité avec 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 peuvent accéder à la bande passante de données disponible.

Sur les appareils équipés d'Android 6.0 ou version ultérieure, un appelant qui souhaite 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 en liaison descendante.

Toutefois, sur les appareils exécutant Android 9 ou version ultérieure, le rappel onCapabilitiesChanged() se déclenche automatiquement en cas de modification importante 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 de fréquences des cellules LTE via ServiceState.getCellBandwidths(). Cela permet aux applications de déterminer la quantité de bande passante (fréquence) disponible sur une cellule donnée. Les informations sur la bande passante de la cellule sont disponibles via un menu masqué 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 du 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 fournit des fonctionnalités supplémentaires telles que le taggage de sockets, la séparation du trafic de premier plan/arrière-plan et le pare-feu par UID pour bloquer l'accès des applications au réseau en fonction de l'état de l'appareil.

Restaurer des API antérieures

Les appareils peuvent désormais effectuer une restauration à partir de futures versions du système d'exploitation. Cette fonctionnalité est particulièrement utile lorsque les utilisateurs ont mis à niveau leur 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, système, paramètres), ces agents doivent gérer la restauration des ensembles de sauvegardes créés sur des versions supérieures de la plate-forme sans plantage et en restaurant au moins certaines données.

Envisagez d'utiliser un outil de validation 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 prise en charge de la restauration à partir de futures versions par SettingsBackupAgent 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 futures versions 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 la gestion des versions de format. Les extensions ici doivent être compatibles avec le code de restauration actuel ou suivre les instructions de la classe, y compris en modifiant les constantes appropriées.

  • SystemBackupAgent spécifie restoreAnyVersion = false sous 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 sous Android 9 et versions ultérieures. Une compatibilité partielle est disponible via les validateurs. Un paramètre peut être restauré à partir d'une version d'API supérieure s'il existe un validateur pour celui-ci dans l'OS cible. L'ajout d'un paramètre doit être accompagné de son outil de validation. Consultez le cours pour en savoir plus.

  • Tout agent de sauvegarde personnalisé inclus dans la ROM doit augmenter son code de version chaque fois qu'une modification incompatible est apportée au format de données de sauvegarde et s'assurer que restoreAnyVersion = false (valeur par défaut) est défini si son agent n'est pas prêt à gérer 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'expérience utilisateur pour les profils gérés permettent aux utilisateurs d'identifier, d'accéder et de contrôler plus facilement le profil géré.

Mettre en pause les OTA

Un nouveau @SystemApi permet aux propriétaires d'appareils de mettre en pause 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 par rapport à la version HAL health@1.0. Pour en savoir plus, consultez les pages suivantes:

Solution de mise en cache de l'APK

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

Optimisation guidée par le profil

Android 9 et versions ultérieures prennent en charge l'optimisation guidée par profil (PGO) de Clang sur les modules Android natifs qui disposent de règles de compilation de modèle.

Journalisation WAL

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

Temps de démarrage

Android 9 modifie l'optimisation du temps de démarrage, comme décrit dans la section Optimisation du temps de démarrage.

Puissance

Restrictions d'arrière-plan

Android 9 et les versions ultérieures incluent des restrictions en arrière-plan qui permettent aux utilisateurs de limiter les applications susceptibles de vider la batterie. Le système peut également suggérer de désactiver les applications qui ont un impact négatif sur l'état de santé 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 des 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 son thermistor.