En plus des nouvelles fonctionnalités, Android 6.0 (niveau d'API 23) comprend plusieurs du système et du comportement de l'API. Ce document met en avant quelques-unes des modifications clés que vous devez comprendre et tenir compte dans vos applications.
Si vous avez déjà publié une application pour Android, notez que ces modifications dans le sur 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 lors de l'exécution. Ce modèle offre aux utilisateurs une meilleure visibilité et un meilleur contrôle 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.
Sur vos applications qui ciblent Android 6.0 (niveau d'API 23) ou version ultérieure, vérifiez et demandez
au moment de l'exécution. Pour déterminer si votre application a reçu une autorisation, appelez la méthode
nouveau checkSelfPermission()
. Pour demander une autorisation, appelez la nouvelle
requestPermissions()
. Même si votre application ne cible pas Android 6.0 (niveau d'API 23), vous devez la tester
le nouveau modèle d'autorisations.
Pour savoir comment prendre en charge le nouveau modèle d'autorisations dans votre application, consultez <ph type="x-smartling-placeholder"></ph> Utiliser des autorisations système Pour obtenir des conseils sur la façon d'évaluer l'impact sur votre application, consultez les remarques 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 applications inactifs. Ces 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, avec l'écran éteint, pendant un certain temps, l'appareil passe en mode Sommeil pour essayer de maintenir le système en état de sommeil. Avec ce mode, les appareils reprennent régulièrement leur fonctionnement normal pendant de courtes périodes pour que la synchronisation de l'application 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. C'est le système qui prend cette décision sur l'application pendant un certain temps. Si l'appareil est débranché, le système désactive le réseau l'accès et suspend les synchronisations et les jobs pour les applications qu'il considère inactives.
Pour en savoir plus sur ces changements d'économie d'énergie, consultez Optimisation pour les fonctionnalités Sommeil et Mise en veille des applications.
Suppression du client HTTP Apache
La version Android 6.0 n'est plus compatible avec le client HTTP Apache. Si votre application utilise ce client
cible Android 2.3 (niveau d'API 9) ou version ultérieure, utilisez la classe HttpURLConnection
à la place. 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éduire la consommation d'énergie. Pour continuer à utiliser les API HTTP Apache,
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' }
BoringSSL
Android abandonne OpenSSL pour
BoringSSL
bibliothèque. 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, tels que libcrypto.so
et libssl.so
. Ces
ne sont pas des API publiques. Elles peuvent être modifiées ou interrompues sans préavis selon les versions et les appareils.
De plus, vous risquez de vous exposer à des failles de sécurité. Modifiez plutôt votre
du code natif pour appeler les API de cryptographie Java via JNI ou pour établir un lien statique avec un
la bibliothèque de cryptographie de votre choix.
Accès à l'identifiant matériel
Afin d'offrir aux utilisateurs une meilleure protection des données, Android
supprime l'accès programmatique à l'identifiant matériel local de l'appareil pour
à l'aide des API Wi-Fi et Bluetooth. La
WifiInfo.getMacAddress()
et les
BluetoothAdapter.getAddress()
méthode
renvoient maintenant une valeur constante de 02:00:00:00:00:00
.
Pour accéder aux identifiants matériels des appareils externes à proximité via des recherches Bluetooth et Wi-Fi, procédez comme suit :
votre application doit désormais disposer de l'ACCESS_FINE_LOCATION
ou
Autorisations ACCESS_COARSE_LOCATION
:
Remarque: Lorsqu'un appareil équipé d'Android 6.0 (niveau d'API 23) lance une Wi-Fi ou Bluetooth en arrière-plan, l'opération est visible par les appareils externes provenant d’une adresse MAC aléatoire.
Notifications
Cette version supprime la méthode Notification.setLatestEventInfo()
. Utilisez les
Notification.Builder
pour créer des notifications. Pour mettre à jour un
de manière répétée, réutilisez l'instance Notification.Builder
. Appelez la méthode
build()
pour obtenir
Notification
instances 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 afficher le texte
dans un objet de notification.
Modifications d'AudioManager
Régler le volume directement ou couper le son de certains flux via l'AudioManager
n'est plus prise en charge. La méthode setStreamSolo()
est obsolète. Vous devez appeler la méthode
requestAudioFocus()
. De même, le
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 affichant de nouvelles fonctionnalités de sélection de texte dans une barre d'outils flottante](https://developer.android.com/static/images/android-6.0/text-selection.gif?authuser=9&hl=fr)
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 un barre d'outils flottante. L'implémentation de l'interaction utilisateur est semblable à celle-ci : pour la barre d'action contextuelle, comme décrit dans <ph type="x-smartling-placeholder"></ph> 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 à votre applications:
- Dans votre objet
View
ouActivity
, modifiez votreActionMode
appels destartActionMode(Callback)
àstartActionMode(Callback, ActionMode.TYPE_FLOATING)
. - Utiliser votre implémentation existante de
ActionMode.Callback
et l'étendreActionMode.Callback2
. - Remplacez les
onGetContentRect()
pour fournir les coordonnées de l'objetRect
de contenu (un rectangle de sélection de texte, par exemple) 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
Bibliothèque Android Support version 22.2 (notez que les barres d'outils flottantes ne sont pas
la rétrocompatibilité et appcompat prennent le contrôle des objets ActionMode
en
par défaut. Cela empêche l'affichage de barres d'outils flottantes. Pour activer
Prise en charge de ActionMode
dans un
AppCompatActivity
, appel
getDelegate()
, puis appelez
setHandleNativeActionModesEnabled()
sur la valeur renvoyée
AppCompatDelegate
et définissez l'entrée
sur false
. Cet appel rend le contrôle des objets ActionMode
aux
le cadre. Sur les appareils équipés d'Android 6.0 (niveau d'API 23), cela permet au framework de prendre en charge
Mode ActionBar
ou barre d'outils flottante sur les appareils en cours d'exécution
Android 5.1 (niveau d'API 22) ou version antérieure, seuls les modes ActionBar
sont
compatibles.
Modifications des favoris du navigateur
Cette version ne prend plus en charge les favoris globaux. La
android.provider.Browser.getAllBookmarks()
et android.provider.Browser.saveBookmark()
de méthodes sont maintenant supprimées. De même, READ_HISTORY_BOOKMARKS
et WRITE_HISTORY_BOOKMARKS
les autorisations sont supprimées. Si votre application cible Android 6.0 (niveau d'API 23) ou une version ultérieure, n'accédez pas
les favoris du fournisseur global ou utiliser les autorisations de favoris. Votre application doit plutôt stocker
des favoris en interne.
Modifications apportées au keystore Android
Avec cette nouveauté, Le fournisseur Android Keystore n'est plus compatible ADR. L'ECDSA est toujours accepté.
Les clés qui ne nécessitent pas de chiffrement au repos ne seront plus supprimées lors de l'écran de verrouillage sécurisé est désactivé ou réinitialisé (par l'utilisateur ou un administrateur de l'appareil, par exemple). Clés nécessitant le chiffrement au repos sera supprimé au cours 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 que l'état des objets
WifiConfiguration
si vous avez créé ces objets. Vous n'êtes pas autorisé à modifier ni à supprimer 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 ledisableAllOthers=true
, l'appareil s'est déconnecté d'autres réseaux, par exemple les données mobiles. Dans cette version, l'appareil ne se déconnecte plus de ces autres réseaux. Si latargetSdkVersion
de votre application est de“20”
ou moins, elle est épinglée à la sélection Réseau Wi-Fi. Si l'targetSdkVersion
de votre application est de niveau“21”
ou supérieur, utilisez le les API multiréseaux (commeopenConnection()
,bindSocket()
et le nouveaubindProcessToNetwork()
) pour vous assurer que son trafic réseau est envoyé sur le réseau sélectionné.
Modifications apportées au service de l'appareil photo
Dans cette version, le modèle d'accès aux ressources partagées du service de caméra a été modifié du précédent modèle d'accès "premier arrivé, premier servi" à un modèle d'accès dans lequel processus sont favorisés. Voici quelques exemples de modifications apportées au comportement du service:
- L'accès aux ressources du sous-système d'appareil photo, y compris l'ouverture et la configuration d'un appareil photo, est en fonction de la "priorité" du processus de candidature du client. Processus d'application avec Les activités visibles par l'utilisateur ou au premier plan reçoivent généralement une priorité plus élevée, ce qui fait que la ressource d'appareil photo l'acquisition de clients et leur utilisation.
- Les clients d'appareil photo actifs pour les applications de priorité inférieure peuvent être "évincés" lorsqu'ils ont une priorité plus élevée
tente d'utiliser l'appareil photo. Dans l'API
Camera
obsolète, cela se traduit paronError()
étant appelé pour le client évincé. Dans l'APICamera2
, cela se traduit paronDisconnected()
appelé pour le client évincé. - Sur les appareils équipés d'un appareil photo approprié, des processus d'application distincts peuvent ouvrent et utilisent simultanément plusieurs caméras distinctes. Toutefois, l'utilisation multiprocessus dans les cas où l'accès simultané entraîne une dégradation importante des performances ou des capacités les appareils photo ouverts sont désormais détectés et bloqués par le service de caméra. Cette modification peut entraîner des "évictions" pour les clients de priorité inférieure, même si aucune autre application n'est tente d'accéder à la même caméra.
- Si vous modifiez l'utilisateur actuel, les clients d'appareil photo actifs seront présents dans les applications appartenant au compte utilisateur précédent d'être évincés. 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 quitter processus qui utilisent le sous-système de l’appareil photo 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 le
newInstance()
. Ce
modification corrige 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 le
La méthode newInstance()
et vous
ignorer les vérifications d'accès, appelez la méthode
Méthode setAccessible()
avec l'entrée
défini sur true
. Si votre application utilise
bibliothèque appcompat v7 ou
bibliothèque recyclerview v7,
vous devez mettre à jour votre application pour utiliser les dernières versions de ces bibliothèques. Sinon, assurez-vous que
toutes les classes personnalisées référencées à partir de XML sont mises à jour afin que leurs constructeurs de classes soient accessibles.
Cette version met à jour le comportement de l'éditeur de liens dynamique. L'éditeur de liens dynamiques comprend désormais
différence entre le soname
d'une bibliothèque et son chemin d'accès
(
le bug public 6670), et la recherche par soname
est désormais
mise en œuvre. Applications qui fonctionnaient auparavant et qui comportaient des entrées DT_NEEDED
incorrectes
(généralement des chemins d'accès absolus sur le système de fichiers de la machine de compilation) peuvent échouer lors de leur chargement.
L'indicateur dlopen(3) RTLD_LOCAL
est maintenant correctement implémenté. Notez que
RTLD_LOCAL
est l'option par défaut. Les appels à dlopen(3)
qui n'ont pas été explicitement utilisés
RTLD_LOCAL
sera affectée (sauf si votre appli 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 de
dlopen(3)
(au lieu d'être référencé 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
déplacement du texte, le système a affiché un avertissement, mais a quand même autorisé le chargement de la bibliothèque.
À partir de cette version, le système refusera cette bibliothèque si le SDK cible de votre appli est en version 23
ou supérieur. Pour vous aider à détecter si le chargement d'une bibliothèque a échoué, votre application doit consigner l'erreur
d'échec de dlopen(3)
, et incluez le texte de description du problème que dlerror(3)
. Pour en savoir plus sur la gestion des transferts de texte, consultez
guide d'installation.
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 absente de l'APK lui-même. Un APK doit être signé de nouveau si l'un des sont supprimés.
Connexion USB
Les appareils connectés via le port USB sont désormais configurés par défaut en mode recharge uniquement. Pour y accéder l'appareil et son contenu via une connexion USB, les utilisateurs doivent explicitement autoriser des interactions. Si votre application prend en charge les interactions utilisateur avec l'appareil via un port USB, prenez en car 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 : Google Dialer
Le journal d'appels affiche désormais les contacts professionnels lorsque l'utilisateur consulte les appels passés.
Paramètre
setCrossProfileCallerIdDisabled()
surtrue
masque les contacts du profil professionnel dans le journal d'appels de l'application Téléphone de Google. Les contacts professionnels peuvent être s'affiche avec les contacts personnels sur les appareils via Bluetooth, vous avez définisetBluetoothContactSharingDisabled()
surfalse
. Par défaut, il est défini surtrue
. - Suppression de la configuration Wi-Fi:configurations Wi-Fi ajoutées par un propriétaire de profil
(par exemple, en appelant la fonction
addNetwork()
) sont désormais supprimées si ce profil professionnel est supprimé. - Blocage de la configuration Wi-Fi:toute configuration Wi-Fi créée par
un propriétaire d'appareil actif ne peut plus être modifié ni supprimé par l'utilisateur si
WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN
n'est pas nul. L'utilisateur peut toujours créer et modifier ses propres configurations Wi-Fi. Appareil actif Les propriétaires ont le droit de modifier ou de supprimer toute configuration Wi-Fi, y compris celles qu'il n'a pas créées. - Téléchargement de l'outil de contrôle des règles relatives aux appareils via l'ajout d'un compte Google:lorsqu'un un compte qui doit être géré par le biais d'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 de comportements d'API
DevicePolicyManager
spécifiques: <ph type="x-smartling-placeholder">- </ph>
- En appelant la méthode
setCameraDisabled()
n'affecte l'appareil photo que pour l'utilisateur appelant. l'appeler à partir du profil géré affectent les applications d'appareil photo exécutées sur l'utilisateur principal. - En outre,
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:
<ph type="x-smartling-placeholder">
- </ph>
KEYGUARD_DISABLE_TRUST_AGENTS
etKEYGUARD_DISABLE_FINGERPRINT
, qui affectent la paramètres de protection 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é.
- Les méthodes
DevicePolicyManager.createAndInitializeUser()
etDevicePolicyManager.createUser()
ont été abandonnées. 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
la valeur par défaut est SHA-256. SHA-1 est toujours pris en charge pour la rétrocompatibilité, mais sera supprimé à l'avenir.EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM
n'accepte désormais que SHA-256.- Les API d'initialisation d'appareils qui existaient dans Android 6.0 (niveau d'API 23) sont désormais supprimées.
EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS
a été supprimé, ce qui accroît la fonctionnalité NFC le provisionnement ne peut pas déverrouiller de manière programmatique un appareil protégé lors du rétablissement de la configuration d'usine.- Vous pouvez désormais utiliser
EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
supplémentaires 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 les profils professionnels,
la couche d'assistance, etc. Les nouvelles API d'autorisation
DevicePolicyManager
ne permettent pas sur les applications antérieures à la version M. - Lorsque les utilisateurs quittent la partie synchrone du flux de configuration initiée par le biais d'une
ACTION_PROVISION_MANAGED_PROFILE
ou l'intentACTION_PROVISION_MANAGED_DEVICE
, le système renvoie maintenant un code de résultatRESULT_CANCELED
.
- En appelant la méthode
- Modifications apportées à d'autres API:
<ph type="x-smartling-placeholder">
- </ph>
- Consommation des données: la classe
android.app.usage.NetworkUsageStats
a été renomméeNetworkStats
- Consommation des données: la classe
- Modifications des paramètres généraux:
<ph type="x-smartling-placeholder">
- </ph>
- Ces paramètres ne peuvent plus être définis via
setGlobalSettings()
: <ph type="x-smartling-placeholder">- </ph>
BLUETOOTH_ON
DEVELOPMENT_SETTINGS_ENABLED
MODE_RINGER
NETWORK_PREFERENCE
WIFI_ON
- Ces paramètres globaux peuvent désormais être définis via
setGlobalSettings()
: <ph type="x-smartling-placeholder">
- Ces paramètres ne peuvent plus être définis via