Android 7.0 pour les développeurs

Android 7.0 Nougat introduit de nouvelles fonctionnalités pour les utilisateurs et les développeurs. Ce document présente les nouveautés pour les développeurs.

Veillez à consulter les modifications de comportement d'Android 7.0 pour en savoir plus sur les domaines dans lesquels les modifications de la plate-forme peuvent affecter vos applications.

Pour en savoir plus sur les fonctionnalités grand public d'Android 7.0, consultez www.android.com.

Compatibilité avec le mode multifenêtre

Dans Android 7.0, nous introduisons une nouvelle fonctionnalité multitâche très demandée sur la plate-forme : le mode multifenêtre.

Les utilisateurs peuvent désormais ouvrir deux applications à la fois.

• Sur les téléphones et les tablettes équipés d'Android 7.0, les utilisateurs peuvent exécuter deux applications côte à côte ou l'une au-dessus de l'autre en mode Écran partagé. Les utilisateurs peuvent redimensionner les applications en faisant glisser le séparateur entre elles.
• Sur les appareils Android TV, les applications peuvent se mettre en mode Picture-in-picture, ce qui leur permet de continuer à afficher du contenu pendant que l'utilisateur parcourt ou interagit avec d'autres applications.

Le mode multifenêtre vous offre de nouvelles façons d'engager les utilisateurs, en particulier sur les tablettes et les autres appareils à grand écran. Vous pouvez même activer le glisser-déposer dans votre application pour permettre aux utilisateurs de faire glisser du contenu vers ou depuis votre application. C'est un excellent moyen d'améliorer l'expérience utilisateur.

Il est facile d'ajouter la prise en charge du mode multifenêtre à votre application et de configurer la manière dont elle gère l'affichage multifenêtre. Par exemple, vous pouvez spécifier les dimensions minimales autorisées de votre activité, ce qui empêche les utilisateurs de redimensionner l'activité en dessous de cette taille. Vous pouvez également désactiver l'affichage multifenêtre pour votre application. Ainsi, le système n'affichera votre application qu'en mode plein écran.

Pour en savoir plus, consultez la documentation destinée aux développeurs sur la compatibilité avec le mode multifenêtre.

Améliorations des notifications

Dans Android 7.0, nous avons repensé les notifications pour les rendre plus faciles et plus rapides à utiliser. Voici quelques-unes des modifications apportées:

• Mises à jour des modèles: nous modifions les modèles de notification pour mettre davantage l'accent sur l'image héros et l'avatar. Les développeurs pourront profiter des nouveaux modèles avec un minimum d'ajustements dans leur code.
• Personnalisation du style de message: vous pouvez personnaliser davantage de libellés d'interface utilisateur associés à vos notifications à l'aide de la classe MessagingStyle. Vous pouvez configurer le message, le titre de la conversation et l'affichage du contenu.
• Notifications groupées: le système peut regrouper les messages, par exemple par sujet, et afficher le groupe. L'utilisateur peut effectuer des actions sur ces éléments, comme les ignorer ou les archiver. Si vous avez implémenté des notifications pour Android Wear, vous connaissez déjà ce modèle.
• Réponse directe: pour les applications de communication en temps réel, le système Android prend en charge les réponses intégrées afin que les utilisateurs puissent répondre rapidement aux SMS ou aux SMS directement dans l'interface de notification.
• Vues personnalisées: deux nouvelles API vous permettent d'exploiter les décorations système, telles que les en-têtes de notification et les actions, lorsque vous utilisez des vues personnalisées dans les notifications.

Figure 2. Notifications groupées et réponse directe.

Pour découvrir comment implémenter les nouvelles fonctionnalités, consultez le guide Notifications.

Compilation JIT/AOT guidée par le profil

Dans Android 7.0, nous avons ajouté un compilateur JIT (Just-in-Time) avec profilage de code à ART, ce qui lui permet d'améliorer constamment les performances des applications Android lors de leur exécution. Le compilateur JIT complète le compilateur Ahead of Time (AOT) actuel d'ART et contribue à améliorer les performances d'exécution, à économiser de l'espace de stockage et à accélérer les mises à jour d'applications et du système.

La compilation guidée par le profil permet à ART de gérer la compilation AOT/JIT pour chaque application en fonction de son utilisation réelle et des conditions de l'appareil. Par exemple, ART conserve un profil des méthodes à chaud de chaque application, et peut précompiler et mettre en cache ces méthodes pour optimiser les performances. Les autres parties de l'application ne sont pas compilées jusqu'à ce qu'elles soient réellement utilisées.

En plus d'améliorer les performances des éléments clés de l'application, la compilation guidée par le profil permet de réduire l'empreinte RAM globale d'une application, y compris les binaires associés. Cette fonctionnalité est particulièrement importante sur les appareils disposant de peu de mémoire.

ART gère la compilation guidée par le profil de manière à minimiser l'impact sur la batterie de l'appareil. La précompilation n'est effectuée que lorsque l'appareil est inactif et en charge, ce qui permet de gagner du temps et d'économiser de la batterie en effectuant ce travail à l'avance.

Installation rapide de l'application

L'un des avantages les plus tangibles du compilateur JIT d'ART est la vitesse d'installation des applications et des mises à jour du système. Même les applications volumineuses dont l'optimisation et l'installation nécessitaient plusieurs minutes sous Android 6.0 peuvent désormais s'installer en quelques secondes. Les mises à jour du système sont également plus rapides, car il n'y a plus d'étape d'optimisation.

Sommeil en déplacement...

