En plus des nouvelles fonctionnalités et capacités, Android 7.0 comprend divers changements de comportement au niveau du système et des API. Ce document met en évidence certains des changements clés que vous devez comprendre et tenir compte dans vos applications.
Si vous avez déjà publié une application pour Android, sachez qu'elle peuvent être affectés par ces changements sur la plate-forme.
Batterie et mémoire
Android 7.0 inclut des modifications de comportement du système visant à améliorer l'autonomie de la batterie d'appareils et la réduction de l'utilisation de la RAM. Ces changements peuvent affecter l'accès de votre application aux ressources système, ainsi que la manière dont votre application interagit avec d'autres applications via certains intents implicites.
Sommeil
Introduit dans Android 6.0 (niveau d'API 23), la fonctionnalité Sommeil améliore l'autonomie de la batterie de reportant les activités du processeur et du réseau lorsqu'un utilisateur laisse un appareil débranché, à l'arrêt et avec l'écran éteint. Android 7.0 vous offre encore plus de possibilités Améliorations apportées à la fonctionnalité Sommeil en appliquant un sous-ensemble de restrictions de processeur et de réseau lorsque l'appareil est débranché avec l'écran éteint, mais pas nécessairement immobile, par exemple lorsqu'un appareil mobile se déplace dans la poche d'un utilisateur.
Lorsqu'un appareil est sur batterie et que l'écran est éteint depuis un certain temps
l'appareil passe en mode Sommeil et applique le premier sous-ensemble de restrictions :
désactive l'accès au réseau des applications, et reporte les tâches et les synchronisations. Si l'appareil est
à l'arrêt pendant un certain temps après l'activation du mode Sommeil, le système applique
le reste des restrictions de la fonctionnalité Sommeil pour PowerManager.WakeLock
,
Alarmes AlarmManager
, recherches GPS et réseaux Wi-Fi. Indépendamment de
que certaines ou toutes les restrictions Sommeil soient appliquées, le système active le
appareil pendant de courtes périodes de maintenance durant lesquelles les applications sont autorisées
un accès réseau et peut exécuter
tout job/synchronisation différé.
Lorsque vous activez l'écran ou branchez l'appareil, vous quittez le mode Sommeil et supprime ces restrictions de traitement. Ce comportement supplémentaire affectent les recommandations et les bonnes pratiques pour adapter votre application version de Sommeil introduite dans Android 6.0 (niveau d'API 23), comme indiqué dans <ph type="x-smartling-placeholder"></ph> Optimisation pour les fonctionnalités Sommeil et Mise en veille des applications Vous devez toujours suivez ces recommandations, par exemple en utilisant Firebase Cloud Messaging (FCM) pour d'envoyer et de recevoir des messages, et de planifier les mises à jour pour vous adapter un comportement supplémentaire du mode Sommeil.
Projet Svelte: optimisations en arrière-plan
Android 7.0 supprime trois diffusions implicites afin d'optimiser les deux l'utilisation de la mémoire et la consommation d'énergie. Cette modification est nécessaire car les couches implicites annonces lancent fréquemment des applications qui se sont inscrites pour les écouter en arrière-plan. La suppression de ces annonces peut s'avérer très bénéfique pour l'appareil les performances et l'expérience utilisateur.
La connectivité des appareils mobiles change fréquemment, par exemple lorsqu'ils sont en mouvement
entre le Wi-Fi et les données mobiles. Actuellement, les applications peuvent surveiller les modifications
la connectivité en enregistrant un récepteur pour la diffusion CONNECTIVITY_ACTION
implicite dans sa
fichier manifeste. Étant donné que de nombreuses applications s'inscrivent pour recevoir cette annonce, une seule
un commutateur réseau peut les faire tous
activer et traiter la diffusion à
une seule fois.
De même, dans les versions précédentes d'Android, les applications pouvaient s'inscrire pour recevoir des annonces ACTION_NEW_PICTURE
et ACTION_NEW_VIDEO
implicites d'autres applications, telles que
Caméra. Lorsqu'un utilisateur prend une photo avec l'application Appareil photo, ces applications s'activent.
pour traiter la diffusion.
Pour atténuer ces problèmes, Android 7.0 applique les d'optimisation:
- Les applications ciblant Android version 7.0 (niveau 24 d'API) et ultérieures ne reçoivent pas les diffusions
CONNECTIVITY_ACTION
s'ils déclarent leur récepteur de diffusion dans le fichier manifeste. Les applications continueront à recevoir des diffusionsCONNECTIVITY_ACTION
si elles enregistrent leurBroadcastReceiver
auprès deContext.registerReceiver()
et que ce contexte est toujours valide. - Le système n'envoie plus d'annonces
ACTION_NEW_PICTURE
niACTION_NEW_VIDEO
. Cette optimisation affecte toutes les applications, pas seulement celles qui ciblent Android 7.0.
Si votre appli utilise l'un de ces intents, vous devez supprimer les dépendances
dès que possible, afin de cibler correctement les appareils Android 7.0.
Le framework Android fournit plusieurs solutions pour atténuer le besoin
ces diffusions implicites. Par exemple, l'API JobScheduler
fournit un mécanisme robuste pour planifier
des opérations réseau lorsque les conditions spécifiées, telles que la connexion à un
réseau illimité sont remplis. Vous pouvez même utiliser JobScheduler
pour réagir aux modifications apportées aux fournisseurs de contenu.
Pour en savoir plus sur les optimisations en arrière-plan dans Android 7.0 (niveau d'API), 24) et comment adapter votre application, consultez la section Arrière-plan Optimisations.
Modifications des autorisations
Android 7.0 apporte des modifications aux autorisations qui peuvent affecter votre application.
Modifications des autorisations du système de fichiers
Afin d'améliorer la sécurité des fichiers privés, le répertoire privé des
les applications ciblant Android 7.0 ou version ultérieure ont un accès limité (0700
).
Ce paramètre empêche la fuite des métadonnées des fichiers privés, comme leur taille.
ou de leur existence. Cette modification d'autorisation a plusieurs effets secondaires:
-
Le propriétaire ne doit plus assouplir les autorisations d'accès aux fichiers privés.
et si vous essayez de le faire
MODE_WORLD_READABLE
et/ouMODE_WORLD_WRITEABLE
déclenche uneSecurityException
Remarque:Pour le moment, cette restriction n'est pas pleinement appliquée. Les applis peuvent toujours modifier les autorisations d'accès à leur répertoire privé à l'aide de les API natives ou l'API
File
. Cependant, nous vous recommandons décourager l'assouplissement des autorisations sur le répertoire privé. -
La transmission d'URI
file://
en dehors du domaine du package peut laisser le récepteur avec un chemin d'accès inaccessible. Par conséquent, nous essayons de transmettre L'URIfile://
déclenche uneFileUriExposedException
La méthode recommandée pour partager le contenu d'un fichier privé utiliseFileProvider
. -
L'utilisateur
DownloadManager
ne peut plus partager de contenu en mode privé stockés par nom de fichier. Les anciennes applications peuvent se retrouver chemin inaccessible lors de l'accès àCOLUMN_LOCAL_FILENAME
. Ciblage par applications Android 7.0 ou version ultérieure déclenche uneSecurityException
lorsque tente d'accéderCOLUMN_LOCAL_FILENAME
Les anciennes applications qui définissent l'emplacement de téléchargement sur un emplacement public en avecDownloadManager.Request.setDestinationInExternalFilesDir()
ouDownloadManager.Request.setDestinationInExternalPublicDir()
peut toujours accéder au chemin dansCOLUMN_LOCAL_FILENAME
, en revanche, est vivement déconseillée. La méthode privilégiée pour accéder à un fichier exposé parDownloadManager
utiliseContentResolver.openFileDescriptor()
Partager des fichiers entre des applications
Pour les applications ciblant Android 7.0, le framework Android applique
La règle d'API StrictMode
qui interdit l'exposition des URI file://
en dehors de votre application. Si un intent contenant un URI de fichier quitte votre application, celle-ci échoue
avec une exception FileUriExposedException
.
Pour partager des fichiers entre des applications, vous devez envoyer un URI content://
.
et accorder une autorisation d'accès temporaire à l'URI. Le moyen le plus simple d'accorder
cette autorisation est de
à l'aide de la classe FileProvider
. Pour en savoir plus,
sur les autorisations et
le partage de fichiers,
consultez la page Partager des fichiers.
Améliorations liées à l'accessibilité
Android 7.0 inclut des modifications destinées à améliorer la convivialité du pour les utilisateurs malvoyants. Ces modifications devraient ne nécessitent généralement pas de modifications du code de votre application, mais vous devez ces fonctionnalités et les tester avec votre application pour évaluer leur impact potentiel sur les utilisateurs expérience.
Zoom sur l'écran
Android 7.0 permet aux utilisateurs de définir la taille d'affichage, qui agrandit ou réduit tous les éléments de l'écran, améliorant ainsi l'accessibilité de l'appareil pour les utilisateurs malvoyants. Les utilisateurs ne peuvent pas zoomer sur l'écran au-delà d'une limite minimale largeur de sw320dp, qui correspond à la largeur d'un Nexus 4, un téléphone de taille moyenne couramment utilisé.
Lorsque la densité de l'appareil change, le système notifie les applications en cours d'exécution dans le de différentes manières:
- Si une application cible un niveau d'API 23 ou inférieur, le système se ferme automatiquement. tous ses processus en arrière-plan. Cela signifie que si un utilisateur quitte une application de ce type pour ouvrir l'écran Settings (Paramètres) et modifier le paramètre Taille d'affichage, le système ferme l'application qu'en cas de mémoire insuffisante. Si l'application a un premier plan processus, le système informe ces processus du changement de configuration décrits dans la section Manipulation Modifications apportées à l'environnement d'exécution, comme si l'orientation de l'appareil avait changé.
- Si une application cible Android 7.0, tous ses processus (premier plan et arrière-plan) sont informés du changement de configuration décrits dans la section Manipulation Modifications apportées à l'environnement d'exécution.
La plupart des applications n'ont pas besoin d'apporter de modifications pour prendre en charge cette fonctionnalité, à condition les applications respectent les bonnes pratiques Android. Points spécifiques à vérifier:
- Tester votre application sur un appareil avec une largeur d'écran de
sw320dp
et vous assurer qu'elle fonctionne correctement. - Lorsque la configuration de l'appareil change, mettez à jour les paramètres
les informations mises en cache, telles que les bitmaps mis en cache ou les ressources chargées à partir du
réseau. Rechercher des modifications de configuration lorsque l'application reprend à partir de l'état mis en pause
de l'état.
Remarque:Si vous mettez en cache des données dépendantes de la configuration, il s'agit d'un il est conseillé d'inclure des métadonnées pertinentes, telles que l'écran approprié ou la densité en pixels de ces données. L'enregistrement de ces métadonnées vous permet de : décider si vous devez actualiser les données mises en cache après une configuration ; le changement.
- Évitez de spécifier des dimensions en px, car elles n'effectuent pas la mise à l'échelle avec
comme la densité de l'écran. Spécifiez plutôt des dimensions avec des valeurs indépendantes de la densité
pixels (
dp
).
Paramètres Vision dans l'assistant de configuration
Android 7.0 inclut des paramètres visuels sur l'écran d'accueil, qui permet aux utilisateurs configurez les paramètres d'accessibilité suivants sur un nouvel appareil: Geste d'agrandissement, Taille de la police, Taille d'affichage et TalkBack. Cette modification augmente la visibilité des bugs liés aux différents paramètres de l'écran. À évaluez l'impact de cette fonctionnalité, testez vos applications avec ces paramètres activés. Vous trouverez ces paramètres sous Paramètres > Accessibilité.
Association des applications du NDK aux bibliothèques de la plate-forme
À partir d'Android 7.0, le système empêche les applications de s'associer dynamiquement contre les bibliothèques non NDK, ce qui peut entraîner le plantage de votre application. Ce changement dans vise à créer une expérience cohérente dans l'application lors des mises à jour de la plate-forme. et différents appareils. Même si votre code ne contient pas de lien bibliothèques privées, il est possible qu'une bibliothèque statique tierce application pourrait le faire. Par conséquent, tous les développeurs doivent vérifier afin que leurs applications ne plantent pas sur les appareils équipés d'Android 7.0. Si votre application utilise code natif, vous ne devez utiliser que des API NDK publiques.
Votre application peut tenter d'accéder à une plate-forme privée de trois façons différentes API:
- Votre application accède directement aux bibliothèques de plates-formes privées. Vous devez mettre à jour votre application pour inclure sa propre copie de ces bibliothèques ou utiliser les API NDK publiques.
- Votre application utilise une bibliothèque tierce qui accède à une plate-forme privée bibliothèques. Même si vous êtes certain que votre application n'a pas accès à des bibliothèques privées vous devez quand même tester votre application dans ce scénario.
- Votre application fait référence à une bibliothèque qui n'est pas incluse dans son APK. Pour
exemple, cela peut se produire si vous avez essayé
d’utiliser votre propre copie d’OpenSSL, mais
oublié de l'intégrer à l'APK de votre application ; L'appli peut s'exécuter normalement sur les versions
de la plate-forme Android, y compris
libcrypto.so
. Cependant, l'application pourrait planter sur les versions ultérieures d'Android qui n'incluent pas cette bibliothèque (par exemple, Android 6.0 et versions ultérieures). Pour résoudre ce problème, assurez-vous de regrouper tous vos bibliothèques non NDK avec votre APK.
Les applications ne doivent pas utiliser de bibliothèques natives qui ne sont pas incluses dans le NDK, car ils peuvent changer ou être supprimés d’une version à l’autre d’Android. La passer d’OpenSSL à BoringSSL en est un exemple. Par ailleurs, car il n'existe aucune exigence de compatibilité pour les bibliothèques de plate-forme. inclus dans le NDK, différents appareils peuvent offrir différents niveaux de et la compatibilité avec d'autres appareils.
Afin de réduire l'impact que cette restriction peut avoir sur
applications publiées, un ensemble de bibliothèques dont l'utilisation est importante, comme
libandroid_runtime.so
, libcutils.so
libcrypto.so
et libssl.so
sont temporairement
accessible sur Android 7.0 (niveau d'API 24) pour les applications ciblant le niveau d'API 23 ou
moins élevée. Si votre application charge l'une de ces bibliothèques, Logcat génère un avertissement.
et un toast s'affiche sur l'appareil cible pour vous en informer. Si ces
vous devez mettre à jour votre application pour inclure sa propre copie de ces
ou n'utilisez que les API NDK publiques. Prochaines versions d'Android
peut limiter l'utilisation des bibliothèques privées
l'application peut planter.
Toutes les applications génèrent une erreur d'exécution lorsqu'elles appellent une API qui n'est ni
publics ni temporairement accessibles. Résultat :
System.loadLibrary
et dlopen(3)
reviennent tous les deux
NULL
, et peut entraîner le plantage de votre application. Nous vous recommandons de vérifier
code d'application pour supprimer l'utilisation d'API de plate-forme privée et tester minutieusement vos applications
à l'aide d'un appareil ou d'un émulateur exécutant Android 7.0 (niveau d'API 24) ; Si vous utilisez
vous n'êtes pas certain que votre application utilise des bibliothèques privées, vous pouvez consulter Logcat pour identifier l'erreur d'exécution.
Le tableau suivant décrit le comportement attendu d'une
en fonction de son utilisation des bibliothèques natives privées et de son API cible
niveau (android:targetSdkVersion
).
Bibliothèques | Niveau d'API cible | Accès à l'environnement d'exécution via l'éditeur de liens dynamique | Comportement d'Android 7.0 (niveau d'API 24) | Comportement futur de la plate-forme Android |
---|---|---|---|---|
NDK public | Tout | Accessible | Fonctionne comme prévu | Fonctionne comme prévu |
Privées (bibliothèques privées accessibles temporairement) | 23 ou inférieure | Temporairement accessible | Fonctionne comme prévu, mais vous recevez un avertissement Logcat. | Erreur d'exécution |
Privées (bibliothèques privées accessibles temporairement) | 24 ou ultérieure | Restricted (Limité) | Erreur d'exécution | Erreur d'exécution |
Privé (autre) | Tout | Restricted (Limité) | Erreur d'exécution | Erreur d'exécution |
Vérifier si votre application utilise des bibliothèques privées
Pour vous aider à identifier les problèmes de chargement des bibliothèques privées, logcat peut générer une un avertissement ou une erreur d'exécution. Par exemple, si votre application cible le niveau d'API 23 ou une version antérieure et tente d'accéder à une bibliothèque privée sur un appareil équipé d'Android 7.0, un avertissement semblable au suivant peut s'afficher:
03-21 17:07:51.502 31234 31234 W linker : library "libandroid_runtime.so" ("/system/lib/libandroid_runtime.so") needed or dlopened by "/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible for the namespace "classloader-namespace" - the access is temporarily granted as a workaround for http://b/26394120
Ces avertissements Logcat vous indiquent quelle bibliothèque tente d'accéder de plate-forme privée, mais ne fera pas planter votre application. Si l'application cible le niveau d'API 24 ou supérieur, mais Logcat génère erreur d'exécution et votre application peut planter:
java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so" ("/system/lib/libcutils.so") needed or dlopened by "/system/lib/libnativeloader.so" is not accessible for the namespace "classloader-namespace" at java.lang.Runtime.loadLibrary0(Runtime.java:977) at java.lang.System.loadLibrary(System.java:1602)
Vous pouvez également voir ces sorties logcat si votre application utilise des bibliothèques tierces
qui se connectent de manière dynamique aux API de la plate-forme privée. L'outil Readelf
Android 7.0DK vous permet de générer une liste de toutes les ressources partagées
d'un fichier .so
donné en exécutant la commande suivante:
aarch64-linux-android-readelf -dW libMyLibrary.so
Mettre à jour votre appli
Voici quelques étapes à suivre pour corriger ce type d'erreur assurez-vous que votre application ne plante pas lors des futures mises à jour de la plate-forme:
- Si votre application utilise des bibliothèques de plate-forme privées, vous devez la mettre à jour pour inclure sa propre copie de ces bibliothèques ou utilisez les API NDK publiques.
- Si votre application utilise une bibliothèque tierce qui accède à des symboles privés, contactez l'auteur de la bibliothèque pour la mettre à jour.
- Assurez-vous d'empaqueter toutes vos bibliothèques non NDK avec votre APK.
- Utilisez les fonctions JNI standards au lieu de
getJavaVM
.getJNIEnv
delibandroid_runtime.so
:AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h> AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or JavaVM::AttachCurrentThread from <jni.h>.
- Utilisez
__system_property_get
à la place duproperty_get
privé. symbole issu delibcutils.so
. Pour ce faire, utilisez__system_property_get
. comprenant les éléments suivants:#include <sys/system_properties.h>
Remarque:La disponibilité et le contenu des propriétés système sont non testés via CTS. Une meilleure solution serait d'éviter d'utiliser ces vos propriétés.
- Utilisez une version locale du symbole
SSL_ctrl
à partir delibcrypto.so
. Par exemple, vous devez associerlibcyrpto.a
de manière statique dans votre fichier.so
, ou inclure une version associée delibcrypto.so
de façon dynamique à partir de BoringSSL/OpenSSL et en empaquetant-la dans votre APK.
Android for Work
Android 7.0 comporte des modifications pour les applications qui ciblent Android for Work, y compris modifications apportées à l'installation du certificat, réinitialisation du mot de passe, utilisateur secondaire gestion et accès aux identifiants des appareils. Si vous créez des applications pour dans les environnements Android for Work, nous vous recommandons de passer en revue votre application en conséquence.
- Vous devez installer un programme d’installation de certificat délégué avant que le DPC puisse définir
Pour les applications de propriétaire de profil et d'appareil ciblant Android 7.0 (niveau d'API 24),
vous devez installer le programme d’installation
du certificat délégué avant
appels de contrôleur (DPC)
DevicePolicyManager.setCertInstallerPackage()
Si le programme d'installation n'est pas encore installé, le système génère uneIllegalArgumentException
- Les restrictions de réinitialisation de mot de passe pour les administrateurs d'appareils s'appliquent désormais au profil
propriétaires. Les administrateurs de l'appareil ne peuvent plus utiliser
DevicePolicyManager.resetPassword()
pour effacer les mots de passe ou les modifier celles qui sont déjà définies. Les administrateurs d'appareils peuvent toujours définir un mot de passe, mais seulement si l'appareil ne dispose d'aucun mot de passe, code ou schéma. - Les propriétaires d'appareils et de profils peuvent gérer les comptes même si les restrictions sont
défini. Les propriétaires d'appareils et de profils peuvent appeler les API Account Management
même si des restrictions utilisateur
DISALLOW_MODIFY_ACCOUNTS
sont en place. - Les propriétaires d'appareils peuvent gérer plus facilement les utilisateurs secondaires. Lorsqu’un appareil est
s'exécutant en mode propriétaire de l'appareil, la restriction
DISALLOW_ADD_USER
est définie automatiquement. Cela empêche les utilisateurs de créer des instances secondaires non gérées utilisateurs. De plus, lesCreateUser()
et Les méthodescreateAndInitializeUser()
sont obsolètes. le nouveau La méthodeDevicePolicyManager.createAndManageUser()
les remplace. - Les propriétaires d'appareils peuvent accéder aux identifiants des appareils. Le propriétaire d'un appareil peut y accéder
Adresse MAC Wi-Fi d'un appareil, en utilisant
DevicePolicyManager.getWifiMacAddress()
Si le Wi-Fi n'a jamais été activée sur l'appareil, cette méthode renvoie la valeurnull
. - Le paramètre "Mode Travail" contrôle l'accès aux applications professionnelles. Lorsque le mode Travail est désactivé, lanceur système indique que les applications professionnelles ne sont pas disponibles en les grisant. Activation... permet à nouveau de rétablir son comportement normal.
- Lors de l'installation d'un fichier PKCS #12 contenant une chaîne de certificats client et
la clé privée correspondante dans l'interface utilisateur des paramètres, le certificat CA dans
n'est plus installée dans le stockage des identifiants de confiance. Cela fait
n'a pas d'incidence sur le résultat de
KeyChain.getCertificateChain()
lorsque les applications tentent de récupérer le client de la chaîne de certificats. Si nécessaire, le certificat CA doit être installé. séparément dans l'espace de stockage des identifiants de confiance via l'interface utilisateur des paramètres, format codé DER sous une extension de fichier .crt ou .cer. - À partir d'Android 7.0, l'enregistrement et le stockage des empreintes digitales sont gérés. par utilisateur. Si le client DPC (Device Policy Client) d'un propriétaire de profil cible un niveau d'API 23 (ou version antérieure) sur un appareil équipé d'Android 7.0 (niveau d'API 24), l'utilisateur est définir une empreinte digitale sur l'appareil, mais les applications professionnelles ne peuvent pas accéder à l'empreinte de l'appareil. Lorsque l'outil DPC cible le niveau d'API 24 ou supérieur, l'utilisateur peut définir l'empreinte digitale pour le profil professionnel en accédant à Paramètres > Sécurité > Sécurité du profil professionnel
- Un nouvel état de chiffrement
ENCRYPTION_STATUS_ACTIVE_PER_USER
est renvoyé parDevicePolicyManager.getStorageEncryptionStatus()
, à indiquent que le chiffrement est actif et que la clé de chiffrement est liée utilisateur. Le nouvel état n'est renvoyé que si l'outil DPC cible le niveau d'API 24 ou supérieur. Pour les applications ciblant des niveaux d'API antérieurs,ENCRYPTION_STATUS_ACTIVE
est renvoyée, même si la clé de chiffrement est spécifique à l'utilisateur ou au profil. - Dans Android 7.0, plusieurs méthodes qui affectent normalement l'ensemble
le comportement de l'appareil est différent si un profil professionnel est installé avec un
un défi professionnel séparé. Au lieu d'affecter l'ensemble de l'appareil,
s'appliquent uniquement au profil professionnel. (Vous trouverez la liste complète de ces méthodes
dans la documentation
DevicePolicyManager.getParentProfileInstance()
.) Par exemple :DevicePolicyManager.lockNow()
verrouille uniquement le profil professionnel, au lieu de le verrouillage de l’ensemble de l’appareil. Pour chacune de ces méthodes, vous pouvez récupérer en appelant la méthode sur l'instance parente duDevicePolicyManager
; vous pouvez obtenir ce parent en Appel deDevicePolicyManager.getParentProfileInstance()
en cours. Par exemple, si vous appelezlockNow()
de l'instance parente , l'appareil est entièrement verrouillé.
Conservation des annotations
Android 7.0 corrige un bug qui empêchait la visibilité des annotations. Ce problème a permis à l'environnement d'exécution d'accéder à des annotations alors qu'il n'aurait pas dû en mesure de le faire. Ces annotations comprenaient:
VISIBILITY_BUILD
: destiné à n'être visible qu'au moment de la compilation.VISIBILITY_SYSTEM
: est destiné à être visible au moment de l'exécution, mais uniquement système sous-jacent.
Si votre application a eu recours à ce comportement, veuillez ajouter une règle de conservation aux annotations qui doivent
être disponibles au moment de l'exécution. Pour ce faire, utilisez @Retention(RetentionPolicy.RUNTIME)
.
Modifications de la configuration TLS/SSL par défaut
Android 7.0 apporte les modifications suivantes à la configuration TLS/SSL par défaut utilisé par les applications pour le trafic HTTPS et TLS/SSL:
- Les suites de chiffrement RC4 sont désormais désactivées.
- Les suites de chiffrement CHACHA20-POLY1305 sont désormais activées.
La désactivation par défaut de RC4 peut entraîner des dysfonctionnements dans HTTPS ou TLS/SSL la connectivité lorsque le serveur ne négocie pas les suites de chiffrement modernes. La solution privilégiée consiste à améliorer la configuration du serveur afin de permettre ainsi que des suites et des protocoles de chiffrement plus modernes. Idéalement, TLSv1.2 et AES-GCM doit être activée, et les suites de chiffrement de confidentialité persistante (ECDHE) doivent à activer et à privilégier.
Une autre solution consiste à modifier l'application afin d'utiliser un SSLSocketFactory
personnalisé pour communiquer avec le serveur. La
doit être conçue pour créer des SSLSocket
instances disposant de certaines des suites de chiffrement requises par le serveur
en plus des suites
de chiffrement par défaut.
Remarque:Ces modifications ne concernent pas WebView
.
Applications ciblant Android 7.0
Ces changements de comportement ne s'appliquent qu'aux applications qui ciblent
Android 7.0 (niveau d'API 24) ou version ultérieure Les applications compilées avec Android 7.0
ou si vous définissez targetSdkVersion
sur Android 7.0 ou version ultérieure, vous devez modifier
leurs applications afin de prendre en charge ces comportements correctement, le cas échéant.
Modifications apportées à la sérialisation
Android 7.0 (niveau d'API 24) a corrigé un bug dans le calcul des valeurs par défaut serialVersionUID où elle ne correspondait pas à la spécification.
Classes qui implémentent Serializable
et ne pas spécifier de champ serialVersionUID
explicite pourrait
voient une modification de leur SerialVersionUID par défaut, ce qui
entraînerait une exception
généré lors de la tentative de désérialisation des instances de la classe
sérialisées sur une version antérieure ou par une application ciblant une version antérieure
version. Le message d'erreur ressemblera à ceci:
local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567
Pour résoudre ces problèmes, vous devez ajouter un champ serialVersionUID
à
Toute classe concernée avec la valeur stream classdesc
serialVersionUID
issue du message d'erreur (par exemple, 1234
po
dans ce cas. Cette modification est conforme à toutes les recommandations de bonnes pratiques
l'écriture du code de sérialisation
et fonctionne sur toutes les versions d'Android.
Le bug spécifique qui a été corrigé était lié à la présence de balises
méthodes d'initialisation (par exemple, <clinit>
). Selon le
la présence ou l'absence d'une méthode d'initialisation statique dans
aura une incidence sur le serialVersionUID par défaut calculé pour cette classe.
Avant la correction du bug, le calcul contrôlait également la super-classe pour une
initialiseur statique si une classe n'en avait pas.
Pour rappel, ce changement n'affecte pas les applications qui ciblent les niveaux d'API 23 ou
les classes comportant un champ serialVersionUID
ou les classes
qui disposent d'une méthode d'initialisation statique.
Autres points importants
- Lorsqu'une application s'exécute sous Android 7.0, mais cible un niveau d'API inférieur,
et que l'utilisateur change de taille d'affichage, le processus de l'application est arrêté. L'application
doit pouvoir gérer ce scénario de façon optimale. Sinon, il plante.
lorsque l'utilisateur la restaure à partir de "Récents".
Vous devez tester votre application pour vous assurer que ce comportement ne se produit pas. Pour ce faire, vous risquez de provoquer un plantage lors de la fermeture manuelle de l'application via DCM.
Les applications ciblant Android 7.0 (niveau d'API 24) ou version ultérieure ne sont pas automatiquement appliquées sont supprimées en cas de changement de densité. mais il est possible qu'ils réagissent mal les modifications de configuration.
- Les applications sous Android 7.0 doivent pouvoir gérer correctement les modifications de configuration, et ne doit pas planter lors des démarrages suivants. Vous pouvez vérifier le comportement de l'application en modifiant la taille de la police (Paramètre > Affichage > Taille de la police), puis restaurer l'application depuis Récents.
-
En raison d'un bug dans les versions précédentes d'Android, le système n'a pas écrit d'indicateurs
à un socket TCP sur le thread principal
en tant que violation du mode strict. Android 7.0 corrige ce bug.
Les applications qui présentent ce comportement génèrent désormais une
android.os.NetworkOnMainThreadException
. En général, effectuer des opérations réseau sur le thread principal est une mauvaise idée, car ces opérations présentent généralement une latence élevée provoquant des ANR et des à-coups. -
La famille de méthodes
Debug.startMethodTracing()
est désormais définie par défaut sur stocker la sortie dans votre répertoire spécifique au package sur le stockage partagé, et non au niveau supérieur de la carte SD. Cela signifie que les applis n'ont plus besoin de demander l'autorisationWRITE_EXTERNAL_STORAGE
pour utiliser ces API. -
De nombreuses API de plate-forme ont maintenant commencé à vérifier si des charges utiles volumineuses sont envoyées.
dans les transactions
Binder
, et le système affiche à nouveauTransactionTooLargeExceptions
en tant queRuntimeExceptions
, au lieu de les journaliser ou de les supprimer en mode silencieux. Un un exemple courant est le stockage d'une trop grande quantité de donnéesActivity.onSaveInstanceState()
, ce qui provoqueActivityThread.StopInfo
uneRuntimeException
lorsque votre application cible Android 7.0. -
Si une application publie des tâches
Runnable
dans unView
, et leView
n'est pas attachée à une fenêtre, le système met la tâcheRunnable
en file d'attente avecView
; la tâcheRunnable
ne s'exécute que lorsque leView
est associé à une fenêtre. Ce comportement corrige les bugs suivants: <ph type="x-smartling-placeholder">- </ph>
- Si une application a publié sur un
View
à partir d'un fil de discussion autre que celui prévu thread UI de la fenêtre,Runnable
risque donc de s'exécuter sur le mauvais thread. - Si la tâche
Runnable
a été publiée depuis un fil de discussion autre que un thread looper, l'application peut exposer la tâcheRunnable
.
- Si une application a publié sur un
-
Si une application sur Android 7.0 avec
DELETE_PACKAGES
l’autorisation tente de supprimer un package, mais une autre application avait installé ce package, le système a besoin d'une confirmation de l'utilisateur. Dans ce scénario, les applications doivent s'attendreSTATUS_PENDING_USER_ACTION
comme l'état renvoyé lorsqu'ils appellentPackageInstaller.uninstall()
- Le fournisseur JCA appelé Crypto est obsolète, car il ne peut SHA1PRNG, est cryptographiquement faible. Les applis ne peuvent plus utiliser SHA1PRNG pour dériver (de manière non sécurisée) les clés, car ce fournisseur n'est plus disponibles. Pour en savoir plus, consultez le blog publier Security "Crypto" fournisseur obsolète dans Android N.