Notes de version d'Android 9

Cette page résume 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. Consultez les mises à jour du site d'août 2018 pour un guide sur les déplacements et le changement de nom des sections.

Construire

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

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

Architecture

Couche d'abstraction matérielle (HAL)

Compatibilité descendante du framework HIDL

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

HAL disponibles dynamiquement

Les HAL disponibles dynamiquement prennent en charge l'arrêt dynamique des sous-systèmes matériels Android lorsqu'ils ne sont pas utilisés ou lorsqu'ils ne sont pas nécessaires.

HIDL

Bloc mémoire HIDL

HIDL MemoryBlock est une couche abstraite construite sur hidl_memory , HIDL @1.0::IAllocator et HIDL @1.0::IMapper . Il est conçu pour les services HIDL comportant 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 incluent la prise en charge des superpositions compressées dans l’image DTBO (Device Tree Blob Overlay) lors de l’utilisation de la version 1 de l’en-tête de la table de l’arborescence des appareils.

Mises à jour du DTO

Android 9 et versions ultérieures exigent que le chargeur de démarrage transmette le blob de l'arborescence des périphériques unifiée au noyau avant de modifier les propriétés définies dans les superpositions de l'arborescence des périphériques (DTO) .

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

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

Vérification DTBO

Android 9 et versions ultérieures nécessitent une partition DTBO. Pour ajouter des nœuds ou apporter des modifications aux propriétés dans le SoC DT, le chargeur de démarrage doit superposer dynamiquement une DT spécifique au périphérique sur le SoC DT. Pour plus d'informations, voir 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 plus d'informations, consultez ces pages :

NDK du fournisseur

Changement de design

Pour plus d'informations sur les modifications de conception du VNDK dans Android 9 et versions ultérieures, consultez ces pages :

Vérificateur ABI

La page Stabilité ABI décrit le vérificateur d'interface binaire d'application (ABI), qui garantit que les modifications apportées aux bibliothèques VNDK maintiennent la conformité 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 du 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 de l'interface du fournisseur décrivent les mises à jour dans Android 9 et versions ultérieures :

Calendrier de dépréciation HIDL

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

Chargeur de démarrage

Cloisons de produit

Android 9 et versions ultérieures prennent en charge la création de partitions /product à l'aide du système de construction 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 aux OEM créés à partir du système de build Android.

Conformité canonique aux raisons de démarrage

La page Canonical Boot Reason décrit les modifications apportées à la spécification de la raison de démarrage du chargeur de démarrage dans Android 9 et versions ultérieures.

Système en tant que root

Tous les appareils lancés avec Android 9 et versions ultérieures doivent utiliser system-as-root , qui fusionne ramdisk.img dans system.img (également connu sous le nom de no-ramdisk), qui à son tour est monté 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 pour indiquer la version de l'en-tête . Le chargeur de démarrage 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 disparités entre l'image de récupération et la partition DTBO sur les périphériques non-A/B, l'image de récupération doit contenir des informations de l'image DTBO .

Afficher

Découpes d'affichage

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

Faire pivoter les suggestions

Les mises à jour du comportement de rotation de l'écran sur Android 9 et versions ultérieures incluent la prise en charge d'un contrôle destiné à 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'application synchronisées permettent de nouvelles animations de transition d'application.

Classification de texte (anciennement TEXTCLASSIFIER)

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

Couleur à large gamme