Android 6.0 a lancé Sommeil, un mode système qui permet d'économiser la batterie en différant les activités du processeur et du réseau des applications lorsque l'appareil est inactif, par exemple lorsqu'il est assis sur une table ou dans un tiroir.

Avec Android 7.0, la fonctionnalité Sommeil va encore plus loin et permet d'économiser la batterie lors de vos déplacements. Chaque fois que l'écran est éteint pendant un certain temps et que l'appareil est débranché, Doze applique un sous-ensemble des restrictions habituelles liées au processeur et au réseau aux applications. Cela signifie que les utilisateurs peuvent économiser la batterie même lorsqu'ils tiennent leur appareil dans leur poche.

Figure 3. La fonctionnalité Sommeil applique désormais des restrictions pour améliorer l'autonomie de la batterie, même lorsque l'appareil n'est pas à l'arrêt.

Peu de temps après l'arrêt de l'écran, lorsque l'appareil est sur batterie, la fonctionnalité Sommeil limite l'accès au réseau et diffère les tâches et les synchronisations. Pendant de brefs intervalles de maintenance, les applications sont autorisées à accéder au réseau et toutes leurs tâches/synchronisations différées sont exécutées. Le fait d'allumer l'écran ou de brancher l'appareil le désactive.

Lorsque l'appareil est à nouveau immobile, avec l'écran éteint et sur la batterie pendant un certain temps, la fonctionnalité Sommeil applique l'ensemble des restrictions liées au processeur et au réseau aux alarmes PowerManager.WakeLock et AlarmManager, ainsi qu'aux recherches GPS/Wi-Fi.

Les bonnes pratiques pour adapter votre application au mode Sommeil sont les mêmes, que l'appareil soit en mouvement ou non. Par conséquent, si vous avez déjà mis à jour votre application pour gérer correctement la fonctionnalité Sommeil, vous êtes prêt. Si ce n'est pas le cas, commencez à adapter votre application à la fonctionnalité Sommeil dès maintenant.

Project Svelte: optimisations en arrière-plan

Le projet Svelte vise à réduire l'utilisation de la RAM par le système et les applications sur la gamme d'appareils Android de l'écosystème. Dans Android 7.0, Project Svelte vise à optimiser l'exécution des applications en arrière-plan.

Le traitement en arrière-plan est un élément essentiel de la plupart des applications. Lorsqu'elle est gérée correctement, elle peut rendre l'expérience utilisateur exceptionnelle : immédiate, rapide et contextualisée. Lorsqu'il n'est pas géré correctement, le traitement en arrière-plan peut consommer inutilement la RAM (et la batterie) et affecter les performances du système pour d'autres applications.

Depuis Android 5.0, JobScheduler est le moyen privilégié pour effectuer des tâches en arrière-plan d'une manière positive pour les utilisateurs. Les applications peuvent planifier des tâches tout en laissant le système optimiser en fonction des conditions de mémoire, d'alimentation et de connectivité. JobScheduler offre contrôle et simplicité, et nous voulons que toutes les applications l'utilisent.

Une autre bonne option est GCMNetworkManager, qui fait partie des services Google Play, qui offre une planification des tâches similaire et compatible avec les anciennes versions d'Android.

Nous continuons d'étendre JobScheduler et GCMNetworkManager pour répondre à davantage de cas d'utilisation. Par exemple, dans Android 7.0, vous pouvez désormais planifier des tâches en arrière-plan en fonction des modifications apportées aux fournisseurs de contenu. En parallèle, nous commençons à abandonner certains des anciens modèles qui peuvent réduire les performances du système, en particulier sur les appareils à faible mémoire.

Dans Android 7.0, nous supprimons trois diffusions implicites couramment utilisées (CONNECTIVITY_ACTION, ACTION_NEW_PICTURE et ACTION_NEW_VIDEO), car elles peuvent activer les processus en arrière-plan de plusieurs applications à la fois et mettre à rude épreuve la mémoire et la batterie. Si votre application les reçoit, utilisez plutôt Android 7.0 pour migrer vers JobScheduler et les API associées.

Pour en savoir plus, consultez la documentation sur les optimisations en arrière-plan.

SurfaceView

Android 7.0 apporte des mouvements synchrones à la classe SurfaceView, ce qui offre de meilleures performances de batterie que TextureView dans certains cas. Lors du rendu de vidéos ou de contenus 3D, les applications avec défilement et position de vidéo animée consomment moins d'énergie avec SurfaceView qu'avec TextureView.

La classe SurfaceView permet une composition à l'écran plus économe en batterie, car elle est composée dans du matériel dédié, séparément du contenu de la fenêtre de l'application. Par conséquent, il effectue moins de copies intermédiaires que TextureView.

La position du contenu d'un objet SurfaceView est désormais mise à jour de manière synchrone avec le contenu de l'application associée. L'une des conséquences de cette modification est que les simples traductions ou échelles d'une vidéo lue dans un SurfaceView ne produisent plus de barres noires à côté de la vue lorsqu'elle se déplace.

À partir d'Android 7.0, nous vous recommandons vivement d'économiser de l'énergie en utilisant SurfaceView au lieu de TextureView.

Économiseur de données

Pendant la durée de vie d'un appareil mobile, le coût d'un forfait de données mobiles dépasse généralement celui de l'appareil lui-même. Pour de nombreux utilisateurs, les données cellulaires sont une ressource coûteuse qu'ils veulent préserver.

Android 7.0 introduit le mode Économiseur de données, un nouveau service système qui permet de réduire l'utilisation de données mobiles par les applications, qu'il s'agisse d'itinérance, vers la fin du cycle de facturation ou sur un petit pack de données prépayé. L'économiseur de données permet aux utilisateurs de contrôler la façon dont les applications utilisent les données mobiles et permet aux développeurs de fournir un service plus efficace lorsque l'économiseur de données est activé.

