Nouveautés Android 6.0

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&#39;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 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:

  1. Dans votre objet View ou Activity, modifiez votre ActionMode appels de startActionMode(Callback) à startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Utiliser votre implémentation existante de ActionMode.Callback et l'étendre ActionMode.Callback2.
  3. Remplacez les onGetContentRect() pour fournir les coordonnées de l'objet Rect de contenu (un rectangle de sélection de texte, par exemple) 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 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 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 disableAllOthers=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 la targetSdkVersion 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 (comme openConnection(), bindSocket() et le nouveau bindProcessToNetwork()) 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 par onError() étant appelé pour le client évincé. Dans l'API Camera2, cela se traduit par onDisconnected() 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() sur true 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éfini setBluetoothContactSharingDisabled() sur false. Par défaut, il est défini sur true.
  • 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">
    • Les méthodes DevicePolicyManager.createAndInitializeUser() et DevicePolicyManager.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'intent ACTION_PROVISION_MANAGED_DEVICE, le système renvoie maintenant un code de résultat RESULT_CANCELED.
  • 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ée NetworkStats
  • Modifications des paramètres généraux: <ph type="x-smartling-placeholder">