Cette page a été traduite par l'API Cloud Translation.

Changements de comportement dans Android 5.0

Niveau d'API: 21

En plus de nouvelles fonctionnalités, Android 5.0 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 qu'elle peut être affectée par ces modifications dans Android 5.0.

Pour obtenir un aperçu des nouvelles fonctionnalités de la plate-forme, consultez plutôt les principales caractéristiques d'Android Lollipop.

Vidéos

Dev Byte: Nouveautés d'Android 5.0

Octet de développement: notifications

Environnement d'exécution Android Runtime ("ART")

Dans Android 5.0, l'environnement d'exécution ART remplace Dalvik comme plate-forme par défaut. L'environnement d'exécution ART a été introduit dans Android 4.4 à titre expérimental.

Pour obtenir un aperçu des nouvelles fonctionnalités d'ART, consultez la page Présentation d'ART. Voici quelques-unes des principales nouveautés:

Compilation anticipée (AOT)
Amélioration de la récupération de mémoire (GC)
Amélioration de la compatibilité avec le débogage

La plupart des applications Android devraient fonctionner sans aucune modification sous ART. Toutefois, certaines techniques qui fonctionnent sur Dalvik ne fonctionnent pas sur ART. Pour en savoir plus sur les problèmes les plus importants, consultez la section Vérifier le comportement des applications dans l'environnement d'exécution Android Runtime (ART). Portez une attention particulière si:

Votre application utilise Java Native Interface (JNI) pour exécuter du code C/C++.
Vous utilisez des outils de développement qui génèrent du code non standard (tels que certains obscurcissements).
Vous utilisez des techniques incompatibles avec la collecte des déchets compactée.

Notifications

Assurez-vous que vos notifications tiennent compte de ces modifications apportées à Android 5.0. Pour en savoir plus sur la conception de vos notifications pour Android 5.0 ou version ultérieure, consultez le guide de conception des notifications.

Style Material Design

Les notifications sont affichées avec du texte sombre sur un arrière-plan blanc (ou très clair) pour correspondre aux nouveaux widgets Material Design. Assurez-vous que toutes vos notifications s'affichent correctement avec le nouveau jeu de couleurs. Si vos notifications ne semblent pas correctes, corrigez-les:

Utilisez setColor() pour définir une couleur d'accentuation dans un cercle derrière l'image de votre icône.
Modifiez ou supprimez les éléments qui impliquent une couleur. Le système ignore tous les canaux non alpha dans les icônes d'action et dans l'icône de notification principale. Vous devez supposer que ces icônes seront en version alpha uniquement. Le système dessine les icônes de notification en blanc et les icônes d'action en gris foncé.

Son et vibreur

Si vous ajoutez actuellement des sons et des vibrations à vos notifications à l'aide des classes Ringtone, MediaPlayer ou Vibrator, supprimez ce code afin que le système puisse présenter correctement les notifications en mode prioritaire. Utilisez plutôt les méthodes Notification.Builder pour ajouter des sons et des vibrations.

Définir l'appareil sur RINGER_MODE_SILENT permet de passer au nouveau mode de priorité. L'appareil quitte le mode priorité si vous le définissez sur RINGER_MODE_NORMAL ou RINGER_MODE_VIBRATE.

Auparavant, Android utilisait STREAM_MUSIC comme flux principal pour contrôler le volume sur les tablettes. Dans Android 5.0, le flux de volume principal pour les téléphones et les tablettes est désormais unifié et contrôlé par STREAM_RING ou STREAM_NOTIFICATION.

Visibilité de l'écran de verrouillage

Par défaut, les notifications s'affichent désormais sur l'écran de verrouillage de l'utilisateur sous Android 5.0. Les utilisateurs peuvent choisir de protéger les informations sensibles contre toute exposition. Dans ce cas, le système masque automatiquement le texte affiché par la notification. Pour personnaliser cette notification masquée, utilisez setPublicVersion().

Si la notification ne contient pas d'informations personnelles ou si vous souhaitez autoriser le contrôle de la lecture multimédia sur la notification, appelez la méthode setVisibility() et définissez le niveau de visibilité de la notification sur VISIBILITY_PUBLIC.

Lecture des contenus multimédias