Lorsqu'un utilisateur active l'économiseur de données dans les paramètres et que l'appareil est connecté à un réseau facturé à l'usage, le système bloque la consommation des données en arrière-plan et indique aux applications d'utiliser moins de données au premier plan dans la mesure du possible (par exemple, en limitant le débit pour le streaming, en réduisant la qualité de l'image, en reportant la mise en cache optimiste, etc.). Les utilisateurs peuvent autoriser des applications spécifiques à autoriser l'utilisation des données facturées à l'usage en arrière-plan même lorsque l'économiseur de données est activé.

Android 7.0 étend ConnectivityManager pour permettre aux applications de récupérer les préférences de l'économiseur de données et de surveiller les modifications de préférences. Toutes les applications doivent vérifier si l'utilisateur a activé l'économiseur de données, et s'efforcer de limiter la consommation de données au premier plan et en arrière-plan.

API Vulkan

Android 7.0 intègre VulkanTM, une nouvelle API de rendu 3D, dans la plate-forme. Tout comme OpenGLTM ES, Vulkan est une norme ouverte pour les graphismes et le rendu 3D, gérée par le groupe Khronos.

Vulkan est conçu dès le départ pour minimiser la surcharge du processeur dans le pilote et permettre à votre application de contrôler plus directement le fonctionnement du GPU. Vulkan permet également d'améliorer la parallélisation en permettant à plusieurs threads d'effectuer simultanément des tâches telles que la construction d'un tampon de commande.

Les outils et bibliothèques de développement Vulkan sont déployés dans le SDK Android 7.0. Exemples:

• En-têtes
• Couches de validation (bibliothèques de débogage)
• Compilateur de nuanceurs SPIR-V
• Bibliothèque de compilation de nuanceurs d'exécution SPIR-V

Vulkan n'est disponible que pour les applications sur les appareils équipés de matériel compatible avec Vulkan, tels que les Nexus 5X, Nexus 6P et Nexus Player. Nous travaillons en étroite collaboration avec nos partenaires pour proposer Vulkan sur davantage d'appareils dès que possible.

Pour en savoir plus, consultez la documentation de l'API.

API Quick Settings Tile

La fenêtre de configuration rapide est un moyen populaire et simple d'afficher les paramètres et les actions clés directement depuis le volet des notifications. Dans Android 7.0, nous avons élargi le champ d'application de la fenêtre de configuration rapide pour la rendre encore plus pratique et pratique.

Nous avons ajouté plus d'espace pour des blocs "Réglages rapides", auxquels les utilisateurs peuvent accéder dans une zone d'affichage paginée en balayant l'écran vers la gauche ou vers la droite. Nous avons également donné aux utilisateurs la possibilité de contrôler quelles tuiles s'affichent et où elles s'affichent. Les utilisateurs peuvent ajouter ou déplacer des cartes simplement en les faisant glisser.

Pour les développeurs, Android 7.0 ajoute également une nouvelle API qui vous permet de définir vos propres blocs "Quick Settings" (Réglages rapides) afin de permettre aux utilisateurs d'accéder facilement aux principales commandes et actions de votre application.

Les blocs "Réglages rapides" sont réservés aux commandes ou actions fréquemment utilisées ou requises en urgence. Ils ne doivent pas être utilisés comme raccourcis pour lancer une application.

Une fois que vous avez défini vos cartes, vous pouvez les présenter aux utilisateurs, qui peuvent les ajouter aux Réglages rapides par simple glisser-déposer.

Pour en savoir plus sur la création d'une carte d'application, consultez la documentation de référence sur Tile.

Blocage de numéros

Android 7.0 est désormais compatible avec le blocage de numéros sur la plate-forme et fournit une API de framework permettant aux fournisseurs de services de gérer une liste de numéros bloqués. L'application de SMS par défaut, l'application de téléphone par défaut et les applications d'opérateurs peuvent lire la liste des numéros bloqués et y écrire des données. Les autres applications n'ont pas accès à cette liste.

En s'appuyant sur le blocage des numéros comme fonctionnalité standard de la plate-forme, Android offre aux applications une méthode cohérente pour prendre en charge le blocage de numéros sur une large gamme d'appareils. Les applications peuvent notamment bénéficier des avantages suivants:

• Les numéros bloqués pendant les appels le sont également pour les SMS
• Les numéros bloqués peuvent persister en cas de réinitialisation et d'appareil via la fonctionnalité de sauvegarde et de restauration
• Plusieurs applications peuvent utiliser la même liste de numéros bloqués

En outre, l'intégration des applications de l'opérateur via Android signifie que les opérateurs peuvent lire la liste des numéros bloqués sur l'appareil et effectuer un blocage côté service afin d'empêcher l'utilisateur d'être contacté par des appels et des messages indésirables par n'importe quel support, comme un point de terminaison VoIP ou des téléphones de transfert.

Pour en savoir plus, consultez la documentation de référence sur BlockedNumberContract.

Filtrage des appels

Android 7.0 permet à l'application téléphonique par défaut de filtrer les appels entrants. Pour ce faire, l'application pour téléphone met en œuvre le nouveau CallScreeningService, qui lui permet d'effectuer un certain nombre d'actions en fonction du Call.Details d'un appel entrant, par exemple:

• Refuser l'appel entrant
• Ne pas autoriser l'appel vers le journal d'appels
• Ne pas afficher de notification pour l'appel à l'utilisateur

Pour en savoir plus, consultez la documentation de référence sur CallScreeningService.

