Changements de comportement: applications ciblant le niveau d'API 29 ou supérieur

Android 10 inclut des modifications du comportement du système pouvant affecter votre application. Les modifications listées sur cette page s'appliquent exclusivement aux applications qui ciblent l'API 29 ou version ultérieure. Si votre application définit targetSdkVersion sur "29" ou une version ultérieure, vous devez la modifier pour qu'elle soit compatible avec ces comportements, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications exécutées sur Android 10.

Remarque : Outre les modifications listées sur cette page, Android 10 introduit un grand nombre de modifications et de restrictions liées à la confidentialité, y compris les suivantes :

• Espace de stockage cloisonné
• Accès au numéro de série de l'appareil USB
• Possibilité d'activer, de désactiver et de configurer le Wi-Fi
• Autorisations de localisation pour les API de connectivité

Ces modifications, qui affectent les applications ciblant le niveau d'API 29 ou une version ultérieure, améliorent la confidentialité des utilisateurs. Pour en savoir plus sur la compatibilité avec ces modifications, consultez la page Modifications liées à la confidentialité.

Mises à jour des restrictions d'interface non SDK

Pour garantir la stabilité et la compatibilité des applications, la plate-forme a commencé à limiter les interfaces non SDK que votre application peut utiliser dans Android 9 (niveau d'API 28). Android 10 inclut des listes à jour d'interfaces non SDK limitées grâce à la collaboration avec les développeurs Android et aux derniers tests internes. Notre objectif est de nous assurer que des alternatives publiques sont disponibles avant de limiter les interfaces non SDK.

Si vous ne ciblez pas Android 10 (niveau d'API 29), certaines de ces modifications peuvent ne pas vous affecter immédiatement. Cependant, bien que vous puissiez actuellement utiliser certaines interfaces non SDK (en fonction du niveau d'API cible de votre application), l'utilisation d'un champ ou d'une méthode non SDK présente toujours un risque élevé d'endommager votre application.

Si vous n'êtes pas sûr que votre application utilise des interfaces non SDK, vous pouvez tester votre application pour le savoir. Si votre application repose sur des interfaces non SDK, vous devriez commencer à planifier une migration vers des alternatives SDK. Nous comprenons néanmoins que certaines applications ont des cas d'utilisation valides pour utiliser des interfaces non SDK. Si vous ne trouvez pas d'alternative à l'utilisation d'une interface non SDK pour une fonctionnalité de votre application, vous devriez demander une nouvelle API publique.

Pour en savoir plus, consultez Mises à jour des restrictions d'interface non SDK dans Android 10 et Restrictions concernant les interfaces non SDK.

Souvenir partagé

Ashmem a modifié le format des mappages Dalvik dans /proc/<pid>/maps, ce qui affecte les applications qui analysent directement le fichier de mappages. Les développeurs d'applications doivent tester le format /proc/<pid>/maps sur les appareils équipés d'Android 10 ou version ultérieure et effectuer l'analyse en conséquence si l'application dépend des formats de mappage Dalvik.

Les applications ciblant Android 10 ne peuvent pas utiliser directement ashmem (/dev/ashmem) et doivent plutôt accéder à la mémoire partagée via la classeASharedMemory `ASharedMemory` du NDK. De plus, les applications ne peuvent pas effectuer d'IOCTL directes vers des descripteurs de fichiers ashmem existants et doivent plutôt utiliser la classe ASharedMemory du NDK ou les API Java Android pour créer des régions de mémoire partagée. Cette modification améliore la sécurité et la robustesse lorsque vous travaillez avec de la mémoire partagée, ce qui améliore les performances et la sécurité d'Android dans son ensemble.

Suppression de l'autorisation d'exécution pour le répertoire d'accueil de l'application

L'exécution de fichiers à partir du répertoire d'accueil de l'application accessible en écriture est un cas de non-respect de la règle W^X. Les applications ne doivent charger que le code binaire intégré au fichier APK d'une application.

Les applications non approuvées qui ciblent Android 10 ne peuvent pas appeler execve() directement sur les fichiers du répertoire d'accueil de l'application.

En outre, les applications qui ciblent Android 10 ne peuvent pas modifier le code exécutable en mémoire des fichiers ouverts avec dlopen() et s'attendre à ce que ces modifications soient écrites sur le disque, car la bibliothèque n'a pas pu être mappée PROT_EXEC via un descripteur de fichier accessible en écriture. Cela inclut tous les fichiers d'objets partagés (.so) associés à des transferts de texte.

L'environnement d'exécution Android n'accepte que les fichiers OAT générés par le système

L'environnement d'exécution Android (ART) n'appelle plus dex2oat à partir du processus de l'application. Cette modification signifie que l'ART n'acceptera que les fichiers OAT générés par le système.

Application de l'exactitude AOT dans ART

Auparavant, la compilation en amont (AOT) effectuée par l'environnement d'exécution Android (ART) pouvait entraîner des plantages au moment de l'exécution si l'environnement du chemin de classe n'était pas le même au moment de la compilation et de l'exécution. Android 10 et versions ultérieures exigent toujours que ces contextes d'environnement soient identiques, ce qui entraîne les modifications de comportement suivantes :

• Les chargeurs de classes personnalisés, c'est-à-dire les chargeurs de classes écrits par des applications, contrairement aux chargeurs de classes du dalvik.system package, ne sont pas compilés AOT. En effet, ART ne peut pas connaître l'implémentation de la recherche de classes personnalisée au moment de l'exécution.
• Les fichiers dex secondaires, c'est-à-dire les fichiers dex chargés manuellement par des applications qui ne se trouvent pas dans le APK principal, sont compilés AOT en arrière-plan. En effet, la compilation lors de la première utilisation peut être trop coûteuse, ce qui entraîne une latence indésirable avant l'exécution. Notez que pour les applications, il est recommandé d'adopter des divisions et de ne plus utiliser de fichiers dex secondaires.
• Les bibliothèques partagées dans Android (les entrées <library> et <uses-library> dans un fichier manifeste Android) sont implémentées à l'aide d'une hiérarchie de chargeurs de classes différente de celle utilisée dans les versions précédentes de la plate-forme.

Modifications des autorisations pour les intents en plein écran

Les applications qui ciblent Android 10 ou version ultérieure et qui utilisent des notifications avec intents en plein écran doivent demander l'autorisation USE_FULL_SCREEN_INTENT dans le fichier manifeste de leur application. Il s'agit d'une autorisation normale. Le système l'accorde donc automatiquement à l'application à l'origine de la demande.

Si une application qui cible Android 10 ou version ultérieure tente de créer une notification avec un intent en plein écran sans demander l'autorisation nécessaire, le système ignore l'intent en plein écran et génère le message de journal suivant :

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

Compatibilité avec les appareils pliables

Android 10 apporte des modifications qui prennent en charge les appareils pliables et les appareils à grand écran.

Lorsqu'une application s'exécute sur Android 10, les onResume() et onPause() méthodes fonctionnent différemment. Lorsque plusieurs applications s'affichent en même temps en mode multifenêtre ou multi-écran, toutes les activités principales ciblables dans les piles visibles sont à l'état réactivé, mais une seule d'entre elles, l'activité "réactivée au premier plan", est réellement ciblée. Lorsque vous exécutez des versions antérieures à Android 10, une seule activité du système peut être réactivée à la fois. Toutes les autres activités visibles sont mises en veille.

Ne confondez pas "focus" avec l'activité "réactivée au premier plan". Le système attribue des priorités aux activités en fonction de l'ordre de priorité pour accorder une priorité plus élevée aux activités avec lesquelles l'utilisateur a interagi en dernier. Une activité peut être réactivée au premier plan, mais ne pas être ciblée (par exemple, si le panneau des notifications est développé).

Dans Android 10 (niveau d'API 29) et versions ultérieures, vous pouvez vous abonner au onTopResumedActivityChanged() rappel pour être averti lorsque votre activité acquiert ou perd la première position réactivée. Cela équivaut à l'état réactivé avant Android 10 et peut être utile si votre application utilise des ressources exclusives ou singleton qui peuvent avoir besoin d'être partagées avec d'autres applications.

Le comportement de l' resizeableActivity attribut de fichier manifeste a également changé. Si une application définit resizeableActivity=false dans Android 10 (niveau d'API 29) ou version ultérieure, elle peut être mise en mode de compatibilité lorsque la taille d'écran disponible change ou si l'application passe d'un écran à un autre.

Les applications peuvent utiliser l' android:minAspectRatio attribut, introduit dans Android 10, pour indiquer les formats d'écran compatibles avec votre application.

À partir de la version 3.5, l'outil d'émulateur d'Android Studio inclut des appareils virtuels de 7,3 et 8 pouces pour tester votre code sur des écrans plus grands.

Pour en savoir plus, consultez Concevoir vos applications pour les appareils pliables.