Android 9 et versions ultérieures incluent la prise en charge d'une large gamme de couleurs, notamment :

  • Plage dynamique élevée (HDR)
  • 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 (telle que l'écran, le composant matériel, le GPU) doit prendre en charge les couleurs ou les formats de tampon à large gamme. Les appareils ne sont pas tenus de revendiquer la prise en charge du contenu à large gamme, même si le matériel le prend en charge. Cependant, une large gamme de couleurs doit être activée pour tirer pleinement parti du matériel. Pour éviter une expérience visuelle incohérente, les couleurs à large gamme ne doivent pas être désactivées pendant l'exécution.

Compatibilité

Document de définition de la compatibilité Android

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

Paramètres

De meilleurs widgets d'application

Le framework de widgets d'application Android offre une visibilité accrue sur les interactions des utilisateurs, 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 lancement (qui sont livrées avec les appareils) pour prendre en charge cette fonctionnalité si elles ne sont pas basées 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’AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca pour obtenir l’exemple de code fourni.

Notifications de changement d'état de l'appareil 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 manifeste et un processus se réveille pour recevoir la diffusion. Ceci est utile pour les installateurs de packages qui souhaitent installer des composants supplémentaires d'applications lors de telles modifications, ce qui est rare, car les modifications de configuration éligibles pour déclencher cette diffusion sont rares.

Le code source de 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 des informations de l'application Paramètres offrent plus de fonctionnalités et une mise en œuvre plus facile.

Essais

Un examen

L'outil de ligne de commande Atest vous permet de créer, d'installer et d'exécuter des tests Android localement, accélérant ainsi considérablement les réexécutions des tests sans nécessiter de connaissance des options de ligne de commande du faisceau de tests de la Trade Federation.

Suite de tests de compatibilité

Téléchargements CTS

Les packages Compatibility Test Suite (CTS) prenant en charge Android 9 sont disponibles sur la page de 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 obtient la commande et l'argument suivants :

  • run retry réessaye tous les tests qui ont échoué ou qui n'ont pas été exécutés lors des sessions précédentes.
  • '--shard-count fragments d'un CTS exécuté en un nombre donné de morceaux indépendants, pour s'exécuter sur plusieurs appareils en parallèle.

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

Service Élément sécurisé (SE)

Le service Secure Element vérifie les éléments sécurisés pris en charge par la plate-forme globale en identifiant si les appareils ont une implémentation SE HAL et si oui, combien. Ceci est utilisé comme base pour tester l’API et la mise en œuvre de l’élément sécurisé sous-jacent.

Boîte de fusion de capteurs

Le boîtier de fusion de capteurs est utilisé dans le test de fusion de capteurs et le test de synchronisation multi-caméras de Camera Image Test Suite (Camera ITS) et 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. Consultez ces pages pour plus d’informations :

Large champ de vision ITS-in-a-box

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

Suite de tests du fournisseur

Architecture du contrôleur hôte

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

Tests HAL prenant en compte le nom du service

Les tests HAL prenant en charge le nom du service VTS prennent en charge l'obtention du nom de service d'une instance HAL donnée en fonction du périphérique sur lequel les tests VTS sont exécutés.

Contrôle de testabilité HAL

La vérification de testabilité VTS HAL inclut une méthode d'exécution permettant d'utiliser la configuration du périphérique afin d'identifier les tests VTS qui doivent être ignorés pour cette cible de périphérique.

Infrastructure de tests automatisés

L' infrastructure de tests automatisés est une infrastructure VTS pour les tests automatisés de 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

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 et d'appareil ou d'application. Cela rendait difficile, voire impossible, l’identification des causes profondes des problèmes.

Android 9 inclut la fonction de télémétrie statsd , qui résout ce problème en collectant plus rapidement de meilleures données. statsd collecte l'utilisation des applications, les statistiques de batterie et de 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 plus de détails, voir frameworks/base/cmds/statsd/ .

Fonctions de sécurité

Signature d'application

Le schéma de signature APK v3 prend en charge la rotation des clés APK.

Prise en charge 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 plus d'informations sur l'intégration de votre pile biométrique pour inclure BiometricPrompt , voir Biométrie .

Analyse dynamique

Android 9 inclut la prise en charge de davantage d'outils d'atténuation et d'analyse des exploits .

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 les modifications du graphique de flux de contrôle d'origine d'un binaire compilé, ce qui rend beaucoup plus difficile la réalisation de telles attaques.

Finance du noyau

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

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 complet du disque.

Cryptage des métadonnées

Android 9 et versions ultérieures incluent la prise en charge du cryptage des métadonnées lorsque la prise en charge matérielle est présente. Avec le chiffrement des métadonnées, une clé unique présente au moment du démarrage utilise le chiffrement basé sur les fichiers pour chiffrer tout contenu non chiffré.

Magasin de clés

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

Coffre Fort

Android 9 et versions ultérieures incluent la prise en charge des clés Android Keystore qui sont stockées et utilisées dans un processeur physiquement séparé spécialement conçu pour les applications de haute sécurité, telles qu'un élément sécurisé (SE) intégré. StrongBox Keymaster est une implémentation de Keymaster HAL dans un matériel sécurisé discret. Une StrongBox possède :

  • Processeur discret
  • Stockage sécurisé intégral
  • Générateur de vrais nombres aléatoires de haute qualité
  • Emballage inviolable
  • Résistance des canaux latéraux

Importation de clé sécurisée

Pour importer en toute sécurité une clé dans Keymaster 4, une clé créée hors appareil est cryptée avec une spécification des autorisations qui définissent la manière dont la clé peut être utilisée.

Prise en charge de 3DES

Keymaster 4 inclut 3DES pour la compatibilité avec les systèmes existants 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 version de clé pour avoir des niveaux de correctifs distincts pour chaque partition. Cela permet à chaque partition d'être mise à jour indépendamment tout en offrant une protection contre la restauration.

API de confirmation protégée Android

Les appareils pris en charge qui démarrent avec Android 9 installé donnent aux développeurs la possibilité d'utiliser l' API Android Protected Confirmation . Avec cette API, les applications peuvent utiliser une instance de ConfirmationPrompt pour afficher une invite à l'utilisateur, lui demandant d'approuver une courte déclaration. Cette déclaration permet à une application de réaffirmer que l'utilisateur souhaite effectuer une transaction sensible, comme effectuer un paiement.

SELinux

Bac à sable SELinux par application

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

Modifications des aigus SELinux

Les mises à jour de Treble SELinux sous Android 9 et supérieur sont documentées sur plusieurs pages de la section SELinux .

Initialisation du fournisseur

L'initialisation du fournisseur comble le trou dans la division système/fournisseur Treble en utilisant un domaine SELinux distinct pour exécuter les commandes /vendor avec des autorisations spécifiques au fournisseur.

Propriétés du système

Android 9 empêche le partage inutile des propriétés système entre les partitions system et celles vendor et fournit une méthode permettant de garantir 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 construction 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 ont l'attribut sysfs_type requis.

l'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 flottant et l'augmentation des pistes de sortie client simultanées, de la mémoire client/serveur maximale et du nombre total de pistes mixées.

Caméra

Caméras USB externes

Android 9 et versions ultérieures prennent en charge 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 la caméra.

Suivi de mouvement

Les appareils photo peuvent annoncer une capacité de suivi de mouvement .

Prise en charge multi-caméras

La prise en charge multi-caméras inclut la prise en charge API pour les appareils multi-caméras via un nouveau périphérique de caméra logique composé de deux ou plusieurs caméras physiques pointant dans la même direction.

Paramètres de session

La mise en œuvre de paramètres de session peut réduire les retards en permettant aux clients de la caméra de configurer activement un sous-ensemble de paramètres de demande coûteux dans le cadre de la phase d'initialisation de la session de capture.

Producteur unique, tampon de consommateurs multiples

Le transport de tampons de caméra à producteur unique et à plusieurs consommateurs est un ensemble de méthodes qui permettent aux clients de 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 streaming de la caméra est en cours.

Connectivité

Appel et messagerie

Mettre en œuvre des plans de données

Android 9 et versions ultérieures offrent une prise en charge améliorée pour les opérateurs mettant en œuvre des forfaits de données à 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 (3P) de gérer les appels entrants simultanés des opérateurs et de consigner les appels dans le journal des appels système.

Transporteur

Identification du transporteur

Dans Android 9, AOSP ajoute une base de données d'identification 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 standard pour accéder à l'eSIM et gérer les profils d'abonnement sur l'eSIM. Pour plus d'informations, voir :

Prise en charge multi-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 voix off LTE (VoLTE), les appels vidéo et les appels Wi-Fi pour chaque abonnement au lieu de partager ces paramètres entre tous les abonnements.

Diffusions d'état SIM

Dans 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 changements, les récepteurs qui ont seulement besoin de savoir si une carte est présente n'ont pas besoin d'écouter les changements d'état des applications, et les récepteurs qui ont seulement 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 collantes. Seuls les récepteurs disposant de l'autorisation READ_PRIVILEGED_PHONE_STATE peuvent recevoir les émissions.

Les intentions ne sont pas rediffusées lorsque vous déverrouillez l'appareil. Les récepteurs qui dépendent des diffusions envoyées avant le déverrouillage doivent soit utiliser directBootAware , soit 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() .

Wifi

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 mis en œuvre par l'opérateur. Dans les zones très encombrées ou avec une couverture cellulaire minimale, comme un stade ou une gare souterraine, le Wi-Fi opérateur contribue à améliorer la connectivité et à décharger le trafic.

Randomisation MAC

La randomisation MAC permet aux appareils d'utiliser des adresses MAC aléatoires lors de la recherche de nouveaux réseaux alors qu'ils ne sont pas actuellement associés à un réseau. Sous Android 9 et versions ultérieures, une option de développement peut être activée pour qu'un appareil utilise une adresse MAC aléatoire lors de la connexion à un réseau Wi-Fi.

Activer le Wi-Fi automatiquement

Lorsque la fonction Activer le Wi-Fi automatiquement 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 force relative du signal reçu (RSSI) suffisamment élevé.

Durée du trajet aller-retour Wi-Fi

Le temps d'aller-retour Wi-Fi (RTT) permet aux appareils de mesurer la distance par rapport à d'autres appareils pris en charge, qu'il s'agisse de points d'accès (AP) ou de pairs Wi-Fi Aware (si Wi-Fi Aware est pris en charge 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 améliorées de la localisation.

Améliorations du score 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 entrer dans un nouveau réseau Wi-Fi. Ces modèles offrent une expérience fiable et transparente aux utilisateurs 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

Concurrence Wi-Fi STA/AP

La simultanéité Wi-Fi STA/AP est la possibilité pour les appareils de fonctionner simultanément en modes station (STA) et point d'accès (AP). Pour les appareils prenant en charge le Wi-Fi double bande simultanée (DBS), cela ouvre des fonctionnalités telles que ne pas perturber le 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 de l'utilisateur (modes de fonctionnement : point d'accès, analyse, connexion ou arrêt) et contrôler les actions du réseau Wi-Fi (telles que l'analyse ou la connexion).

Dans Android 9 et versions ultérieures, le code du cadre Wi-Fi et la mise en œuvre de WifiStateMachine sont réorganisés, ce qui entraîne une taille de code réduite, une logique de contrôle Wi-Fi plus facile à suivre, une granularité de contrôle améliorée et une couverture et une qualité accrues des tests unitaires. .

À un niveau élevé, WifiStateMachine permet au Wi-Fi d'être dans l'un des quatre états suivants :

  • Mode client (peut se connecter et numériser)
  • Mode numérisation 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 traitant uniquement les événements pertinents pour son fonctionnement. La nouvelle implémentation limite le code aux événements liés à ce mode, réduisant ainsi le temps de débogage et le risque d'introduire de nouveaux bogues 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 et versions ultérieures, l'autorisation de l'application CHANGE_WIFI_STATE est activée par défaut. Vous pouvez désactiver l'autorisation de n'importe quelle application sur la page des paramètres dans Paramètres > Applications et notifications > Accès spécial aux applications > Contrôle Wi-Fi .

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

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

Pour les tests manuels :

  1. Accédez à Paramètres > Applications et notifications > Accès aux applications spéciales > Contrôle 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 dans lequel l'autorisation CHANGE_WIFI_STATE n'est pas accordée.

Dépréciation de WPS

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

Graphique

Mise en œuvre

API Vulkan 1.1

Android 9 et versions ultérieures prennent en charge la mise en œuvre de 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être. WinScope fournit une infrastructure et des outils pour enregistrer et 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être, tout en enregistrant tous les états pertinents du gestionnaire de fenêtres dans un fichier de trace. Vous pouvez utiliser ces données pour rejouer et parcourir la transition.

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

Interaction

Audio automobile

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

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

Véhicule HAL

Les propriétés du véhicule décrivent les modifications apportées à l'interface HAL du véhicule.

Sélection des satellites GNSS

Lorsque vous travaillez avec les nouveaux HAL du système mondial de navigation par satellite (GNSS) (v1.1+), 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 GNSS HAL si certains satellites GNSS ne doivent pas être utilisés. Cela peut être utile en cas d'erreurs persistantes de satellite ou de constellation GNSS, ou pour réagir plus rapidement aux problèmes de mise en œuvre de GNSS HAL qui peuvent survenir lors du mélange de constellations utilisant différents systèmes horaires et événements externes, tels que les changements de numéro de seconde intercalaire, de jour ou de semaine. .

Modèle matériel GNSS

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

Autorisations

Configuration des mises à jour discrétionnaires du contrôle d'accès

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

Mettre sur liste blanche les autorisations des applications privilégiées

Sous Android 9 et versions ultérieures, si des autorisations doivent être refusées, modifiez le code 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 de l'estimation de la bande passante

Android 9 offre une prise en charge améliorée 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 peuvent accéder à la bande passante de données disponible.

Sur les appareils exécutant Android 6.0 ou version ultérieure, un appelant souhaitant une estimation de la bande passante pour un réseau cellulaire appelle ConnectivityManager.requestBandwidthUpdate() , et le framework peut fournir une estimation de la bande passante de liaison descendante.

Mais sur les appareils exécutant 9 ou version ultérieure, le rappel onCapabilitiesChanged() se déclenche automatiquement lorsqu'il y a un changement significatif dans la bande passante estimée, et l'appel requestBandwidthUpdate() n'est pas une opération ; 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 quantité de bande passante (fréquence) disponible sur une cellule donnée. Les informations sur la bande passante cellulaire sont disponibles via un menu caché afin que les testeurs sur le terrain puissent vérifier les informations les plus récentes.

Surveillance du trafic eBPF

L' outil de trafic réseau eBPF utilise une combinaison d'implémentation du noyau et de l'espace utilisateur pour surveiller l'utilisation du réseau sur un périphérique depuis le dernier démarrage du périphérique. Cet outil fournit des fonctionnalités supplémentaires telles que le marquage de socket, la séparation du trafic de premier plan/arrière-plan et un pare-feu par UID pour bloquer l'accès des applications au réseau en fonction de l'état de l'appareil.

Restaurer vers des API inférieures

Les appareils peuvent désormais restaurer à partir des futures versions du système d'exploitation. Ceci 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 effectués sur des versions supérieures de la plate-forme sans planter et en restaurant au moins certaines données.

Pensez à utiliser un validateur pour vérifier les valeurs non valides d'une donnée de sauvegarde donnée et restaurer uniquement les données valides, comme dans core/java/android/provider/SettingsValidators.java .

La fonctionnalité est activée par défaut. La prise en charge de SettingsBackupAgent pour la restauration à partir de versions futures 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 du périphérique étend l'un des agents de sauvegarde inclus dans la ROM (ou ajoute un agent personnalisé).

Cette fonctionnalité permet les restaurations du système à partir des futures versions de la plateforme ; cependant, 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 prend en charge 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, qui incluent le remplacement des constantes appropriées.

  • SystemBackupAgent spécifie restoreAnyVersion = false dans Android 9 et versions ultérieures. Il ne prend pas en charge la restauration à partir de versions supérieures de l'API.

  • SettingsBackupAgent spécifie restoreAnyVersion = true dans Android 9 et versions ultérieures. Un support partiel existe via les validateurs. Un paramètre peut être restauré à partir d’une version d’API supérieure s’il existe un validateur correspondant dans le système d’exploitation cible. L’ajout de tout paramètre doit être accompagné de son validateur. Vérifiez la classe pour plus de détails.

  • 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 des données de sauvegarde et garantir restoreAnyVersion = false (valeur par défaut) si son agent n'est pas prêt à gérer les données de sauvegarde d'une version future de leur code.

Entreprise

Améliorations du profil géré

Les modifications 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

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

Performance

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 plus d'informations, consultez ces pages :

Solution de mise en cache APK

Android 9 et versions ultérieures incluent une solution de mise en cache APK pour une installation rapide d'applications préchargées sur un appareil prenant en charge 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 A/B sans affecter l'espace de données destiné à l'utilisateur.

Optimisation guidée par le profil

Android 9 et versions ultérieures prennent en charge l'utilisation de l'optimisation guidée par profil (PGO) de Clang sur les modules Android natifs dotés de règles de construction de modèles.

Journalisation en écriture anticipée

Un mode spécial de SQLiteDatabase appelé compatibilité write-ahead logging (WAL) 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 Optimisation des temps de démarrage .

Pouvoir

Restrictions d'arrière-plan

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

Appareils sans batterie

Android 9 gère les appareils sans batterie avec plus d'élégance 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 bonne santé avec une lecture de température normale sur sa thermistance.