Compatibilité avec plusieurs paramètres régionaux, plus de langues

Android 7.0 permet désormais aux utilisateurs de sélectionner plusieurs paramètres régionaux dans les paramètres pour mieux prendre en charge les cas d'utilisation bilingues. Les applications peuvent utiliser une nouvelle API pour obtenir les paramètres régionaux sélectionnés par l'utilisateur, puis proposer une expérience utilisateur plus sophistiquée aux utilisateurs qui se trouvent dans plusieurs langues. Par exemple, elles peuvent afficher des résultats de recherche dans plusieurs langues sans proposer de traduire des pages Web dans une langue que l'utilisateur connaît déjà.

En plus de la compatibilité avec plusieurs paramètres régionaux, Android 7.0 élargit le nombre de langues disponibles pour les utilisateurs. Elle propose plus de 25 variantes chacune pour les langues couramment utilisées telles que l'anglais, l'espagnol, le français et l'arabe. Par ailleurs, plus de 100 nouvelles langues sont partiellement prises en charge.

Les applications peuvent obtenir la liste des paramètres régionaux définis par l'utilisateur en appelant LocaleList.GetDefault(). Pour prendre en charge le plus grand nombre de paramètres régionaux, Android 7.0 modifie la façon dont il résout les ressources. Assurez-vous de tester et de vérifier que vos applications fonctionnent comme prévu avec la nouvelle logique de résolution des ressources.

Pour en savoir plus sur le nouveau comportement de résolution des ressources et sur les bonnes pratiques à suivre, consultez la page Compatibilité multilingue.

Nouveaux emoji

Android 7.0 introduit des emoji supplémentaires et des fonctionnalités liées aux emoji, y compris les emoji de couleur de peau et la prise en charge de sélecteurs de variante. Si votre application est compatible avec les emoji, suivez les consignes ci-dessous pour profiter de ces fonctionnalités.

• Vérifiez qu'un appareil contient un emoji avant de l'insérer. Pour vérifier quels emoji sont présents dans la police du système, utilisez la méthode hasGlyph(String).
• Vérifiez qu'un emoji est compatible avec les sélecteurs de variantes. Les sélecteurs de variante vous permettent de présenter certains emoji en couleur ou en noir et blanc. Sur les appareils mobiles, les applications doivent représenter les emoji en couleur plutôt qu'en noir et blanc. Toutefois, si votre application affiche des emojis avec du texte, elle doit utiliser la variante en noir et blanc. Pour déterminer si un emoji possède une variante, utilisez le sélecteur de variante. Pour obtenir la liste complète des caractères avec des variantes, consultez la section séquences de variantes d'emoji de la documentation Unicode sur les variantes.
• Vérifiez qu'un emoji est compatible avec la couleur de peau. Android 7.0 permet aux utilisateurs de modifier la couleur de peau des emoji selon leurs préférences. Les applications de clavier doivent fournir des indications visuelles pour les emoji ayant plusieurs carnations et permettre aux utilisateurs de sélectionner celle qu'ils préfèrent. Pour déterminer les emoji système dotés de modificateurs de couleur de peau, utilisez la méthode hasGlyph(String). Pour savoir quels emoji utilisent les carnations, consultez la documentation Unicode.

API ICU4J sur Android

Android 7.0 propose désormais un sous-ensemble d'API ICU4J dans le framework Android sous le package android.icu. La migration est facile et implique principalement de passer simplement de l'espace de noms com.java.icu à android.icu. Si vous utilisez déjà un bundle ICU4J dans vos applications, le passage aux API android.icu fournies dans le framework Android peut vous permettre de réduire considérablement la taille de l'APK.

Pour en savoir plus sur les API ICU4J d'Android, consultez la page Assistance ICU4J.

WebView

Chrome et WebView, ensemble

À partir de la version 51 de Chrome sur Android 7.0 ou version ultérieure, l'APK Chrome sur votre appareil est utilisé pour fournir et afficher les WebViews du système Android. Cette approche améliore l'utilisation de la mémoire sur l'appareil même et réduit la bande passante requise pour maintenir WebView à jour (l'APK WebView autonome ne sera plus mis à jour tant que Chrome restera activé).

Pour choisir votre fournisseur WebView, activez les options pour les développeurs, puis sélectionnez Implémentation de WebView. Vous pouvez utiliser n'importe quelle version de Chrome compatible (en développement, bêta ou stable) installée sur votre appareil, ou l'APK WebView autonome pour l'implémentation de WebView.

Multiprocessus

À partir de la version 51 de Chrome sous Android 7.0, WebView exécute le contenu Web dans un processus distinct en bac à sable lorsque l'option pour les développeurs "Multiprocess WebView" est activée.

Nous attendons vos commentaires sur la compatibilité et les performances d'exécution dans N avant d'activer le multiprocessus WebView dans une prochaine version d'Android. Dans cette version, des régressions au niveau du temps de démarrage, de l'utilisation totale de la mémoire et des performances d'affichage logiciel sont attendues.

Si vous rencontrez des problèmes inattendus en mode multiprocessus, n'hésitez pas à nous en faire part. Veuillez contacter l'équipe WebView à l'aide de l'outil de suivi des bugs Chromium.

JavaScript s'exécute avant le chargement de la page

À partir des applications ciblant Android 7.0, le contexte JavaScript sera réinitialisé lors du chargement d'une nouvelle page. Actuellement, le contexte est reporté pour la première page chargée dans une nouvelle instance WebView.

Les développeurs qui souhaitent injecter du code JavaScript dans WebView doivent exécuter le script une fois que la page a commencé à se charger.

