Changements de comportement : toutes les applications

Android 9 (niveau d'API 28) apporte un certain nombre de modifications au système Android. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles s'exécutent sur la plate-forme Android 9, quel que soit le niveau d'API qu'elles ciblent. Tous les développeurs doivent examiner ces modifications et modifier leurs applications pour les prendre en charge correctement, le cas échéant.

Pour les modifications qui ne concernent que les applications qui ciblent le niveau d'API 28 ou supérieur, consultez Changements de comportement: applications ciblant le niveau d'API 28 ou supérieur.

Gestion de l'alimentation

Android 9 introduit de nouvelles fonctionnalités pour améliorer la gestion de l'alimentation des appareils. Ces modifications, ainsi que les fonctionnalités qui étaient déjà présentes avant Android 9, permettent de garantir que les ressources système sont mises à la disposition des applications qui en ont le plus besoin.

Pour en savoir plus, consultez Gestion de l'alimentation.

Modifications concernant la confidentialité

Pour améliorer la confidentialité des utilisateurs, Android 9 introduit plusieurs changements de comportement, tels que la limitation de l'accès des applications en arrière-plan aux capteurs de l'appareil, la restriction des informations récupérées à partir des recherches Wi-Fi, ainsi que de nouvelles règles d'autorisation et groupes d'autorisations liés aux appels téléphoniques, à l'état du téléphone et aux recherches Wi-Fi.

Ces modifications affectent toutes les applications exécutées sous Android 9, quelle que soit la version du SDK cible.

Accès limité aux capteurs en arrière-plan

Android 9 limite la capacité des applications en arrière-plan à accéder aux entrées utilisateur et aux données des capteurs. Si votre application s'exécute en arrière-plan sur un appareil équipé d'Android 9, le système applique les restrictions suivantes à votre application:

  • Votre application ne peut pas accéder au micro ni à l'appareil photo.
  • Les capteurs qui utilisent le mode de création de rapports continu, tels que les accéléromètres et les gyroscopes, ne reçoivent pas d'événements.
  • Les capteurs qui utilisent le mode de création de rapport on-change ou one-shot ne reçoivent pas d'événements.

Si votre application doit détecter les événements de capteurs sur les appareils équipés d'Android 9, utilisez un service de premier plan.

Accès limité aux journaux d'appels

Android 9 introduit le groupe d'autorisations CALL_LOG et déplace les autorisations READ_CALL_LOG, WRITE_CALL_LOG et PROCESS_OUTGOING_CALLS dans ce groupe. Dans les versions précédentes d'Android, ces autorisations se trouvaient dans le groupe d'autorisations PHONE.

Ce groupe d'autorisations CALL_LOG offre aux utilisateurs un meilleur contrôle et une meilleure visibilité pour les applications qui ont besoin d'accéder à des informations sensibles sur les appels téléphoniques, telles que la lecture des enregistrements d'appels téléphoniques et l'identification des numéros de téléphone.

Si votre application a besoin d'accéder aux journaux d'appels ou doit traiter des appels sortants, vous devez demander explicitement ces autorisations au groupe d'autorisations CALL_LOG. Sinon, une erreur SecurityException se produit.

Remarque : Étant donné que ces autorisations ont changé de groupes et sont accordées au moment de l'exécution, il est possible pour l'utilisateur de refuser à votre application l'accès aux informations des journaux d'appels téléphoniques. Dans ce cas, votre application doit pouvoir gérer le manque d'accès aux informations de manière optimale.

Si votre application respecte déjà les bonnes pratiques pour les autorisations d'exécution, elle peut gérer la modification du groupe d'autorisations.

Restriction d'accès aux numéros de téléphone

Les applications exécutées sur Android 9 ne peuvent pas lire les numéros de téléphone ni l'état du téléphone sans avoir d'abord obtenir l'autorisation READ_CALL_LOG, en plus des autres autorisations requises par les cas d'utilisation de votre application.

Les numéros de téléphone associés aux appels entrants et sortants sont visibles dans la diffusion de l'état du téléphone, par exemple pour les appels entrants et sortants, et sont accessibles à partir de la classe PhoneStateListener. Toutefois, sans l'autorisation READ_CALL_LOG, le champ de numéro de téléphone fourni dans les diffusions PHONE_STATE_CHANGED et via PhoneStateListener est vide.

Pour lire les numéros de téléphone à partir de l'état du téléphone, mettez à jour votre application afin de demander les autorisations nécessaires en fonction de votre cas d'utilisation:

Accès limité aux informations de connexion et de localisation Wi-Fi

Sous Android 9, les exigences d'autorisation requises pour qu'une application effectue des recherches Wi-Fi sont plus strictes que dans les versions précédentes. Pour en savoir plus, consultez la section Restrictions concernant la recherche Wi-Fi.

Des restrictions similaires s'appliquent également à la méthode getConnectionInfo(), qui renvoie un objet WifiInfo décrivant la connexion Wi-Fi actuelle. Vous ne pouvez utiliser les méthodes de cet objet pour récupérer les valeurs SSID et BSSID que si l'application appelante dispose des autorisations suivantes:

  • ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION
  • ACCESS_WIFI_STATE

La récupération du SSID ou du BSSID nécessite également l'activation des services de localisation sur l'appareil (sous Paramètres > Emplacement).

Informations supprimées des méthodes de service Wi-Fi

Dans Android 9, les annonces et les événements suivants ne reçoivent pas d'informations sur la position de l'utilisateur ni de données permettant d'identifier personnellement l'utilisateur:

La diffusion du système NETWORK_STATE_CHANGED_ACTION à partir du Wi-Fi ne contient plus de SSID (anciennement EXTRA_SSID), de BSSID (anciennement EXTRA_BSSID) ni d'informations de connexion (anciennement EXTRA_NETWORK_INFO). Si votre application a besoin de ces informations, appelez plutôt getConnectionInfo().

Les informations de téléphonie dépendent désormais du paramètre de localisation de l'appareil

Si l'utilisateur a désactivé la localisation de l'appareil sur un appareil exécutant Android 9, les méthodes suivantes ne fournissent pas de résultats:

Restrictions concernant l'utilisation d'interfaces non SDK

Pour garantir la stabilité et la compatibilité des applications, la plate-forme limite l'utilisation de certains champs et méthodes non SDK. Ces restrictions s'appliquent que vous tentiez d'accéder directement à ces méthodes et champs, par réflexion ou à l'aide de JNI. Dans Android 9, votre application peut continuer à accéder à ces interfaces limitées. La plate-forme utilise des toasts et des entrées de journal pour vous les attirer. Si votre application affiche un tel toast, il est important d'adopter une stratégie d'implémentation autre que l'interface limitée. Si vous pensez qu'aucune autre stratégie n'est envisageable, vous pouvez signaler un bug afin de demander le réexamen de la restriction.

La section Restrictions sur les interfaces non SDK contient d'autres informations importantes. Vous devez l'examiner pour vous assurer que votre application continue de fonctionner correctement.

Modifications du comportement de sécurité

Modifications apportées à la sécurité des appareils

Android 9 ajoute plusieurs fonctionnalités qui renforcent la sécurité de votre application, quelle que soit la version ciblée par votre application.

Modifications apportées à l'implémentation de TLS

L'implémentation TLS du système a subi plusieurs modifications dans Android 9:

  • Si une instance de SSLSocket ne parvient pas à se connecter pendant sa création, le système génère une erreur IOException au lieu d'une NullPointerException.
  • La classe SSLEngine gère correctement les alertes close_notify qui se produisent.

Pour en savoir plus sur les requêtes Web sécurisées dans une application Android, consultez Un exemple HTTPS.

Filtre SECCOMP plus strict

Android 9 limite davantage les appels système disponibles pour les applications. Ce comportement est une extension du filtre SECCOMP inclus dans Android 8.0 (niveau d'API 26).

Modifications cryptographiques

Android 9 introduit plusieurs modifications dans l'implémentation et la gestion des algorithmes cryptographiques.

Conscrypter les implémentations de paramètres et d'algorithmes

Android 9 fournit des implémentations supplémentaires des paramètres d'algorithme dans Conscrypt. Ces paramètres incluent: AES, DESEDE, OAEP et EC. Les versions Bouncy Castle de ces paramètres et de nombreux algorithmes sont obsolètes depuis Android 9.

Si votre application cible Android 8.1 (niveau d'API 27) ou une version antérieure, vous recevez un avertissement lorsque vous demandez l'implémentation de Bouncy Castle de l'un de ces algorithmes obsolètes. Toutefois, si vous ciblez Android 9, ces requêtes génèrent chacune une exception NoSuchAlgorithmException.

Autres modifications

Android 9 introduit plusieurs autres modifications liées à la cryptographie:

  • Lorsque vous utilisez des clés PBE, si Bouncy Castle attend un vecteur d'initialisation (IV) et que votre application n'en fournit pas, vous recevez un avertissement.
  • L'implémentation Conscrypt de l'algorithme de chiffrement ARC4 vous permet de spécifier ARC4/ECB/NoPadding ou ARC4/NONE/NoPadding.
  • Le fournisseur JCA (Java Cryptography Architecture) Crypto a été supprimé. Par conséquent, si votre application appelle SecureRandom.getInstance("SHA1PRNG", "Crypto"), une exception NoSuchProviderException se produit.
  • Si votre application analyse des clés RSA à partir de tampons plus volumineux que la structure de clé, aucune exception ne se produit.

Pour en savoir plus sur l'utilisation des fonctionnalités cryptographiques d'Android, consultez la page Cryptographie.

Les fichiers chiffrés sécurisés sur Android ne sont plus pris en charge

Android 9 supprime complètement la prise en charge des fichiers chiffrés sécurisés (ASEC) Android.

Dans Android 2.2 (niveau d'API 8), Android a introduit les ASEC pour permettre la compatibilité des applications sur une carte SD. Sous Android 6.0 (niveau d'API 23), la plate-forme a introduit une technologie d'appareil de stockage adoptable que les développeurs peuvent utiliser à la place des ASEC.

Mises à jour des bibliothèques ICU

Android 9 utilise la version 60 de la bibliothèque ICU. Android 8.0 (niveau d'API 26) et Android 8.1 (niveau d'API 27) utilisent la bibliothèque ICU 58.

La bibliothèque ICU permet de fournir des API publiques sous android.icu package. Elle est utilisée en interne dans la plate-forme Android pour prendre en charge l'internationalisation. Par exemple, il permet d'implémenter des classes Android dans java.util, java.text et android.text.format.

La mise à jour d'ICU 60 contient de nombreuses modifications mineures, mais utiles, y compris la prise en charge des données Emoji 5.0 et l'amélioration des formats de date et d'heure, comme indiqué dans les notes de version ICU 59 et ICU 60.

Changements importants dans cette mise à jour:

  • La façon dont la plate-forme gère les fuseaux horaires a changé.
    • La plate-forme gère mieux les fuseaux GMT et UTC. UTC n'est plus un synonyme de GMT.

      La bibliothèque ICU fournit désormais des noms de zone traduits pour les fuseaux horaires GMT et UTC. Cette modification affecte la mise en forme et le comportement d'analyse de android.icu pour des zones telles que "GMT", "Etc/GMT", "UTC", "Etc/UTC" et "Zulu".

    • java.text.SimpleDateFormat utilise désormais la bibliothèque ICU pour fournir des noms à afficher pour le fuseau UTC /GMT, ce qui signifie que :
      • La mise en forme de zzzz génère une longue chaîne localisée pour de nombreux paramètres régionaux. Auparavant, il générait "UTC" pour l'UTC et des chaînes telles que "GMT+00:00" pour GMT.
      • L'analyse de zzzz reconnaît les chaînes telles que "Universal Coordinated Time" et "Greenwich Mean Time".
      • Les applications peuvent rencontrer des problèmes de compatibilité si elles supposent que "UTC" ou "GMT+00:00" s'affiche pour zzzz dans toutes les langues.
    • Le comportement de java.text.DateFormatSymbols.getZoneStrings() a changé :
      • Comme pour SimpleDateFormat, les codes UTC et GMT ont désormais des noms longs. Les variantes DST des noms de fuseau horaire pour le fuseau UTC, tels que "UTC", "Etc/UTC" et "Zulu", deviennent GMT+00:00, qui est la valeur de remplacement standard lorsqu'aucun nom n'est disponible, à la place de la chaîne codée en dur UTC.
      • Certains ID de zone sont correctement reconnus comme synonymes d'autres zones, de sorte qu'Android trouve des chaînes pour les ID de zone archaïques, telles que Eire, qui n'ont pas pu être résolues auparavant.
    • L'Asie/Hanoi n'est plus une zone reconnue. Pour cette raison, java.util.TimeZones.getAvailableIds() ne renvoie pas cette valeur, et java.util.TimeZone.getTimeZone() ne la reconnaît pas. Ce comportement est cohérent avec le comportement android.icu existant.
  • La méthode android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) peut générer une erreur ParseException même lors de l'analyse du texte de devise légitime. Pour éviter ce problème, utilisez NumberFormat.parseCurrency, disponible depuis Android 7.0 (niveau d'API 24), pour le texte de devise de style PLURALCURRENCYSTYLE.

Modifications apportées au test Android

Android 9 apporte plusieurs modifications à la bibliothèque et à la structure des classes du framework de test Android. Ces modifications aident les développeurs à utiliser des API publiques compatibles avec le framework, mais elles offrent également plus de flexibilité pour créer et exécuter des tests à l'aide de bibliothèques tierces ou d'une logique personnalisée.

Bibliothèques supprimées du framework

Android 9 réorganise les classes basées sur JUnit en trois bibliothèques : android.test.base, android.test.runner et android.test.mock. Cette modification vous permet d'exécuter des tests sur une version de JUnit qui fonctionne le mieux avec les dépendances de votre projet. Cette version de JUnit peut être différente de celle fournie par android.jar.

Pour en savoir plus sur l'organisation des classes basées sur JUnit dans ces bibliothèques et sur la préparation du projet de votre application pour l'écriture et l'exécution de tests, consultez la section Configurer un projet pour Android Test.

Modifications apportées à la compilation de la suite de tests

La méthode addRequirements() de la classe TestSuiteBuilder a été supprimée, et la classe TestSuiteBuilder elle-même est désormais obsolète. La méthode addRequirements() exigeait des développeurs qu'ils fournissent des arguments dont les types sont des API masquées, ce qui rend l'API non valide.

Décodeur UTF Java

UTF-8 est le jeu de caractères par défaut dans Android. Une séquence d'octets UTF-8 peut être décodée par un constructeur String tel que String(byte[] bytes).

Le décodeur UTF-8 d'Android 9 suit les normes Unicode plus strictement que dans les versions précédentes. Ces modifications incluent les suivantes:

  • La forme la plus courte d'UTF-8, telle que <C0, AF>, est traitée comme non valide.
  • La forme de substitution de l'encodage UTF-8, telle que U+D800..U+DFFF, est traitée comme non valide.
  • La sous-partie maximale est remplacée par une seule U+FFFD. Par exemple, dans la séquence d'octets "41 C0 AF 41 F4 80 80 41", les sous-parties maximales sont "C0", "AF" et "F4 80 80". "F4 80 80" peut être la sous-séquence initiale de "F4 80 80 80", mais "C0" ne peut pas être la sous-séquence initiale d'une séquence d'unités de code correctement formatée. Le résultat doit donc être "A\ufffd\ufffdA\ufffdA".
  • Pour décoder une séquence UTF-8 / CESU-8 modifiée sous Android 9 ou version ultérieure, utilisez la méthode DataInputStream.readUTF() ou la méthode JNI NewStringUTF().

Validation du nom d'hôte à l'aide d'un certificat

Le document RFC 2818 décrit deux méthodes permettant de mettre en correspondance un nom de domaine avec un certificat : l'utilisation des noms disponibles dans l'extension subjectAltName (SAN) ou, en l'absence d'une extension SAN, le recours à commonName (CN).

Cependant, le remplacement du CN a été abandonné dans le document RFC 2818. Pour cette raison, Android ne revient plus à utiliser CN. Pour vérifier un nom d'hôte, le serveur doit présenter un certificat avec un SAN correspondant. Les certificats qui ne contiennent pas de SAN correspondant au nom d'hôte ne sont plus approuvés.

La recherche d'adresses réseau peut entraîner des violations du réseau

Les recherches d'adresses réseau nécessitant une résolution de nom peuvent impliquer les E/S réseau et sont donc considérées comme des opérations bloquantes. Les opérations de blocage sur le thread principal peuvent entraîner des pauses ou des à-coups.

La classe StrictMode est un outil de développement qui aide les développeurs à détecter les problèmes dans leur code.

Dans Android 9 et versions ultérieures, StrictMode détecte les violations de réseau causées par les recherches d'adresses réseau nécessitant une résolution de nom.

Vous ne devez pas distribuer vos applications lorsque StrictMode est activé. Dans ce cas, vos applications peuvent rencontrer des exceptions, telles que NetworkOnMainThreadException, lors de l'utilisation des méthodes detectNetwork() ou detectAll() pour obtenir une règle qui détecte les violations du réseau.

La résolution d'une adresse IP numérique n'est pas considérée comme une opération bloquante. La résolution d'adresse IP numérique fonctionne de la même manière que dans les versions antérieures à Android 9.

Taggage de sockets

Dans les versions de plate-forme antérieures à Android 9, si un socket est tagué à l'aide de la méthode setThreadStatsTag(), il n'est pas tagué lorsqu'il est envoyé à un autre processus à l'aide de l'IPC de liaison avec un conteneur ParcelFileDescriptor.

Sous Android 9 et versions ultérieures, le tag de socket est conservé lorsqu'il est envoyé à un autre processus à l'aide de l'IPC de liaison. Cette modification peut affecter les statistiques de trafic réseau, par exemple lorsque vous utilisez la méthode queryDetailsForUidTag().

Si vous souhaitez conserver le comportement des versions précédentes, qui suppriment le balisage d'un socket envoyé à un autre processus, vous pouvez appeler untagSocket() avant d'envoyer le socket.

Quantité indiquée d'octets disponibles dans le socket

La méthode available() renvoie 0 lorsqu'elle est appelée après avoir appelé la méthode shutdownInput().

Rapports plus détaillés sur les capacités réseau pour les VPN

Sous Android 8.1 (niveau d'API 27) ou version antérieure, la classe NetworkCapabilities n'a signalé qu'un ensemble limité d'informations pour les VPN, comme TRANSPORT_VPN, en omettant NET_CAPABILITY_NOT_VPN. En raison de ces informations limitées, il était difficile de déterminer si l'utilisation d'un VPN entraînerait des frais pour l'utilisateur de l'application. Par exemple, vérifier NET_CAPABILITY_NOT_METERED ne permet pas de déterminer si les réseaux sous-jacents étaient facturés à l'usage ou non.

Dans Android 9 et versions ultérieures, lorsqu'un VPN appelle la méthode setUnderlyingNetworks(), le système Android fusionne les transports et les capacités de tous les réseaux sous-jacents et renvoie le résultat en tant que capacités réseau effectives du réseau VPN.

Sur Android 9 ou version ultérieure, les applications qui recherchent déjà NET_CAPABILITY_NOT_METERED reçoivent les capacités réseau du VPN et des réseaux sous-jacents.

Les fichiers du dossier xt_qtaguid ne sont plus disponibles pour les applis

À partir d'Android 9, les applications ne sont pas autorisées à accéder directement en lecture aux fichiers du dossier /proc/net/xt_qtaguid. L'objectif est d'assurer la cohérence avec certains appareils qui ne disposent pas du tout de ces fichiers.

Les API publiques qui s'appuient sur ces fichiers, TrafficStats et NetworkStatsManager, continuent de fonctionner comme prévu. Toutefois, les fonctions cutils non compatibles, telles que qtaguid_tagSocket(), peuvent ne pas fonctionner comme prévu, voire pas du tout, sur différents appareils.

La condition FLAG_ACTIVITY_NEW_TASK est désormais appliquée.

Avec Android 9, vous ne pouvez pas démarrer une activité à partir d'un contexte autre qu'une activité, sauf si vous transmettez l'indicateur d'intent FLAG_ACTIVITY_NEW_TASK. Si vous tentez de démarrer une activité sans transmettre cet indicateur, l'activité ne démarre pas et le système imprime un message dans le journal.

Modifications apportées à la rotation de l'écran

À partir d'Android 9, des modifications importantes ont été apportées au mode de rotation portrait. Sous Android 8.0 (niveau d'API 26), les utilisateurs pouvaient basculer entre les modes rotation automatique et portrait à l'aide d'une tuile ou des paramètres d'affichage Quicksettings. Le mode Portrait a été renommé verrouillage de la rotation. Il est actif lorsque la rotation automatique est désactivée. Le mode de rotation automatique n'est pas modifié.

Lorsque l'appareil est en mode de verrouillage pour la rotation, les utilisateurs peuvent verrouiller leur écran sur n'importe quelle rotation compatible avec l'activité visible supérieure. Une activité ne doit pas partir du principe qu'elle sera toujours affichée en mode portrait. Si l'activité principale peut être affichée dans plusieurs rotations en mode Rotation automatique, les mêmes options doivent être disponibles en mode verrouillé pour la rotation, à quelques exceptions près selon le paramètre screenOrientation de l'activité (voir le tableau ci-dessous).

Les activités qui demandent une orientation spécifique (par exemple, screenOrientation=landscape) ignorent la préférence de verrouillage de l'utilisateur et se comportent de la même manière que dans Android 8.0.

La préférence d'orientation de l'écran peut être définie au niveau de l'activité dans le fichier manifeste Android, ou de manière programmatique avec setRequestedOrientation().

Le mode de verrouillage de la rotation définit la préférence de rotation de l'utilisateur que le WindowManager utilise pour gérer la rotation des activités. La préférence de rotation des utilisateurs peut être modifiée dans les cas suivants. Notez que le retour à la rotation naturelle de l'appareil, qui est normalement portrait pour les appareils ayant un facteur de forme de téléphone, est biaisé:

  • Lorsque l'utilisateur accepte une suggestion de rotation, la préférence de rotation change pour la suggestion.
  • Lorsque l'utilisateur passe à une application en mode portrait forcée (y compris l'écran de verrouillage ou le lanceur d'applications), la préférence de rotation passe en mode portrait.

Le tableau suivant récapitule le comportement de rotation pour les orientations courantes de l'écran:

Orientation de l'écran Comportement
non spécifié, utilisateur Lorsque la rotation automatique et le verrouillage de la rotation sont activés, l'activité peut s'afficher en mode portrait ou paysage (et inversement). Attendez-vous à être compatible avec les mises en page en mode portrait et paysage.
utilisateurLandscape Lorsque la rotation automatique et le verrouillage de la rotation sont activés, l'activité peut s'afficher en mode paysage ou paysage inversé. Attendez-vous à ce que seules les mises en page en mode paysage soient acceptées.
utilisateurPortrait En cas de rotation automatique et de verrouillage de la rotation, l'activité peut s'afficher en mode portrait ou portrait inversé. Attendez-vous à ne prendre en charge que les mises en page en mode portrait.
Utilisateur complet Lorsque la rotation automatique et le verrouillage de la rotation sont activés, l'activité peut s'afficher en mode portrait ou paysage (et inversement). Attendez-vous à accepter les mises en page en mode portrait et paysage.

Les utilisateurs du verrouillage de la rotation auront la possibilité de verrouiller le mode portrait inversé (souvent à 180o).
capteur, fullSensor, capteurPortrait, sensorLandscape La préférence pour le mode de verrouillage de la rotation est ignorée et traitée comme si la rotation automatique était active. N'utilisez cette méthode que dans des circonstances exceptionnelles, en accordant une attention toute particulière à l'expérience utilisateur.

L'abandon du client HTTP Apache affecte les applications avec ClassLoader non standard

Avec Android 6.0, nous avons supprimé la prise en charge du client HTTP Apache. Cette modification n'a aucun effet sur la grande majorité des applications qui ne ciblent pas Android 9 ou une version ultérieure. Toutefois, ce changement peut affecter certaines applications qui utilisent une structure ClassLoader non standard, même si elles ne ciblent pas Android 9 ou une version ultérieure.

Une application peut être affectée si elle utilise un ClassLoader non standard qui délègue explicitement l'ClassLoader du système. Ces applications doivent déléguer à l'application ClassLoader à la place lorsqu'elles recherchent des classes dans org.apache.http.*. S'il délègue à l'ClassLoader système, les applications échoueront sur Android 9 ou version ultérieure avec une NoClassDefFoundError, car ces classes ne sont plus connues du ClassLoader du système. Pour éviter des problèmes similaires à l'avenir, les applications doivent généralement charger les classes via l'application ClassLoader plutôt que d'accéder directement au ClassLoader du système.

Énumération des caméras

Les applications exécutées sur les appareils Android 9 peuvent détecter toutes les caméras disponibles en appelant getCameraIdList(). Une application ne doit pas supposer que l'appareil n'a qu'une seule caméra arrière ou une seule caméra avant.

Par exemple, si votre application dispose d'un bouton permettant de basculer entre les caméras avant et arrière, vous pouvez choisir parmi plusieurs caméras avant ou arrière. Vous devez parcourir la liste des caméras, examiner les caractéristiques de chaque caméra et choisir celles que l'utilisateur pourra voir.