Changements de comportement : toutes les applications

Android 9 (niveau d'API 28) introduit un certain nombre de modifications dans le 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 la section 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 de l'appareil. Ces modifications, ainsi que les fonctionnalités déjà présentes avant Android 9, permettent de s'assurer 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 apportées à la confidentialité

Pour améliorer la confidentialité des utilisateurs, Android 9 introduit plusieurs modifications de comportement, telles 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 analyses Wi-Fi, ainsi que de nouvelles règles et groupes d'autorisations liées aux appels téléphoniques, à l'état du téléphone et aux analyses Wi-Fi.

Ces modifications affectent toutes les applications exécutées sur 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 donné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 à la caméra.
  • Les capteurs qui utilisent le mode de reporting continu, tels que les accéléromètres et les gyroscopes, ne reçoivent pas d'événements.
  • Les capteurs qui utilisent les modes de création de rapports à chaque modification ou à usage unique ne reçoivent pas d'événements.

Si votre application doit détecter des événements de capteur sur des appareils exécutant 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é sur 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 nécessite l'accès aux journaux d'appels ou doit traiter les appels sortants, vous devez demander explicitement ces autorisations au groupe d'autorisations CALL_LOG. Sinon, une exception SecurityException se produit.

Remarque : Étant donné que ces autorisations ont changé de groupe et sont accordées au moment de l'exécution, l'utilisateur peut refuser à votre application l'accès aux informations des journaux d'appels téléphoniques. Dans ce cas, votre application doit pouvoir gérer correctement l'absence d'accès aux informations.

Si votre application suit déjà les bonnes pratiques en matière d'autorisations d'exécution, elle peut gérer le changement de groupe d'autorisations.

Accès aux numéros de téléphone limité

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 d'abord acquérir 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 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 pour demander les autorisations nécessaires en fonction de votre cas d'utilisation:

Restriction d'accès aux informations de connexion et de localisation Wi-Fi

Sous Android 9, les exigences d'autorisation 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 de numérisation 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 que pour récupérer les valeurs SSID et BSSID si l'application appelante dispose des autorisations suivantes:

  • ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION
  • ACCESS_WIFI_STATE

Pour récupérer le SSID ou le BSSID, les services de localisation doivent également être activés sur l'appareil (sous Paramètres > Position).

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

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

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

Les informations sur la 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 donnent pas de résultats:

Restrictions concernant l'utilisation d'interfaces non SDK

Pour assurer la stabilité et la compatibilité des applications, la plate-forme limite l'utilisation de certaines méthodes et champs autres que SDK. Ces restrictions s'appliquent que vous essayiez d'accéder à ces méthodes et champs directement, via la réflexion ou à l'aide de JNI. Sous 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 les porter à votre attention. Si votre application affiche un tel toast, il est important que vous suiviez 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 pour demander un nouvel examen de la restriction.

Restrictions concernant 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é de l'appareil

Android 9 ajoute plusieurs fonctionnalités qui améliorent la sécurité de votre application, quelle que soit la version qu'elle cible.

Modifications apportées à l'implémentation du protocole 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 lors de sa création, le système génère une exception IOException au lieu d'une exception NullPointerException.
  • La classe SSLEngine gère de manière claire toutes les alertes close_notify qui se produisent.

Pour en savoir plus sur l'envoi de requêtes Web sécurisées dans une application Android, consultez 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 apportées à la cryptographie

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

Implémentations de paramètres et d'algorithmes Conscrypt

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 version antérieure, vous recevez un avertissement lorsque vous demandez l'implémentation Bouncy Castle de l'un de ces algorithmes obsolètes. Toutefois, si vous ciblez Android 9, chacune de ces requêtes génère 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 du 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"), un 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 section Cryptographie.

Les fichiers chiffrés sécurisés Android ne sont plus acceptés

Android 9 supprime complètement la prise en charge des fichiers Android Secure Encrypted (ASEC).

Dans Android 2.2 (niveau d'API 8), Android a introduit les ASEC pour prendre en charge la fonctionnalité d'applications sur carte SD. Sur 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 ICU 58.

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

La mise à jour vers ICU 60 contient de nombreux petits changements, mais utiles, y compris la prise en charge des données Emoji 5.0 et l'amélioration des formats de date/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 le format GMT et UTC. UTC n'est plus synonyme de GMT.

      ICU fournit désormais des noms de fuseaux traduits pour GMT et UTC. Cette modification affecte le formatage et le comportement d'analyse de android.icu pour les zones telles que "GMT", "Etc/GMT", "UTC", "Etc/UTC" et "Zulu".

    • java.text.SimpleDateFormat utilise désormais ICU pour fournir des noms à afficher pour UTC /GMT, ce qui signifie :
      • La mise en forme de zzzz génère une longue chaîne localisée pour de nombreux paramètres régionaux. Auparavant, il produisait "UTC" pour UTC et des chaînes telles que "GMT+00:00" pour GMT.
      • L'analyse zzzz reconnaît des chaînes telles que "Temps universel coordonné" et "Heure moyenne de Greenwich".
      • Les applications peuvent rencontrer des problèmes de compatibilité si elles supposent que "UTC" ou "GMT+00:00" sont affichés pour zzzz dans toutes les langues.
    • Le comportement de java.text.DateFormatSymbols.getZoneStrings() a changé :
      • Comme pour SimpleDateFormat, UTC et GMT ont désormais des noms longs. Les variantes d'heure d'été des noms de fuseau horaire pour la zone UTC, telles que "UTC", "Etc/UTC" et "Zulu", deviennent GMT+00:00, qui est le paramètre par défaut lorsque aucun nom n'est disponible, plutôt que 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, tels que Eire, qui ne pouvaient pas être résolus auparavant.
    • Asia/Hanoi n'est plus une zone reconnue. C'est pourquoi java.util.TimeZones.getAvailableIds() ne renvoie pas cette valeur et que java.util.TimeZone.getTimeZone() ne la reconnaît pas. Ce comportement est cohérent avec le comportement existant de android.icu.
  • La méthode android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) peut générer une 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 aux tests Android

Android 9 apporte plusieurs modifications à la bibliothèque et à la structure de classe du framework Android Test. Ces modifications aident les développeurs à utiliser des API publiques compatibles avec le framework, mais elles permettent également de créer et d'exécuter des tests plus facilement à l'aide de bibliothèques tierces ou de 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, ainsi que sur la préparation du projet de votre application pour écrire et exécuter des tests, consultez Configurer un projet pour Android Test.

Modifications de 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 a été abandonnée. La méthode addRequirements() obligeait les développeurs à fournir des arguments dont les types sont des API masquées, ce qui rendait l'API non valide.

Décodeur UTF Java

UTF-8 est le jeu de caractères par défaut d'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. Voici quelques exemples de modifications:

  • La forme non la plus courte d'UTF-8, telle que <C0, AF>, est considérée comme mal formée.
  • La forme de substitution d'UTF-8, telle que U+D800..U+DFFF, est considérée comme mal formée.
  • La sous-partie maximale est remplacée par un seul 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 de toute séquence d'unités de code valide. Le résultat doit donc être "A\ufffd\ufffdA\ufffdA".
  • Pour décoder une séquence UTF-8 / CESU-8 modifiée dans 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

La RFC 2818 décrit deux méthodes permettant de faire correspondre un nom de domaine à un certificat : en utilisant les noms disponibles dans l'extension subjectAltName (SAN) ou, en l'absence d'extension SAN, en recourant à commonName (CN).

Toutefois, le recours à CN a été abandonné dans la RFC 2818. Pour cette raison, Android n'utilise plus CN par défaut. Pour valider 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.

Les recherches d'adresses réseau peuvent entraîner des cas de non-respect du réseau

Les recherches d'adresses réseau nécessitant une résolution de nom peuvent impliquer des E/S réseau et sont donc considérées comme des opérations bloquantes. Les opérations bloquantes 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.

Sous Android 9 et versions ultérieures, StrictMode détecte les cas de non-respect des règles réseau causés par les recherches d'adresses réseau nécessitant une résolution de nom.

Vous ne devez pas distribuer vos applications avec StrictMode activé. Si vous le faites, vos applications peuvent rencontrer des exceptions, telles que NetworkOnMainThreadException lorsque vous utilisez les méthodes detectNetwork() ou detectAll() pour obtenir une stratégie qui détecte les cas de non-respect du réseau.

La résolution d'une adresse IP numérique n'est pas considérée comme une opération de blocage. 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 socket

Dans les versions de plate-forme antérieures à Android 9, si un socket est tagué à l'aide de la méthode setThreadStatsTag(), il est déstagué 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, la balise de socket est conservée lorsqu'elle est envoyée à 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 supprime le tag d'un socket envoyé à un autre processus, vous pouvez appeler untagSocket() avant d'envoyer le socket.

Nombre d'octets disponibles dans le socket

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

Rapports plus détaillés sur les fonctionnalités réseau des VPN

Sous Android 8.1 (niveau d'API 27) ou version antérieure, la classe NetworkCapabilities ne signalait qu'un ensemble limité d'informations pour les VPN, comme TRANSPORT_VPN, mais en omettant NET_CAPABILITY_NOT_VPN. Ces informations limitées rendaient difficile de déterminer si l'utilisation d'un VPN entraînerait des frais pour l'utilisateur de l'application. Par exemple, la vérification de NET_CAPABILITY_NOT_METERED ne permet pas de déterminer si les réseaux sous-jacents sont facturés ou non.

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

Sous Android 9 et versions ultérieures, les applications qui vérifient déjà NET_CAPABILITY_NOT_METERED reçoivent les fonctionnalités réseau du VPN et des réseaux sous-jacents.

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

À partir d'Android 9, les applications ne sont plus autorisées à disposer d'un accès en lecture direct aux fichiers du dossier /proc/net/xt_qtaguid. Cela permet de garantir 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(), risquent de ne pas fonctionner comme prévu, voire de ne pas fonctionner du tout, sur différents appareils.

L'exigence FLAG_ACTIVITY_NEW_TASK est désormais appliquée

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

Modifications de la rotation de l'écran

À partir d'Android 9, le mode de rotation portrait a subi des modifications importantes. Dans Android 8.0 (niveau d'API 26), les utilisateurs pouvaient basculer entre les modes de rotation Auto-rotation (Rotation automatique) et Portrait à l'aide d'une carte Quicksettings ou des paramètres d'affichage. Le mode portrait a été renommé Verrouillage de l'orientation et est actif lorsque la rotation automatique est désactivée. Le mode rotation automatique n'est pas modifié.

Lorsque l'appareil est en mode verrouillage de la rotation, les utilisateurs peuvent verrouiller leur écran sur n'importe quelle rotation compatible avec l'activité visible en haut. Une activité ne doit pas supposer qu'elle sera toujours affichée en mode portrait. Si l'activité supérieure peut être affichée en plusieurs rotations en mode rotation automatique, les mêmes options doivent être disponibles en mode rotation verrouillée, à quelques exceptions près en fonction du 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 qu'en 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 fonctionne en définissant la préférence de rotation de l'utilisateur que WindowManager utilise pour gérer la rotation de l'activité. La préférence de rotation de l'utilisateur peut être modifiée dans les cas suivants. Notez qu'il existe un biais de retour à l'orientation naturelle de l'appareil, qui est normalement le mode portrait pour les appareils au format téléphone:

  • Lorsque l'utilisateur accepte une suggestion de rotation, la préférence de rotation est remplacée par la suggestion.
  • Lorsque l'utilisateur passe à une application en mode portrait forcé (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 d'écran courantes:

Orientation de l'écran Comportement
non spécifié, utilisateur En mode rotation automatique et verrouillage de la rotation, l'activité peut être affichée en mode portrait ou paysage (et inversement). Prévoyez de prendre en charge les mises en page en mode portrait et paysage.
userLandscape En mode rotation automatique et verrouillage de la rotation, l'activité peut être affichée en mode paysage ou en mode paysage inversé. Ne comptez pas sur la prise en charge des mises en page en mode paysage.
userPortrait En mode rotation automatique et verrouillage de la rotation, l'activité peut être affichée en mode portrait ou en mode portrait inversé. Ne comptez pas sur la prise en charge d'autres orientations que le portrait.
fullUser En mode rotation automatique et verrouillage de la rotation, l'activité peut être affichée en mode portrait ou paysage (et inversement). Vous devrez prendre en charge les formats portrait et paysage.

Les utilisateurs du verrouillage de rotation auront la possibilité de verrouiller l'écran en mode portrait inversé, souvent à 180 degrés.
sensor, fullSensor, sensorPortrait, sensorLandscape La préférence de mode de verrouillage de la rotation est ignorée et est traitée comme si la rotation automatique était active. N'utilisez cette fonctionnalité que dans des cas exceptionnels et en tenant compte de l'expérience utilisateur.

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

Avec Android 6.0, nous avons supprimé la prise en charge du client HTTP Apache. Ce changement n'a aucun effet sur la grande majorité des applications qui ne ciblent pas Android 9 ou 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 version ultérieure.

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

Énumérer les caméras

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

Par exemple, si votre application comporte un bouton permettant de basculer entre les caméras avant et arrière, il est possible qu'il existe plusieurs caméras avant ou arrière parmi lesquelles choisir. Vous devez parcourir la liste des caméras, examiner les caractéristiques de chacune d'elles et décider des caméras à exposer à l'utilisateur.