Géolocalisation sur des origines non sécurisées

À partir des applications ciblant Android 7.0, l'API de géolocalisation ne sera autorisée que sur les origines sécurisées (via HTTPS). Cette règle est conçue pour protéger les informations privées des utilisateurs lorsqu'ils utilisent une connexion non sécurisée.

Tester avec WebView Bêta

WebView est mis à jour régulièrement. Par conséquent, nous vous recommandons de tester fréquemment la compatibilité avec votre application à l'aide de sa version bêta. Pour commencer à tester les versions préliminaires de WebView sur Android 7.0, téléchargez et installez Chrome pour les développeurs ou la version bêta de Chrome, puis sélectionnez-la comme implémentation de WebView dans les options pour les développeurs, comme décrit ci-dessus. Veuillez signaler les problèmes via l'outil de suivi des bugs Chromium pour que nous puissions les corriger avant qu'une nouvelle version de WebView soit disponible.

API OpenGLTM ES 3.2

Android 7.0 ajoute des interfaces de framework et est compatible avec les plates-formes OpenGL ES 3.2, y compris:

• Toutes les extensions du pack d'extensions Android (AEP), à l'exception de EXT_texture_sRGB_decode.
• Tampons de frame en virgule flottante pour HDR et ombrage différé.
• Appels de dessin BaseVertex pour améliorer le traitement par lot et par flux.
• Contrôle d'accès robuste pour le tampon pour réduire la surcharge WebGL.

L'API de framework pour OpenGL ES 3.2 sur Android 7.0 est fournie avec la classe GLES32. Lorsque vous utilisez OpenGL ES 3.2, veillez à le déclarer dans votre fichier manifeste, à l'aide de la balise <uses-feature> et de l'attribut android:glEsVersion.

Pour en savoir plus sur l'utilisation d'OpenGL ES, y compris sur la vérification de la version compatible d'OpenGL ES d'un appareil au moment de l'exécution, consultez le guide de l'API OpenGL ES.

Enregistrement Android TV

Android 7.0 permet d'enregistrer et de lire du contenu à partir des services d'entrée Android TV via de nouvelles API d'enregistrement. En s'appuyant sur les API de décalage temporel existantes, les services d'entrée TV peuvent contrôler quelles données de canal peuvent être enregistrées et comment les sessions enregistrées sont sauvegardées, et gérer les interactions des utilisateurs avec le contenu enregistré.

Pour en savoir plus, consultez API Android TV Recording.

Android for Work

Android for Work ajoute de nombreuses nouvelles fonctionnalités et API pour les appareils équipés d'Android 7.0. Voici quelques points forts. Pour obtenir la liste complète des fonctionnalités, consultez la liste des fonctionnalités d'Android Enterprise.

Test de sécurité du profil professionnel

Les propriétaires de profils ciblant le SDK N peuvent spécifier un défi de sécurité distinct pour les applications exécutées dans le profil professionnel. La question d'authentification professionnelle s'affiche lorsqu'un utilisateur tente d'ouvrir des applications professionnelles. Si le test de sécurité réussit, le profil professionnel est déverrouillé et le déchiffrer si nécessaire. Pour les propriétaires de profils, ACTION_SET_NEW_PASSWORD invite l'utilisateur à définir une question d'authentification professionnelle, et ACTION_SET_NEW_PARENT_PROFILE_PASSWORD l'invite à définir un verrouillage de l'appareil.

Les propriétaires de profils peuvent définir des règles de code secret distinctes pour le défi professionnel (telles que la durée minimale du code PIN ou si une empreinte digitale peut être utilisée pour déverrouiller le profil) à l'aide de setPasswordQuality(), de setPasswordMinimumLength() et des méthodes associées. Le propriétaire du profil peut également définir le verrouillage de l'appareil à l'aide de l'instance DevicePolicyManager renvoyée par la nouvelle méthode getParentProfileInstance(). De plus, les propriétaires de profils peuvent personnaliser l'écran des identifiants pour le défi professionnel à l'aide des nouvelles méthodes setOrganizationColor() et setOrganizationName().

Désactiver les applications professionnelles

Sur un appareil avec un profil professionnel, les utilisateurs peuvent activer/désactiver le mode professionnel. Lorsque le mode professionnel est désactivé, l'utilisateur géré est temporairement arrêté, ce qui désactive les applications du profil professionnel, la synchronisation en arrière-plan et les notifications. Cela inclut l'application de propriétaire de profil. Lorsque le mode Travail est désactivé, le système affiche une icône d'état persistante pour rappeler à l'utilisateur qu'il ne peut pas lancer d'applications professionnelles. Le lanceur d'applications indique que les applications et les widgets professionnels ne sont pas accessibles.

VPN permanent

Les propriétaires d'appareils et de profils peuvent s'assurer que les applications professionnelles se connectent toujours via un VPN spécifié. Le système lance automatiquement ce VPN après le démarrage de l'appareil.

Les nouvelles méthodes DevicePolicyManager sont setAlwaysOnVpnPackage() et getAlwaysOnVpnPackage().

Étant donné que les services VPN peuvent être liés directement par le système sans interaction de l'application, les clients VPN doivent gérer les nouveaux points d'entrée pour le VPN permanent. Comme précédemment, les services sont indiqués au système par un filtre d'intent correspondant à l'action android.net.VpnService.

Les utilisateurs peuvent également définir manuellement l'option "Toujours sur les clients VPN qui implémentent les méthodes VPNService" via Paramètres > Plus > Vpn. L'option permettant d'activer le VPN permanent dans les paramètres n'est disponible que si le client VPN cible le niveau d'API 24.

