Nouveautés Android 6.0

En plus de nouvelles fonctionnalités, Android 6.0 (niveau d'API 23) inclut diverses modifications du système et du comportement des API. Ce document met en évidence certaines des principales modifications que vous devez comprendre et prendre en compte dans vos applications.

Si vous avez déjà publié une application pour Android, sachez que ces modifications de la plate-forme affectent votre application.

Autorisations d'exécution

Cette version introduit un nouveau modèle d'autorisations, qui permet aux utilisateurs de gérer directement les autorisations des applications au moment de l'exécution. Ce modèle offre aux utilisateurs une meilleure visibilité et un meilleur contrôle sur les autorisations, tout en simplifiant les processus d'installation et de mise à jour automatique pour les développeurs d'applications. Les utilisateurs peuvent accorder ou révoquer des autorisations individuellement pour les applications installées.

Dans vos applications qui ciblent Android 6.0 (niveau d'API 23) ou version ultérieure, veillez à vérifier et à demander les autorisations au moment de l'exécution. Pour déterminer si une autorisation a été accordée à votre application, appelez la nouvelle méthode checkSelfPermission(). Pour demander une autorisation, appelez la nouvelle méthode requestPermissions(). Même si votre application ne cible pas Android 6.0 (niveau d'API 23), vous devez la tester avec le nouveau modèle d'autorisations.

Pour savoir comment prendre en charge le nouveau modèle d'autorisations dans votre application, consultez la section Utiliser des autorisations système. Pour savoir comment évaluer l'impact sur votre application, consultez les Notes sur l'utilisation des autorisations.

Sommeil et Mise en veille des applications

Cette version introduit de nouvelles optimisations d'économie d'énergie pour les appareils et les applications inactifs. Ces fonctionnalités affectent toutes les applications. Veillez donc à les tester dans ces nouveaux modes.

  • Sommeil : si un utilisateur débranche un appareil et le laisse immobile, avec son écran éteint, pendant un certain temps, l'appareil passe en mode Sommeil, où il tente de maintenir le système en veille. Dans ce mode, les appareils reprennent périodiquement les opérations normales pendant de courtes périodes afin que la synchronisation des applications puisse avoir lieu et que le système puisse effectuer les opérations en attente.
  • Mode veille de l'application : le mode veille de l'application permet au système de déterminer qu'une application est inactive lorsque l'utilisateur ne l'utilise pas activement. Le système prend cette décision lorsque l'utilisateur ne touche pas l'application pendant un certain temps. Si l'appareil est débranché, le système désactive l'accès au réseau et suspend les synchronisations et les tâches pour les applications qu'il considère inactives.

Pour en savoir plus sur ces changements d'économie d'énergie, consultez Optimiser pour les fonctionnalités Sommeil et Mise en veille des applications.

Suppression du client HTTP Apache

La version Android 6.0 ne prend plus en charge le client HTTP Apache. Si votre application utilise ce client et cible Android 2.3 (niveau d'API 9) ou version ultérieure, utilisez plutôt la classe HttpURLConnection. Cette API est plus efficace, car elle réduit l'utilisation du réseau grâce à une compression transparente et à la mise en cache des réponses, et réduit la consommation d'énergie. Pour continuer à utiliser les API HTTP Apache, vous devez d'abord déclarer la dépendance au moment de la compilation suivante dans votre fichier build.gradle: 

android {
    useLibrary 'org.apache.http.legacy'
}

BoringSSL

Android abandonne OpenSSL pour la bibliothèque BoringSSL. Si vous utilisez le NDK Android dans votre application, n'associez pas vos scripts de compilation à des bibliothèques cryptographiques qui ne font pas partie de l'API NDK, telles que libcrypto.so et libssl.so. Ces bibliothèques ne sont pas des API publiques et peuvent changer ou ne plus fonctionner sans préavis entre les versions et les appareils. De plus, vous vous exposez à des failles de sécurité. Modifiez plutôt votre code natif pour appeler les API de cryptographie Java via JNI ou pour établir un lien statique avec une bibliothèque de cryptographie de votre choix.

Accès à l'identifiant matériel

Pour offrir aux utilisateurs une meilleure protection des données, à partir de cette version, Android supprime l'accès programmatique à l'identifiant matériel local de l'appareil pour les applications qui utilisent les API Wi-Fi et Bluetooth. Les méthodes WifiInfo.getMacAddress() et BluetoothAdapter.getAddress() renvoient désormais une valeur constante de 02:00:00:00:00:00.

Pour accéder aux identifiants matériels des appareils externes à proximité via des analyses Bluetooth et Wi-Fi, votre application doit désormais disposer des autorisations ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION:

Remarque : Lorsqu'un appareil équipé d'Android 6.0 (niveau d'API 23) lance une analyse Wi-Fi ou Bluetooth en arrière-plan, l'opération est visible par les appareils externes comme provenant d'une adresse MAC aléatoire.

Notifications

Cette version supprime la méthode Notification.setLatestEventInfo(). Utilisez plutôt la classe Notification.Builder pour créer des notifications. Pour mettre à jour une notification à plusieurs reprises, réutilisez l'instance Notification.Builder. Appelez la méthode build() pour obtenir les instances Notification mises à jour.

La commande adb shell dumpsys notification n'affiche plus le texte de votre notification. Utilisez plutôt la commande adb shell dumpsys notification --noredact pour imprimer le texte dans un objet de notification.

Modifications apportées à AudioManager

Il n'est plus possible de régler le volume directement ou de couper le son de flux spécifiques via la classe AudioManager. La méthode setStreamSolo() est obsolète. Vous devez appeler la méthode requestAudioFocus() à la place. De même, la méthode setStreamMute() est obsolète. Appelez plutôt la méthode adjustStreamVolume() et transmettez la valeur de direction ADJUST_MUTE ou ADJUST_UNMUTE.

Sélection de texte

Écran montrant les nouvelles fonctionnalités de sélection de texte dans une barre d'outils flottante

Lorsque les utilisateurs sélectionnent du texte dans votre application, vous pouvez désormais afficher des actions de sélection de texte telles que Couper, Copier et Coller dans une barre d'outils flottante. L'implémentation de l'interaction utilisateur est semblable à celle de la barre d'action contextuelle, comme décrit dans la section Activer le mode d'action contextuelle pour des vues individuelles.

Pour implémenter une barre d'outils flottante pour la sélection de texte, apportez les modifications suivantes dans vos applications existantes :

  1. Dans votre objet View ou Activity, faites passer vos appels ActionMode de startActionMode(Callback) à startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Utilisez votre implémentation existante de ActionMode.Callback et étendez ActionMode.Callback2 à la place.
  3. Remplacez la méthode onGetContentRect() pour fournir les coordonnées de l'objet Rect de contenu (par exemple, un rectangle de sélection de texte) dans la vue.
  4. Si le positionnement du rectangle n'est plus valide et qu'il s'agit du seul élément à être invalidé, appelez la méthode invalidateContentRect().

Si vous utilisez la version 22.2 de la bibliothèque Android Support, sachez que les barres d'outils flottantes ne sont pas rétrocompatibles et que appcompat contrôle les objets ActionMode par défaut. Cela empêche l'affichage des barres d'outils flottantes. Pour activer la prise en charge de ActionMode dans un AppCompatActivity, appelez getDelegate(), puis appelez setHandleNativeActionModesEnabled() sur l'objet AppCompatDelegate renvoyé et définissez le paramètre d'entrée sur false. Cet appel renvoie le contrôle des objets ActionMode au framework. Sur les appareils équipés d'Android 6.0 (niveau d'API 23), le framework est compatible avec les modes ActionBar ou barre d'outils flottante, tandis que sur les appareils équipés d'Android 5.1 (niveau d'API 22) ou version antérieure, seuls les modes ActionBar sont compatibles.

Modifications apportées aux favoris du navigateur

Cette version ne prend plus en charge les favoris globaux. Les méthodes android.provider.Browser.getAllBookmarks() et android.provider.Browser.saveBookmark() sont désormais supprimées. De même, les autorisations READ_HISTORY_BOOKMARKS et WRITE_HISTORY_BOOKMARKS sont supprimées. Si votre application cible Android 6.0 (niveau d'API 23) ou une version ultérieure, n'accédez pas aux favoris du fournisseur global ni n'utilisez les autorisations de favoris. À la place, votre application doit stocker les données des favoris en interne.

Modifications apportées à Android Keystore

Avec cette version, le fournisseur Android Keystore ne prend plus en charge DSA. ECDSA est toujours compatible.

Les clés qui ne nécessitent pas de chiffrement au repos ne seront plus supprimées lorsque l'écran de verrouillage sécurisé sera désactivé ou réinitialisé (par exemple, par l'utilisateur ou un administrateur de l'appareil). Les clés nécessitant un chiffrement au repos seront supprimées lors de ces événements.

Modifications apportées au Wi-Fi et au réseau

Cette version introduit les modifications de comportement suivantes pour les API Wi-Fi et réseau.

  • Vos applications ne peuvent désormais modifier l'état des objets WifiConfiguration que si vous les avez créés. Vous n'êtes pas autorisé à modifier ni à supprimer les objets WifiConfiguration créés par l'utilisateur ou par d'autres applications.
  • Auparavant, si une application forçait l'appareil à se connecter à un réseau Wi-Fi spécifique en utilisant enableNetwork() avec le paramètre disableAllOthers=true, l'appareil se déconnectait des autres réseaux, tels que les données mobiles. Dans cette version, l'appareil ne se déconnecte plus de ces autres réseaux. Si la valeur targetSdkVersion de votre application est “20” ou inférieure, elle est épinglée au réseau Wi-Fi sélectionné. Si la version targetSdkVersion de votre application est “21” ou supérieure, utilisez les API multiréseaux (telles que openConnection(), bindSocket() et la nouvelle méthode bindProcessToNetwork()) pour vous assurer que son trafic réseau est envoyé sur le réseau sélectionné.

Modifications apportées au service de caméra

Dans cette version, le modèle d'accès aux ressources partagées du service de caméra n'est plus le modèle d'accès "premier arrivé, premier servi", mais dans lequel les processus à priorité élevée sont privilégiés. Voici quelques-unes des modifications apportées au comportement du service:

  • L'accès aux ressources du sous-système de l'appareil photo, y compris l'ouverture et la configuration d'un appareil photo, est attribué en fonction de la "priorité" du processus d'application cliente. Les processus d'application avec des activités visibles par l'utilisateur ou au premier plan se voient généralement attribuer une priorité plus élevée, ce qui rend l'acquisition et l'utilisation des ressources de l'appareil photo plus fiables.
  • Les clients d'appareil photo actifs pour les applications de priorité inférieure peuvent être "expulsés" lorsqu'une application de priorité supérieure tente d'utiliser l'appareil photo. Dans l'API Camera obsolète, onError() est appelé pour le client éjecté. Dans l'API Camera2, onDisconnected() est appelé pour le client éjecté.
  • Sur les appareils dotés d'un matériel d'appareil photo approprié, des processus d'application distincts peuvent ouvrir et utiliser simultanément des appareils photo distincts de manière indépendante. Toutefois, les cas d'utilisation multiprocessus, où l'accès simultané entraîne une dégradation importante des performances ou des fonctionnalités de l'un des appareils photo ouverts, sont désormais détectés et refusés par le service de caméra. Ce changement peut entraîner des "évictions" pour les clients de priorité inférieure, même si aucune autre application ne tente directement d'accéder au même appareil photo.
  • Modifier l'utilisateur actuel entraîne l'éviction des clients de caméra actifs dans les applications appartenant au compte utilisateur précédent. L'accès à l'appareil photo est limité aux profils utilisateur appartenant à l'utilisateur actuel de l'appareil. En pratique, cela signifie qu'un compte "Invité", par exemple, ne pourra pas laisser les processus en cours d'exécution qui utilisent le sous-système de la caméra lorsque l'utilisateur est passé à un autre compte.

Runtime

L'environnement d'exécution ART implémente désormais correctement les règles d'accès pour la méthode newInstance(). Cette modification résout un problème qui empêchait Dalvik de vérifier correctement les règles d'accès dans les versions précédentes. Si votre application utilise la méthode newInstance() et que vous souhaitez remplacer les vérifications d'accès, appelez la méthode setAccessible() avec le paramètre d'entrée défini sur true. Si votre application utilise la bibliothèque appcompat v7 ou la bibliothèque recyclerview v7, vous devez la mettre à jour pour qu'elle utilise les dernières versions de ces bibliothèques. Dans le cas contraire, assurez-vous que toutes les classes personnalisées référencées à partir du fichier XML sont mises à jour afin que leurs constructeurs de classe soient accessibles.

Cette version met à jour le comportement de l'éditeur de liens dynamique. Le liant dynamique comprend désormais la différence entre le soname d'une bibliothèque et son chemin d'accès (bug public 6670), et la recherche par soname est désormais implémentée. Les applications qui fonctionnaient auparavant et qui comportent des entrées DT_NEEDED incorrectes (généralement des chemins absolus sur le système de fichiers de la machine de compilation) peuvent échouer lors du chargement.

L'indicateur dlopen(3) RTLD_LOCAL est maintenant correctement implémenté. Notez que RTLD_LOCAL est la valeur par défaut. Les appels à dlopen(3) qui n'utilisent pas explicitement RTLD_LOCAL seront donc affectés (sauf si votre application utilise explicitement RTLD_GLOBAL). Avec RTLD_LOCAL, les symboles ne seront pas mis à la disposition des bibliothèques chargées par des appels ultérieurs à dlopen(3) (au lieu d'être référencés par des entrées DT_NEEDED).

Dans les versions précédentes d'Android, si votre application demandait au système de charger une bibliothèque partagée avec transfert de texte, le système affichait un avertissement, mais a quand même autorisé le chargement de la bibliothèque. À partir de cette version, le système rejette cette bibliothèque si la version du SDK cible de votre application est la version 23 ou ultérieure. Pour vous aider à détecter tout échec de chargement d'une bibliothèque, votre application doit consigner l'échec dlopen(3) et inclure le texte de description du problème renvoyé par l'appel dlerror(3). Pour en savoir plus sur la gestion des relocalisations de texte, consultez ce guide.

Validation de l'APK

La plate-forme effectue désormais une validation plus stricte des APK. Un APK est considéré comme corrompu si un fichier est déclaré dans le fichier manifeste, mais qu'il n'est pas présent dans l'APK lui-même. Un APK doit être ré-approuvé si l'un des contenus est supprimé.

Connexion USB

Les connexions d'appareils via le port USB sont désormais définies par défaut sur le mode "Recharge uniquement". Pour accéder à l'appareil et à son contenu via une connexion USB, les utilisateurs doivent explicitement autoriser ces interactions. Si votre application prend en charge les interactions utilisateur avec l'appareil via un port USB, tenez compte du fait que l'interaction doit être explicitement activée.

Modifications apportées à Android for Work

Cette version inclut les modifications de comportement suivantes pour Android for Work :

  • Contacts professionnels dans un contexte personnel Le journal des appels de l'application Téléphone Google affiche désormais les contacts professionnels lorsque l'utilisateur consulte les appels passés. Définir setCrossProfileCallerIdDisabled() sur true masque les contacts du profil professionnel dans le journal d'appels du Google Téléphone. Les contacts professionnels ne peuvent être affichés avec les contacts personnels sur les appareils via Bluetooth que si vous définissez setBluetoothContactSharingDisabled() sur false. Par défaut, cette valeur est définie sur true.
  • Suppression de la configuration Wi-Fi:les configurations Wi-Fi ajoutées par un propriétaire de profil (par exemple, via des appels à la méthode addNetwork()) sont désormais supprimées si ce profil professionnel est supprimé.
  • Verrouillage de la configuration Wi-Fi : toute configuration Wi-Fi créée par un propriétaire d'appareil actif ne peut plus être modifiée ni supprimée par l'utilisateur si WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN est différent de zéro. L'utilisateur peut toujours créer et modifier ses propres configurations Wi-Fi. Les propriétaires d'appareils actifs ont le droit de modifier ou de supprimer toutes les configurations Wi-Fi, y compris celles qu'ils n'ont pas créées.
  • Télécharger l'outil de contrôle des règles relatives aux appareils via l'ajout d'un compte Google:lorsqu'un compte Google nécessitant une gestion via une application de contrôle des règles relatives aux appareils (DPC) est ajouté à un appareil en dehors d'un contexte géré, le flux d'ajout de compte invite désormais l'utilisateur à installer le WPC approprié. Ce comportement s'applique également aux comptes ajoutés via Settings > Accounts (Paramètres > Comptes) et dans l'assistant de configuration initiale de l'appareil.
  • Modifications de comportements d'API DevicePolicyManager spécifiques:
    • L'appel de la méthode setCameraDisabled() n'affecte l'appareil photo que pour l'utilisateur appelant. L'appel à partir du profil géré n'a aucune incidence sur les applications d'appareil photo exécutées sur l'utilisateur principal.
    • De plus, la méthode setKeyguardDisabledFeatures() est désormais disponible pour les propriétaires de profil, ainsi que pour les propriétaires d'appareil.
    • Un propriétaire de profil peut définir les restrictions suivantes pour le clavier :
    • Les méthodes DevicePolicyManager.createAndInitializeUser() et DevicePolicyManager.createUser() sont obsolètes.
    • La méthode setScreenCaptureDisabled() bloque désormais également la structure d'assistance lorsqu'une application de l'utilisateur donné est au premier plan.
    • EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM est désormais défini par défaut sur SHA-256. SHA-1 est toujours compatible avec les versions antérieures, mais sera supprimé à l'avenir. Désormais, EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM n'accepte que SHA-256.
    • Les API d'initialiseur d'appareil qui existaient dans Android 6.0 (niveau d'API 23) sont désormais supprimées.
    • EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS est supprimé afin que le provisionnement par contact NFC ne puisse pas déverrouiller de manière programmatique un appareil protégé par le rétablissement de la configuration d'usine.
    • Vous pouvez désormais utiliser l'extra EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE pour transmettre des données à l'application propriétaire de l'appareil lors du provisionnement NFC de l'appareil géré.
    • Les API Android for Work sont optimisées pour les autorisations d'exécution M, y compris les profils professionnels, la couche d'assistance et d'autres. Les nouvelles API d'autorisation DevicePolicyManager n'affectent pas les applications antérieures à la version M.
    • Lorsque les utilisateurs reviennent en arrière de la partie synchrone du flux de configuration lancé via un intent ACTION_PROVISION_MANAGED_PROFILE ou ACTION_PROVISION_MANAGED_DEVICE, le système renvoie désormais un code de résultat RESULT_CANCELED.
  • Modifications apportées à d'autres API :
    • Consommation de données: la classe android.app.usage.NetworkUsageStats a été rebaptisée NetworkStats.
  • Modifications apportées aux paramètres globaux :