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
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:
- Dans votre objet
View
ouActivity
, faites passer vos appelsActionMode
destartActionMode(Callback)
àstartActionMode(Callback, ActionMode.TYPE_FLOATING)
. - Prenez votre implémentation existante de
ActionMode.Callback
et faites-la étendreActionMode.Callback2
à la place. - Remplacez la méthode
onGetContentRect()
pour fournir les coordonnées de l'objetRect
de contenu (tel qu'un rectangle de sélection de texte) dans la vue. - 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 objetsWifiConfiguration
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ètredisableAllOthers=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 valeurtargetSdkVersion
de votre application est inférieure ou égale à“20”
, elle est épinglée au réseau Wi-Fi sélectionné. Si letargetSdkVersion
de votre application est“21”
ou supérieur, utilisez les API multiréseaux (telles queopenConnection()
,bindSocket()
et la nouvelle méthodebindProcessToNetwork()
) 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'APICamera2
,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()
surtrue
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éfinissezsetBluetoothContactSharingDisabled()
surfalse
. Par défaut, elle est définie surtrue
. - 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 :
KEYGUARD_DISABLE_TRUST_AGENTS
etKEYGUARD_DISABLE_FINGERPRINT
, qui affectent les paramètres de verrouillage du clavier pour l'utilisateur parent du profil.KEYGUARD_DISABLE_UNREDACTED_NOTIFICATIONS
, qui n'affecte que les notifications générées par les applications dans le profil géré.
- Abandon des méthodes
DevicePolicyManager.createAndInitializeUser()
etDevicePolicyManager.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
ouACTION_PROVISION_MANAGED_DEVICE
, le système renvoie désormais un code de résultatRESULT_CANCELED
.
- L'appel de la méthode
- Modifications apportées aux autres API :
- Consommation des données: la classe
android.app.usage.NetworkUsageStats
a été renomméeNetworkStats
.
- Consommation des données: la classe
- Modifications apportées aux paramètres généraux :
- Ces paramètres ne peuvent plus être définis via
setGlobalSettings()
:BLUETOOTH_ON
DEVELOPMENT_SETTINGS_ENABLED
MODE_RINGER
NETWORK_PREFERENCE
WIFI_ON
- Ces paramètres généraux peuvent désormais être définis via
setGlobalSettings()
:
- Ces paramètres ne peuvent plus être définis via