Provisionnement personnalisé

Une application peut personnaliser les flux de provisionnement du propriétaire du profil et du propriétaire de l'appareil avec des couleurs et des logos d'entreprise. DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR personnalise la couleur de flux. DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI personnalise le flux avec un logo d'entreprise.

Améliorations de l'accessibilité

Android 7.0 propose désormais les paramètres Vision directement sur l'écran d'accueil pour la configuration d'un nouvel appareil. Cela permet aux utilisateurs de découvrir et de configurer beaucoup plus facilement les fonctionnalités d'accessibilité sur leurs appareils, y compris le geste d'agrandissement, la taille de la police, la taille d'affichage et TalkBack.

Les fonctionnalités d'accessibilité étant plus visibles, vos utilisateurs sont plus susceptibles de tester votre application lorsqu'elles sont activées. Veillez à tester vos applications le plus tôt possible avec ces paramètres activés. Vous pouvez les activer dans Paramètres > Accessibilité.

Toujours dans Android 7.0, les services d'accessibilité peuvent désormais aider les utilisateurs souffrant d'un handicap moteur à toucher l'écran. La nouvelle API permet de créer des services comportant des fonctionnalités telles que le suivi des visages, le suivi oculaire, la numérisation par point, etc., afin de répondre aux besoins de ces utilisateurs.

Pour en savoir plus, consultez la documentation de référence sur GestureDescription.

Démarrage direct

Le démarrage direct réduit le temps de démarrage de l'appareil et permet aux applications enregistrées de disposer de fonctionnalités limitées, même après un redémarrage inattendu. Par exemple, si un appareil chiffré redémarre pendant que l'utilisateur est en veille, les alarmes, les messages et les appels entrants enregistrés peuvent désormais continuer à avertir l'utilisateur comme d'habitude. Cela signifie également que les services d'accessibilité peuvent également être disponibles immédiatement après un redémarrage.

Le démarrage direct exploite le chiffrement basé sur les fichiers dans Android 7.0 afin d'appliquer des règles de chiffrement précises pour les données du système et des applications. Le système utilise un magasin chiffré par appareil pour certaines données système et les données d'application explicitement enregistrées. Par défaut, un magasin chiffré par identifiants est utilisé pour toutes les autres données système, données utilisateur, applications et données d'application.

Au démarrage, le système démarre en mode restreint avec un accès uniquement aux données chiffrées de l'appareil, sans accès général aux applications ou aux données. Si vous souhaitez exécuter des composants dans ce mode, vous pouvez les enregistrer en définissant un indicateur dans le fichier manifeste. Après le redémarrage, le système active les composants enregistrés en diffusant l'intent LOCKED_BOOT_COMPLETED. Le système s'assure que les données d'application chiffrées de l'appareil enregistrées sont disponibles avant le déverrouillage. Toutes les autres données ne sont pas disponibles tant que l'utilisateur n'a pas confirmé ses identifiants sur l'écran de verrouillage pour les déchiffrer.

Pour en savoir plus, consultez la section Démarrage direct.

Attestation des clés

Android 7.0 introduit l'attestation de clé, un nouvel outil de sécurité qui vous aide à vous assurer que les paires de clés stockées dans le keystore intégré au matériel d'un appareil protègent correctement les informations sensibles utilisées par votre application. Grâce à cet outil, vous avez la certitude que votre application interagit avec des clés hébergées dans du matériel sécurisé, même si l'appareil qui exécute votre application est en mode root. Si vous utilisez les clés du keystore intégré au matériel dans vos applications, nous vous conseillons d'utiliser cet outil, en particulier si vous utilisez les clés pour valider des informations sensibles dans votre application.

L'attestation de clé vous permet de vérifier qu'une paire de clés RSA ou EC a été créée et stockée dans le keystore intégré au matériel d'un appareil, au sein de son environnement d'exécution sécurisé (TEE). Cet outil vous permet également d'utiliser un service hors appareil, tel que le serveur backend de votre application, pour déterminer et vérifier fortement les utilisations et la validité de la paire de clés. Ces fonctionnalités offrent un niveau de sécurité supplémentaire qui protège la paire de clés, même si quelqu'un lance l'appareil en mode root ou compromet la sécurité de la plate-forme Android exécutée sur l'appareil.

Remarque : Seul un petit nombre d'appareils exécutant Android 7.0 sont compatibles avec l'attestation de clé au niveau du matériel. Tous les autres appareils exécutant Android 7.0 utilisent l'attestation de clé au niveau du logiciel à la place. Avant de valider les propriétés des clés intégrées au matériel d'un appareil dans un environnement de production, vous devez vous assurer que l'appareil est compatible avec l'attestation de clé au niveau du matériel. Pour ce faire, vous devez vérifier que la chaîne de certificats d'attestation contient un certificat racine signé par la clé racine d'attestation Google et que l'élément attestationSecurityLevel dans la structure de données de la description de clé est défini sur le niveau de sécurité TrustedEnvironment.

Pour en savoir plus, consultez la documentation pour les développeurs sur l'attestation de clé.

Configuration de la sécurité réseau

Dans Android 7.0, les applications peuvent personnaliser le comportement de leurs connexions sécurisées (HTTPS, TLS) de manière sécurisée, sans aucune modification de code, à l'aide de la configuration de sécurité réseau déclarative au lieu d'utiliser les API programmatiques traditionnelles sources d'erreurs (par exemple, X509TrustManager).

Fonctionnalités compatibles:

