Nouveautés Android 6.0

En plus des nouvelles fonctionnalités, Android 6.0 (niveau d'API 23) inclut diverses modifications du système et du comportement de l'API. Ce document met en évidence certains des principaux changements 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 apportées à la plate-forme affectent votre application.

Autorisations d'exécution

Cette version introduit un nouveau modèle d'autorisations, dans lequel les utilisateurs peuvent désormais gérer directement les autorisations de l'application 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 une version ultérieure, veillez à rechercher et à demander des 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 selon le nouveau modèle d'autorisations.

Pour en savoir plus sur la prise en charge du nouveau modèle d'autorisations dans votre application, consultez Utiliser les autorisations système. Pour obtenir des conseils sur l'évaluation de l'impact sur votre application, consultez la section 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 à tester vos applications dans ces nouveaux modes.

  • Sommeil: si un utilisateur débranche un appareil et le laisse immobile pendant un certain temps, avec l'écran éteint, l'appareil passe en mode Sommeil, où il tente de maintenir le système en veille. Dans ce mode, les appareils reprennent régulièrement le fonctionnement normal pendant de brèves périodes afin que la synchronisation des applications puisse avoir lieu et que le système puisse effectuer toutes les opérations en attente.
  • Mise en veille des applications: la mise en veille des applications 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 des applications qu'il considère inactives.

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

Suppression du client HTTP Apache

La version Android 6.0 supprime la prise en charge du client HTTP Apache. Si votre application utilise ce client et cible Android 2.3 (niveau d'API 9) ou une 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 une mise en cache des réponses transparentes, et réduit la consommation d'énergie. Pour continuer à utiliser les API HTTP Apache, vous devez d'abord déclarer la dépendance suivante au moment de la compilation dans votre fichier build.gradle: 

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

SSL ennuyeux

Android abandonne OpenSSL au profit de la bibliothèque BoringSSL. Si vous utilisez le NDK Android dans votre application, n'associez pas votre application à 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. En outre, vous pouvez vous exposer à des failles de sécurité. Modifiez plutôt votre code natif pour appeler les API de cryptographie Java via JNI ou pour créer un lien statique avec la bibliothèque de cryptographie de votre choix.

Accès à l'identifiant matériel

Pour améliorer la protection des données des utilisateurs, Android supprime l'accès programmatique à l'identifiant matériel local de l'appareil pour les applications utilisant 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 les recherches 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 recherche 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'imprime 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 la méthode adjustStreamVolume() et transmettez la valeur de direction ADJUST_MUTE ou ADJUST_UNMUTE.

Sélection de texte

Écran affichant 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. Prenez votre implémentation existante de ActionMode.Callback et faites-la étendre ActionMode.Callback2 à la place.
  3. Remplacez la méthode onGetContentRect() pour fournir les coordonnées de l'objet Rect de contenu (tel qu'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 à invalider, appelez la méthode invalidateContentRect().

Si vous utilisez la révision 22.2 de la bibliothèque Android Support, sachez que les barres d'outils flottantes ne sont pas rétrocompatibles et qu'Appcompat prend le contrôle des objets ActionMode par défaut. Cela empêche l'affichage de barres d'outils flottantes. Pour activer la prise en charge de ActionMode dans un AppCompatActivity, appelez getDelegate(), puis 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), ce qui permet au framework de prendre en charge les modes ActionBar ou de 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 pris en charge.

Modifications des favoris du navigateur

Cette version supprime la prise en charge des favoris globaux. Suppression des méthodes android.provider.Browser.getAllBookmarks() et android.provider.Browser.saveBookmark(). 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 et n'utilisez pas les autorisations de favoris. Au lieu de cela, votre application doit stocker les données des favoris en interne.

Modifications apportées à Android Keystore

Avec cette version, le fournisseur Android Keystore n'accepte plus les ADR. L'ECDSA est toujours accepté.

Les clés qui ne nécessitent pas de chiffrement au repos ne seront plus supprimées lorsque l'écran de verrouillage sécurisé est 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 sont supprimées lors de ces événements.

Changements relatifs au Wi-Fi et au réseau

Cette version apporte les modifications de comportement suivantes aux API Wi-Fi et de mise en réseau.

  • Vos applications ne peuvent désormais modifier l'état des objets WifiConfiguration que si vous avez créé ces objets. 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éconnecte d'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 inférieure ou égale à “20”, elle est épinglée au réseau Wi-Fi sélectionné. Si le targetSdkVersion de votre application est “21” ou supérieur, 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 Appareil photo

Dans cette version, le modèle d'accès aux ressources partagées du service de caméra est passé du précédent modèle d'accès "premier arrivé, premier servi" à un modèle d'accès qui privilégie les processus à priorité élevée. Le comportement du service a été modifié:

  • L'accès aux ressources du sous-système d'appareil photo, y compris l'ouverture et la configuration d'un appareil photo, est accordé en fonction de la "priorité" du processus de l'application cliente. Les processus d'application comportant des activités visibles par l'utilisateur ou au premier plan reçoivent généralement 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 des 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 évincé. Dans l'API Camera2, onDisconnected() est appelé pour le client évincé.
  • Sur les appareils dotés du matériel d'appareil photo approprié, des processus d'application distincts peuvent ouvrir et utiliser simultanément des caméras distinctes de manière indépendante. Toutefois, les cas d'utilisation multiprocessus, dans lesquels l'accès simultané entraîne une dégradation importante des performances ou des fonctionnalités de n'importe quel appareil photo ouvert, sont désormais détectés et interdits par le service de caméra. Cette modification peut entraîner des "évictions" pour les clients de priorité inférieure, même lorsqu'aucune autre application ne tente directement d'accéder au même appareil photo.
  • La modification de l'utilisateur actuel entraîne l'éviction des clients d'appareil photo 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 peut pas laisser de processus en cours d'exécution qui utilisent le sous-système d'appareil photo lorsque l'utilisateur change de 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 les règles d'accès de manière incorrecte dans les versions précédentes. Si votre application utilise la méthode newInstance() et que vous souhaitez ignorer 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 afin qu'elle utilise les dernières versions de ces bibliothèques. Sinon, assurez-vous que toutes les classes personnalisées référencées à partir du XML sont mises à jour afin que leurs constructeurs de classe soient accessibles.

Cette version met à jour le comportement de l'éditeur de liens dynamique. L'éditeur de liens dynamique comprend désormais la différence entre le soname d'une bibliothèque et son chemin d'accès ( bug public 6670). 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 d'accès absolus dans le système de fichiers de la machine de compilation) peuvent échouer lors du chargement.

L'indicateur dlopen(3) RTLD_LOCAL est désormais correctement implémenté. Notez que RTLD_LOCAL est la valeur par défaut. Par conséquent, les appels à dlopen(3) qui n'ont pas explicitement utilisé RTLD_LOCAL seront affectés (sauf si votre application utilise explicitement RTLD_GLOBAL). Avec RTLD_LOCAL, les symboles ne seront pas disponibles pour les bibliothèques chargées par les appels ultérieurs de dlopen(3) (au lieu d'être référencés par les 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 des transferts de texte, le système affichait un avertissement, mais autorisait le chargement de la bibliothèque. À partir de cette version, le système refusera cette bibliothèque si la version du SDK cible de votre application est 23 ou ultérieure. Pour vous aider à détecter si une bibliothèque ne se charge pas, votre application doit consigner l'échec de 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 déplacements 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 pas dans l'APK lui-même. Un APK doit être signé à nouveau si l'un des contenus est supprimé.

Connexion USB

Par défaut, les connexions des appareils via le port USB sont désormais configurées en 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 ces interactions doivent être explicitement activées.

Modifications apportées à Android for Work

Cette version inclut les changements de comportement suivants pour Android for Work:

  • Contacts professionnels dans un contexte personnel Le journal d'appels de Google Dialer 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 Google Dialer. 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, elle 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 la valeur de WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN est non nulle. L'utilisateur peut toujours créer et modifier ses propres configurations Wi-Fi. Les propriétaires actifs d'appareils 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échargez l'outil de contrôle des règles relatives aux appareils via l'ajout de 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 Paramètres > Comptes et dans l'assistant de configuration initiale de l'appareil.
  • Modifications apportées à des comportements spécifiques de l'API DevicePolicyManager:
    • L'appel de la méthode setCameraDisabled() n'affecte que la caméra de l'utilisateur appelant. L'appel à partir du profil géré n'affecte pas 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'appareils.
    • Un propriétaire de profil peut définir les restrictions de verrouillage du clavier suivantes :
    • Abandon des méthodes DevicePolicyManager.createAndInitializeUser() et DevicePolicyManager.createUser().
    • Désormais, la méthode setScreenCaptureDisabled() bloque également la structure d'assistance lorsqu'une application de l'utilisateur donné est exécutée au premier plan.
    • EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM est désormais SHA-256 par défaut. SHA-1 est toujours compatible avec la rétrocompatibilité, mais sera supprimé à l'avenir. EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM n'accepte désormais que SHA-256.
    • Suppression des API d'initialisation d'appareil qui existaient dans Android 6.0 (niveau d'API 23).
    • EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS est supprimé afin que le provisionnement NFC par intermittence ne puisse pas déverrouiller de manière programmatique un appareil protégé en cas de 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 du 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 pour les profils professionnels, la couche d'assistance, etc. Les nouvelles API d'autorisation DevicePolicyManager n'affectent pas les applications antérieures à la version M.
    • Lorsque les utilisateurs quittent la partie synchrone du flux de configuration initiée 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 aux autres API :
    • Consommation des données: la classe android.app.usage.NetworkUsageStats a été renommée NetworkStats.
  • Modifications apportées aux paramètres généraux :