Si vous implémentez des notifications qui présentent l'état de la lecture multimédia ou les commandes de transport, envisagez d'utiliser le nouveau modèle Notification.MediaStyle au lieu d'un objet RemoteViews.RemoteView personnalisé. Quelle que soit l'approche choisie, veillez à définir la visibilité de la notification sur VISIBILITY_PUBLIC afin que vos commandes soient accessibles depuis l'écran de verrouillage. Notez qu'à partir d'Android 5.0, le système n'affiche plus d'objets RemoteControlClient sur l'écran de verrouillage. Pour en savoir plus, consultez la section Si votre application utilise RemoteControlClient.

Notification prioritaire

Les notifications peuvent désormais s'afficher dans une petite fenêtre flottante (également appelée notification d'alerte) lorsque l'appareil est actif (c'est-à-dire qu'il est déverrouillé et que son écran est allumé). Ces notifications ressemblent à la forme compacte de votre notification, à l'exception que la notification prioritaire affiche également des boutons d'action. Les utilisateurs peuvent effectuer une action ou ignorer une notification d'alerte sans quitter l'application en cours.

Voici quelques exemples de conditions susceptibles de déclencher des notifications prioritaires:

L'activité de l'utilisateur est en mode plein écran (l'application utilise fullScreenIntent)
La notification a un niveau de priorité élevé et utilise des sonneries ou des vibrations

Si votre application implémente des notifications dans l'un de ces scénarios, assurez-vous que les notifications prioritaires sont présentées correctement.

Commandes multimédias et RemoteControlClient

La classe RemoteControlClient est désormais obsolète. Passez à la nouvelle API MediaSession dès que possible.

Les écrans de verrouillage d'Android 5.0 n'affichent pas les commandes de transport pour votre MediaSession ou RemoteControlClient. À la place, votre application peut fournir un contrôle de la lecture multimédia depuis l'écran de verrouillage via une notification. Cela permet à votre application de mieux contrôler la présentation des boutons multimédias, tout en offrant une expérience cohérente aux utilisateurs sur les appareils verrouillés et déverrouillés.

Android 5.0 introduit un nouveau modèle Notification.MediaStyle à cette fin. Notification.MediaStyle convertit les actions de notification que vous avez ajoutées avec Notification.Builder.addAction() en boutons compacts intégrés aux notifications de lecture multimédia de votre application. Transmettez votre jeton de session à la méthode setSession() pour informer le système que cette notification contrôle une session multimédia en cours.

Veillez à définir la visibilité de la notification sur VISIBILITY_PUBLIC pour la marquer comme pouvant être affichée sur n'importe quel écran de verrouillage (sécurisé ou non). Pour en savoir plus, consultez la section Notifications sur l'écran de verrouillage.

Pour afficher les commandes de lecture multimédia si votre application s'exécute sur la plate-forme Android TV ou Wear, implémentez la classe MediaSession. Vous devez également implémenter MediaSession si votre application doit recevoir des événements de bouton multimédia sur les appareils Android.

getRecentTasks()

Avec l'introduction de la nouvelle fonctionnalité de tâches de documents et d'activités simultanées dans Android 5.0 (voir Documents et activités simultanés sur l'écran "Récents" ci-dessous), la méthode ActivityManager.getRecentTasks() est désormais obsolète afin d'améliorer la confidentialité des utilisateurs. Pour assurer la rétrocompatibilité, cette méthode renvoie toujours un petit sous-ensemble de ses données, y compris les tâches de l'application appelante et éventuellement d'autres tâches non sensibles (telles que la maison). Si votre application utilise cette méthode pour récupérer ses propres tâches, utilisez plutôt getAppTasks() pour récupérer ces informations.

Compatibilité 64 bits dans le NDK Android

Android 5.0 est compatible avec les systèmes 64 bits. L'amélioration 64 bits augmente l'espace d'adressage et améliore les performances, tout en prenant entièrement en charge les applications 32 bits existantes. La prise en charge de la compatibilité 64 bits améliore également les performances d'OpenSSL pour la cryptographie. De plus, cette version introduit de nouvelles API NDK multimédias natives, ainsi que la prise en charge native d'OpenGL ES (GLES) 3.1.

Pour utiliser la compatibilité 64 bits fournie dans Android 5.0, téléchargez et installez la révision 10c du NDK depuis la page du NDK Android. Pour en savoir plus sur les modifications importantes et les corrections de bugs apportées au NDK, consultez les notes de version de la révision 10c.

Lier à un service

La méthode Context.bindService() nécessite désormais un Intent explicite et génère une exception si elle reçoit un intent implicite. Pour vous assurer que votre application est sécurisée, utilisez un intent explicite lorsque vous démarrez ou liez votre Service, et ne déclarez pas de filtres d'intent pour le service.

WebView

Android 5.0 modifie le comportement par défaut de votre application.

Si votre application cible le niveau d'API 21 ou une version ultérieure:
- Le système bloque les contenus mixtes et les cookies tiers par défaut. Pour autoriser le contenu mixte et les cookies tiers, utilisez les méthodes setMixedContentMode() et setAcceptThirdPartyCookies(), respectivement.
- Le système choisit désormais de manière intelligente les parties du document HTML à dessiner. Ce nouveau comportement par défaut permet de réduire l'espace mémoire utilisé et d'améliorer les performances. Si vous souhaitez afficher l'intégralité du document en une seule fois, désactivez cette optimisation en appelant enableSlowWholeDocumentDraw().
Si votre application cible des niveaux d'API inférieurs à 21:le système autorise les contenus mixtes et les cookies tiers, et affiche toujours l'intégralité du document en une seule fois.

Exigence d'unicité pour les autorisations personnalisées

Comme indiqué dans la présentation des autorisations, les applications Android peuvent définir des autorisations personnalisées pour gérer l'accès aux composants de manière propriétaire, sans utiliser les autorisations système prédéfinies de la plate-forme. Les applications définissent des autorisations personnalisées dans les éléments <permission> déclarés dans leurs fichiers manifestes.

Dans un petit nombre de scénarios, définir des autorisations personnalisées est une approche légitime et sécurisée. Toutefois, la création d'autorisations personnalisées est parfois inutile et peut même présenter un risque potentiel pour une application, en fonction du niveau de protection attribué aux autorisations.

Android 5.0 inclut un changement de comportement pour s'assurer qu'une seule application peut définir une autorisation personnalisée donnée, sauf si elle est signée avec la même clé que les autres applications qui définissent l'autorisation.

Applications utilisant des autorisations personnalisées en double

Toute application peut définir n'importe quelle autorisation personnalisée. Il est donc possible que plusieurs applications définissent la même autorisation personnalisée. Par exemple, si deux applications offrent une fonctionnalité similaire, elles peuvent dériver le même nom logique pour leurs autorisations personnalisées. Les applications peuvent également intégrer des bibliothèques publiques courantes ou des exemples de code qui incluent eux-mêmes les mêmes définitions d'autorisations personnalisées.

Sous Android 4.4 et versions antérieures, les utilisateurs pouvaient installer plusieurs applications de ce type sur un appareil donné, même si le système attribuait le niveau de protection spécifié par la première application installée.

À partir d'Android 5.0, le système applique une nouvelle restriction d'unicité sur les autorisations personnalisées pour les applications signées avec différentes clés. Désormais, une seule application sur un appareil peut définir une autorisation personnalisée donnée (déterminée par son nom), sauf si l'autre application qui définit l'autorisation est signée avec la même clé. Si l'utilisateur tente d'installer une application avec une autorisation personnalisée en double et qu'elle n'est pas signée avec la même clé que l'application résidente qui définit l'autorisation, le système bloque l'installation.

Remarques concernant votre application

Sous Android 5.0 et versions ultérieures, les applications peuvent continuer à définir leurs propres autorisations personnalisées comme avant et à demander des autorisations personnalisées à d'autres applications via le mécanisme <uses-permission>. Toutefois, avec la nouvelle exigence introduite dans Android 5.0, vous devez évaluer attentivement les impacts potentiels sur votre application.

Voici quelques points à prendre en compte:

Votre application déclare-t-elle des éléments <permission> dans son fichier manifeste ? Si oui, sont-elles réellement nécessaires au bon fonctionnement de votre application ou de votre service ? Pouvez-vous utiliser une autorisation par défaut du système à la place ?
Si vous avez des éléments <permission> dans votre application, savez-vous d'où ils viennent ?
Avez-vous l'intention de demander à d'autres applications de demander vos autorisations personnalisées via <uses-permission> ?
Utilisez-vous du code standard ou un exemple de code dans votre application qui inclut des éléments <permission> ? Ces éléments d'autorisation sont-ils vraiment nécessaires ?
Vos autorisations personnalisées utilisent-elles des noms simples ou basés sur des termes courants que d'autres applications peuvent partager ?

Nouvelles installations et mises à jour

Comme indiqué ci-dessus, les nouvelles installations et mises à jour de votre application sur les appareils équipés d'Android 4.4 ou d'une version antérieure ne sont pas affectées et le comportement ne change pas. Pour les nouvelles installations et mises à jour sur les appareils équipés d'Android 5.0 ou version ultérieure, le système empêche l'installation de votre application s'il définit une autorisation personnalisée déjà définie par une application résidente existante.

Installations existantes avec la mise à jour du système Android 5.0

Si votre application utilise des autorisations personnalisées et qu'elle est largement distribuée et installée, il est possible qu'elle soit affectée lorsque les utilisateurs mettront à jour leurs appareils vers Android 5.0. Une fois la mise à jour du système installée, le système valide à nouveau les applications installées, y compris en vérifiant leurs autorisations personnalisées. Si votre application définit une autorisation personnalisée déjà définie par une autre application déjà validée et qu'elle n'est pas signée avec la même clé que l'autre application, le système ne réinstalle pas votre application.

Recommandations

Sur les appareils équipés d'Android 5.0 ou version ultérieure, nous vous recommandons d'examiner immédiatement votre application, d'apporter les ajustements nécessaires et de publier la version mise à jour auprès de vos utilisateurs dès que possible.

Si vous utilisez des autorisations personnalisées dans votre application, réfléchissez à leur origine et à la nécessité de les utiliser. Supprimez tous les éléments <permission> de votre application, sauf si vous êtes certain qu'ils sont nécessaires au bon fonctionnement de votre application.
Dans la mesure du possible, envisagez de remplacer vos autorisations personnalisées par les autorisations par défaut du système.
Si votre application nécessite des autorisations personnalisées, renommez-les pour qu'elles soient uniques à votre application, par exemple en les ajoutant au nom complet du package de votre application.
Si vous disposez d'une suite d'applications signées avec différentes clés et que les applications accèdent à un composant partagé à l'aide d'une autorisation personnalisée, assurez-vous que l'autorisation personnalisée n'est définie qu'une seule fois, dans le composant partagé. Les applications qui utilisent le composant partagé ne doivent pas définir elles-mêmes l'autorisation personnalisée, mais doivent plutôt demander l'accès via le mécanisme <uses-permission>.
Si une suite d'applications est signée avec la même clé, chaque application peut définir la ou les autorisations personnalisées nécessaires. Le système permet aux applications d'être installées de la manière habituelle.

Modifications de la configuration TLS/SSL par défaut

Android 5.0 modifie la configuration TLS/SSL par défaut utilisée par les applications pour HTTPS et d'autres trafics TLS/SSL:

Les protocoles TLSv1.2 et TLSv1.1 sont désormais activés.
Les suites de chiffrement AES-GCM (AEAD) sont désormais activées.
Les suites de chiffrement MD5, 3DES, d'exportation et ECDH à clé statique sont désormais désactivées.
Les suites de chiffrement de confidentialité persistante (ECDHE et DHE) sont à privilégier.

Ces modifications peuvent entraîner des interruptions de la connectivité HTTPS ou TLS/SSL dans un petit nombre de cas listés ci-dessous.

Notez que le ProviderInstaller de sécurité des services Google Play propose déjà ces modifications sur les versions de la plate-forme Android depuis Android 2.3.

Le serveur ne prend en charge aucune des suites de chiffrement activées

Par exemple, un serveur peut ne prendre en charge que les suites de chiffrement 3DES ou MD5. La solution privilégiée consiste à améliorer la configuration du serveur pour activer des suites et des protocoles de chiffrement plus efficaces et plus modernes. Idéalement, TLSv1.2 et AES-GCM doivent être activés, et les suites de chiffrement de confidentialité persistante (ECDHE, DHE) doivent être activées et privilégiées.

Vous pouvez également modifier l'application pour qu'elle utilise un SSLSocketFactory personnalisé pour communiquer avec le serveur. L'usine doit être conçue pour créer des instances SSLSocket dont certaines des suites de chiffrement requises par le serveur sont activées en plus des suites de chiffrement par défaut.

L'application émet des hypothèses incorrectes sur les suites de chiffrement utilisées pour se connecter au serveur

Par exemple, certaines applications contiennent un X509TrustManager personnalisé qui plante, car il s'attend à ce que le paramètre authType soit RSA, mais qu'il rencontre ECDHE_RSA ou DHE_RSA.

Le serveur n'est pas compatible avec TLSv1.1, TLSv1.2 ou les nouvelles extensions TLS

Par exemple, le handshake TLS/SSL avec un serveur est refusé par erreur ou bloqué. La solution recommandée consiste à mettre à niveau le serveur pour qu'il respecte le protocole TLS/SSL. Le serveur négociera alors ces protocoles plus récents, ou négociera TLSv1 ou des protocoles plus anciens, et ignorera les extensions TLS qu'il ne comprend pas. Dans certains cas, la désactivation de TLSv1.1 et TLSv1.2 sur le serveur peut servir de mesure provisoire jusqu'à ce que le logiciel du serveur soit mis à niveau.

Vous pouvez également modifier l'application pour qu'elle utilise un SSLSocketFactory personnalisé pour communiquer avec le serveur. L'usine doit être conçue pour créer des instances SSLSocket avec uniquement les protocoles activés qui sont correctement compatibles avec le serveur.

Prise en charge des profils gérés

Les administrateurs d'appareils peuvent ajouter un profil géré à un appareil. Ce profil appartient à l'administrateur, qui peut ainsi le contrôler, tout en laissant le profil personnel de l'utilisateur et son espace de stockage sous son contrôle. Cette modification peut affecter le comportement de votre application existante de différentes manières.

Gérer les intents

Les administrateurs de l'appareil peuvent restreindre l'accès aux applications système à partir du profil géré. Dans ce cas, si une application déclenche un intent à partir du profil géré qui serait normalement géré par cette application et qu'il n'existe pas de gestionnaire approprié pour l'intent sur le profil géré, l'intent génère une exception. Par exemple, l'administrateur de l'appareil peut empêcher les applications du profil géré d'accéder à l'application Appareil photo du système. Si votre application s'exécute sur le profil géré et appelle startActivityForResult() pour MediaStore.ACTION_IMAGE_CAPTURE, et qu'aucune application du profil géré ne peut gérer l'intent, un ActivityNotFoundException est généré.

Pour éviter cela, vérifiez qu'il existe au moins un gestionnaire pour chaque intent avant de le déclencher. Pour vérifier si un gestionnaire est valide, appelez Intent.resolveActivity(). Vous pouvez voir un exemple de cette procédure dans Prendre des photos simplement: prendre une photo avec l'application Appareil photo.

Partager des fichiers entre plusieurs profils

Chaque profil dispose de son propre espace de stockage de fichiers. Étant donné qu'un URI de fichier fait référence à un emplacement spécifique dans l'espace de stockage de fichiers, cela signifie qu'un URI de fichier valide sur un profil n'est pas valide sur l'autre. Ce n'est généralement pas un problème pour une application, qui n'accède généralement qu'aux fichiers qu'elle crée. Toutefois, si une application joint un fichier à un intent, il n'est pas sûr de joindre un URI de fichier, car dans certains cas, l'intent peut être géré sur l'autre profil. Par exemple, un administrateur d'appareil peut spécifier que les événements de capture d'image doivent être gérés par l'application Appareil photo du profil personnel. Si l'intent est déclenché par une application sur le profil géré, l'appareil photo doit pouvoir écrire l'image à un emplacement où les applications du profil géré peuvent la lire.

Pour plus de sécurité, lorsque vous devez joindre un fichier à un intent qui peut passer d'un profil à un autre, vous devez créer et utiliser un URI de contenu pour le fichier. Pour en savoir plus sur le partage de fichiers avec des URI de contenu, consultez la section Partager des fichiers. Par exemple, l'administrateur de l'appareil peut autoriser ACTION_IMAGE_CAPTURE à être géré par la caméra dans le profil personnel. Le EXTRA_OUTPUT de l'intent de déclenchement doit contenir un URI de contenu spécifiant l'emplacement où la photo doit être stockée. L'application d'appareil photo peut écrire l'image à l'emplacement spécifié par cet URI, et l'application qui a déclenché l'intent pourra lire ce fichier, même si l'application se trouve dans l'autre profil.

Android 5.0 ne prend plus en charge les widgets de l'écran de verrouillage, mais continue de prendre en charge les widgets de l'écran d'accueil.