• Ancres de confiance personnalisées : Permet à une application de personnaliser les autorités de certification approuvées pour ses connexions sécurisées. Par exemple, vous pouvez approuver des certificats autosignés spécifiques ou un ensemble restreint d'autorités de certification publiques.
• Forçages réservés au débogage. Permet à un développeur d'applications de déboguer en toute sécurité les connexions sécurisées de son application sans risque supplémentaire pour la base installée.
• Désactivation du trafic en texte clair Permet à une application de se protéger contre l'utilisation accidentelle du trafic en texte clair.
• Épinglage de certificats : Fonctionnalité avancée qui permet à une application de limiter les clés de serveur approuvées pour les connexions sécurisées.

Pour en savoir plus, consultez la section Configuration de la sécurité réseau.

Autorité de certification de confiance par défaut

Par défaut, les applications qui ciblent Android 7.0 n'approuvent que les certificats fournis par le système et ne font plus confiance aux autorités de certification ajoutées par l'utilisateur. Les applications ciblant Android 7.0 (niveau d'API 24) qui souhaitent approuver des autorités de certification ajoutées par l'utilisateur doivent utiliser la configuration de sécurité réseau pour spécifier le niveau de confiance des autorités de certification utilisateur.

APK Signature Scheme v2

Android 7.0 introduit APK Signature Scheme v2, un nouveau schéma de signature d'application qui offre des temps d'installation d'applications plus rapides et une meilleure protection contre les modifications non autorisées des fichiers APK. Par défaut, Android Studio 2.2 et le plug-in Android pour Gradle 2.2 signent votre application à l'aide de APK Signature Scheme v2 et du schéma de signature traditionnel, qui utilise la signature JAR.

Bien que nous vous recommandions d'appliquer APK Signature Scheme v2 à votre application, ce nouveau schéma n'est pas obligatoire. Si votre application ne se compile pas correctement lorsque vous utilisez APK Signature Scheme v2, vous pouvez désactiver le nouveau schéma. Lors de la désactivation, Android Studio 2.2 et le plug-in Android pour Gradle 2.2 ne signent votre application qu'à l'aide du schéma de signature traditionnel. Pour signer uniquement avec le schéma traditionnel, ouvrez le fichier build.gradle au niveau du module, puis ajoutez la ligne v2SigningEnabled false à votre configuration de signature de version:

  android {
    ...
    defaultConfig { ... }
    signingConfigs {
      release {
        storeFile file("myreleasekey.keystore")
        storePassword "password"
        keyAlias "MyReleaseKey"
        keyPassword "password"
        v2SigningEnabled false
      }
    }
  }

Attention : Si vous signez votre application avec APK Signature Scheme v2 et que vous y apportez des modifications supplémentaires, la signature de l'application n'est plus valide. C'est pourquoi vous devez utiliser des outils tels que zipalign avant de signer votre application à l'aide de APK Signature Scheme v2, et non après.

Pour en savoir plus, consultez les documents Android Studio qui expliquent comment signer une application dans Android Studio et comment configurer le fichier de compilation pour signer des applications à l'aide du plug-in Android pour Gradle.

Accès à l'annuaire limité

Dans Android 7.0, les applications peuvent utiliser de nouvelles API pour demander l'accès à des répertoires de stockage externe spécifiques, y compris des répertoires se trouvant sur des supports amovibles tels que des cartes SD. Les nouvelles API simplifient considérablement la manière dont votre application accède aux répertoires de stockage externe standards, tels que le répertoire Pictures. Des applications telles que des applications photo peuvent utiliser ces API au lieu d'READ_EXTERNAL_STORAGE, qui accorde l'accès à tous les répertoires de stockage, ou de Storage Access Framework, qui permet à l'utilisateur d'accéder au répertoire.

De plus, les nouvelles API simplifient les étapes qu'un utilisateur suit pour accorder l'accès au stockage externe à votre application. Lorsque vous utilisez les nouvelles API, le système utilise une interface utilisateur d'autorisation simple qui détaille clairement le répertoire auquel l'application demande l'accès.

Pour en savoir plus, consultez la documentation sur l'accès cloisonné à l'annuaire pour les développeurs.

Outil d'aide pour les raccourcis clavier

Dans Android 7.0, l'utilisateur peut appuyer sur Méta+ / pour afficher un écran Raccourcis clavier qui affiche tous les raccourcis disponibles à partir du système et de l'application sélectionnée. Le système récupère automatiquement ces raccourcis à partir du menu de l'application s'ils existent. Vous pouvez également fournir vos propres listes de raccourcis affinées pour l'écran. Pour ce faire, remplacez la méthode onProvideKeyboardShortcuts().

Remarque : La touche Méta n'est pas présente sur tous les claviers. Sur un clavier Macintosh, il s'agit de la touche Commande. Pour le clavier Windows, il s'agit de la touche Windows. Sur la Pixel C et les claviers ChromeOS, il s'agit de la touche Recherche.

Pour déclencher l'outil d'aide aux raccourcis clavier depuis n'importe quelle page de votre application, appelez requestShowKeyboardShortcuts() à partir de l'activité concernée.

API Custom Pointer

Android 7.0 introduit l'API Custom Pointer, qui vous permet de personnaliser l'apparence, la visibilité et le comportement du pointeur. Cette fonctionnalité est particulièrement utile lorsqu'un utilisateur interagit avec des objets d'interface utilisateur à l'aide d'une souris ou d'un pavé tactile. Le pointeur par défaut utilise une icône standard. Cette API inclut également des fonctionnalités avancées, telles que la modification de l'apparence de l'icône du pointeur en fonction des mouvements spécifiques de la souris ou du pavé tactile.

Pour définir une icône de pointeur, remplacez la méthode onResolvePointerIcon() de la classe View. Cette méthode utilise un objet PointerIcon pour dessiner l'icône correspondant à un événement de mouvement spécifique.

API Sustained Performance

Les performances peuvent fluctuer considérablement pour les applications de longue durée, car le système régule les moteurs système sur puce lorsque les composants de l'appareil atteignent leur limite de température. Cette fluctuation représente une cible mouvante pour les développeurs qui créent des applications hautes performances de longue durée.

Pour résoudre ces limites, Android 7.0 est compatible avec le mode Performances soutenues, qui permet aux OEM de fournir des indications sur les fonctionnalités de performances des appareils pour les applications de longue durée. Les développeurs d'applications peuvent utiliser ces suggestions pour régler les applications afin d'obtenir un niveau de performances prévisible et cohérent sur de longues périodes.

Les développeurs d'applications ne peuvent essayer cette nouvelle API dans Android 7.0 que sur les appareils Nexus 6P. Pour utiliser cette fonctionnalité, définissez l'indicateur de fenêtre de performances soutenues pour la fenêtre que vous souhaitez exécuter en mode Performances soutenues. Définissez cet indicateur à l'aide de la méthode Window.setSustainedPerformanceMode(). Le système désactive automatiquement ce mode lorsque la fenêtre n'est plus active.

Compatibilité RV

Android 7.0 prend en charge la plate-forme et optimise un nouveau mode RV afin de permettre aux développeurs de créer des expériences de RV sur mobile de haute qualité pour les utilisateurs. Il existe un certain nombre d'améliorations des performances, y compris l'accès à un cœur de processeur exclusif pour les applications de RV. Dans vos applications, vous pouvez bénéficier du suivi intelligent de la tête et des notifications stéréo compatibles avec la RV. Plus important encore, Android 7.0 fournit des graphiques à très faible latence. Pour obtenir des informations complètes sur la création d'applications de RV pour Android 7.0, consultez la page SDK Google VR pour Android.

Améliorations du service d'impression

Dans Android 7.0, les développeurs de services d'impression peuvent désormais afficher des informations supplémentaires sur des imprimantes et des tâches d'impression individuelles.

Lorsqu'il liste des imprimantes individuelles, un service d'impression peut désormais définir des icônes pour chaque imprimante de deux manières:

• Vous pouvez définir une icône à partir d'un ID de ressource en appelant setIconResourceId().
• Vous pouvez afficher une icône du réseau en appelant setHasCustomPrinterIcon() et en définissant un rappel lorsque l'icône est demandée à l'aide de onRequestCustomPrinterIcon().

En outre, vous pouvez fournir une activité par imprimante pour afficher des informations supplémentaires en appelant setInfoIntent().

Vous pouvez indiquer la progression et l'état des tâches d'impression dans la notification correspondante en appelant setProgress() et setStatus(), respectivement.

API Frame Metrics

L'API Frame Metrics permet à une application de surveiller les performances de rendu de l'interface utilisateur. L'API offre cette fonctionnalité en exposant une API Pub/Sub en streaming pour transférer les informations de temps de rendu pour la fenêtre actuelle de l'application. Les données renvoyées sont équivalentes à celles affichées par adb shell dumpsys gfxinfo framestats, mais ne se limitent pas aux 120 dernières trames.

Vous pouvez utiliser l'API Frame Metrics pour mesurer les performances de l'interface utilisateur au niveau de l'interaction en production, sans connexion USB. Cette API permet de collecter des données avec une précision beaucoup plus élevée que adb shell dumpsys gfxinfo. Cette précision accrue est possible, car le système peut collecter des données pour des interactions particulières dans l'application. Le système n'a pas besoin de capturer un résumé global des performances de l'ensemble de l'application ni d'effacer un état global. Vous pouvez utiliser cette fonctionnalité pour collecter des données sur les performances et détecter les régressions dans les performances de l'interface utilisateur pour des cas d'utilisation réels dans une application.

Pour surveiller une fenêtre, implémentez la méthode de rappel OnFrameMetricsAvailableListener.onFrameMetricsAvailable() et enregistrez-la dans cette fenêtre.

L'API fournit un objet FrameMetrics, qui contient des données temporelles signalées par le sous-système de rendu pour différents jalons du cycle de vie des frames. Les métriques acceptées sont les suivantes: UNKNOWN_DELAY_DURATION, INPUT_HANDLING_DURATION, ANIMATION_DURATION, LAYOUT_MEASURE_DURATION, DRAW_DURATION, SYNC_DURATION, COMMAND_ISSUE_DURATION, SWAP_BUFFERS_DURATION, TOTAL_DURATION et FIRST_DRAW_FRAME.

Fichiers virtuels

Dans les versions précédentes d'Android, votre application pouvait utiliser Storage Access Framework pour permettre aux utilisateurs de sélectionner des fichiers dans leurs comptes de stockage cloud, tels que Google Drive. Cependant, il n'y avait aucun moyen de représenter des fichiers qui n'avaient pas de représentation bytecode directe. Chaque fichier était requis pour fournir un flux d'entrée.

Android 7.0 ajoute le concept de fichiers virtuels au framework d'accès au stockage. La fonctionnalité de fichiers virtuels permet à votre DocumentsProvider de renvoyer des URI de document pouvant être utilisés avec un intent ACTION_VIEW, même s'ils n'ont pas de représentation bytecode directe. Android 7.0 vous permet également de fournir d'autres formats de fichiers utilisateur, virtuels ou autres.

Pour en savoir plus sur l'ouverture de fichiers virtuels, consultez la page Ouvrir des fichiers virtuels dans le guide Storage Access Frameworks.