Changements de comportement : toutes les applications

Android 10 apporte des modifications de comportement qui peuvent affecter votre application. Les modifications répertoriées sur cette page s'appliquent à votre application lorsqu'elle est exécutée sur Android 10, quel que soit le targetSdkVersion de l'application. Vous devez tester votre application et la modifier si nécessaire pour prendre en charge ces modifications correctement.

Si la targetSdkVersion de votre application est 29 ou ultérieure, vous devrez également apporter des modifications supplémentaires. Pour en savoir plus, consultez les modifications de comportement pour les applications ciblant le niveau 29.

Remarque : En plus des modifications listées sur cette page, Android 10 introduit de nombreuses modifications et restrictions liées à la confidentialité. En voici quelques-unes:

• Accès à la position de l'appareil en arrière-plan
• Début de l'activité en arrière-plan
• Informations sur l'affinité de contacts
• Randomisation des adresses MAC
• Métadonnées de l'appareil photo
• Modèle d'autorisations

Ces modifications affectent toutes les applications et renforcent la confidentialité des utilisateurs. Pour en savoir plus sur la compatibilité de ces modifications, consultez la page Modifications apportées à la confidentialité.

Restrictions des interfaces hors 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 risquent de ne pas vous affecter immédiatement. Toutefois, bien que vous puissiez actuellement utiliser certaines interfaces non SDK (en fonction du niveau d'API cible de votre application), l'utilisation d'une méthode ou d'un champ non SDK présente toujours un risque élevé d'endommager votre application.

Si vous ne savez pas si 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 devez 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 devez demander une nouvelle API publique.

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

Navigation par gestes

À partir d'Android 10, les utilisateurs peuvent activer la navigation par gestes sur l'appareil. Si un utilisateur active la navigation par gestes, toutes les applications de l'appareil sont affectées, qu'elles ciblent ou non le niveau d'API 29. Par exemple, si l'utilisateur balaie l'écran à partir du bord, le système interprète ce geste comme une navigation vers l'arrière, sauf si une application remplace spécifiquement ce geste pour certaines parties de l'écran.

Pour que votre application soit compatible avec la navigation par gestes, vous devez étendre son contenu d'un bord à l'autre et gérer les gestes conflictuels de manière appropriée. Pour en savoir plus, consultez la documentation sur la navigation par gestes.

NDK

Android 10 inclut les modifications NDK suivantes.

Les objets partagés ne peuvent pas contenir de repositionnement de texte.

Android 6.0 (niveau d'API 23) interdit l'utilisation du déplacement de texte dans des objets partagés. Le code doit être chargé tel quel et ne doit pas être modifié. Ce changement améliore la sécurité et le temps de chargement des applications.

SELinux applique cette restriction aux applications qui ciblent Android 10 ou version ultérieure. Si ces applications continuent à utiliser des objets partagés contenant des déplacements de texte, elles risquent fortement de ne plus fonctionner.

Modifications apportées aux bibliothèques Bionic et aux chemins d'accès dynamiques de l'éditeur de liens

À partir d'Android 10, plusieurs chemins d'accès sont des liens symboliques au lieu de fichiers standards. Les applications qui s'appuyaient sur des chemins d'accès correspondant à des fichiers standards peuvent ne plus fonctionner:

• /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
• /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
• /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
• /system/bin/linker -> /apex/com.android.runtime/bin/linker

Ces modifications s'appliquent également aux variantes 64 bits du fichier, avec lib/ remplacé par lib64/.

Pour des raisons de compatibilité, les liens symboliques sont fournis aux anciens chemins d'accès. Par exemple, /system/lib/libc.so est un lien symbolique vers /apex/com.android.runtime/lib/bionic/libc.so. dlopen(“/system/lib/libc.so”) continue donc de fonctionner, mais les applications verront la différence lorsqu'elles essaient d'examiner les bibliothèques chargées en lisant /proc/self/maps ou une version similaire, ce qui n'est pas habituel. Toutefois, nous avons constaté que certaines applications le font dans le cadre de leur processus anti-piratage. Si tel est le cas, les chemins d'accès /apex/… doivent être ajoutés en tant que chemins valides pour les fichiers Bionic.

Binaires/bibliothèques système mappés à la mémoire d'exécution uniquement

À partir d'Android 10, les segments exécutables de binaires système et de bibliothèques sont mappés en exécution en mémoire uniquement (non lisibles) afin de renforcer la protection contre les attaques par réutilisation de code. Si votre application effectue des opérations de lecture dans des segments de mémoire marqués comme "Exécution uniquement" (lors d'une inspection de bug, de faille ou d'inspection intentionnelle de la mémoire), le système envoie un signal SIGSEGV à votre application.

Pour déterminer si ce comportement a causé un plantage, examinez le fichier tombstone associé dans /data/tombstones/. Un plantage lié à l'exécution uniquement contient le message d'abandon suivant:

Cause: execute-only (no-read) memory access error; likely due to data in .text.

Pour contourner ce problème et effectuer des opérations telles que l'inspection de la mémoire, il est possible de marquer les segments d'exécution uniquement comme lecture+exécution en appelant mprotect(). Toutefois, nous vous recommandons vivement de le redéfinir sur "Exécuter uniquement" par la suite, car ce paramètre d'autorisation d'accès offre une meilleure protection à votre application et à vos utilisateurs.

Remarque :Les appels à ptrace ne sont pas affectés par ce comportement, ce qui vous permet de déboguer ptrace.

Sécurité

Android 10 apporte les modifications de sécurité suivantes.

TLS 1.3 activé par défaut

Sur Android 10 ou version ultérieure, TLS 1.3 est activé par défaut pour toutes les connexions TLS. Voici quelques détails importants sur notre mise en œuvre de TLS 1.3:

• Les suites de chiffrement TLS 1.3 ne peuvent pas être personnalisées. Les suites de chiffrement TLS 1.3 compatibles sont toujours activées lorsque TLS 1.3 est activé. Toute tentative de désactivation en appelant setEnabledCipherSuites() est ignorée.
• Lorsque TLS 1.3 est négocié, les objets HandshakeCompletedListener sont appelés avant que les sessions ne soient ajoutées au cache de session. (Dans TLS 1.2 et d'autres versions antérieures, ces objets sont appelés après l'ajout des sessions au cache de session.)
• Dans certains cas où les instances SSLEngine génèrent une exception SSLHandshakeException sur les versions précédentes d'Android, elles génèrent une exception SSLProtocolException sur Android 10 ou version ultérieure.
• Le mode 0-RTT n'est pas pris en charge.

Si vous le souhaitez, vous pouvez obtenir un SSLContext pour lequel TLS 1.3 est désactivé en appelant SSLContext.getInstance("TLSv1.2"). Vous pouvez également activer ou désactiver des versions de protocole pour chaque connexion en appelant setEnabledProtocols() sur un objet approprié.

Les certificats signés avec SHA-1 ne sont pas approuvés dans TLS

Dans Android 10, les certificats qui utilisent l'algorithme de hachage SHA-1 ne sont pas approuvés dans les connexions TLS. Les autorités de certification racine n'ont pas délivré ce certificat depuis 2016 et ne sont plus approuvées dans Chrome ni dans les autres principaux navigateurs.

Toute tentative de connexion échoue si elle est destinée à un site qui présente un certificat SHA-1.

Modifications et améliorations du comportement de KeyChain

Certains navigateurs, tels que Google Chrome, permettent aux utilisateurs de choisir un certificat lorsqu'un serveur TLS envoie un message de demande de certificat dans le cadre d'un handshake TLS. À partir d'Android 10, les objets KeyChain respectent les émetteurs et les paramètres de spécification de clé lors de l'appel de KeyChain.choosePrivateKeyAlias() pour afficher une invite de sélection de certificat aux utilisateurs. Plus précisément, cette invite ne contient pas d'options non conformes aux spécifications du serveur.

Si aucun certificat sélectionnable par l'utilisateur n'est disponible (par exemple, si aucun certificat ne correspond aux spécifications du serveur ou si un appareil ne dispose d'aucun certificat installé), l'invite de sélection de certificat ne s'affiche pas du tout.

De plus, il n'est pas nécessaire sous Android 10 ou version ultérieure de verrouiller l'écran de l'appareil pour importer des clés ou des certificats CA dans un objet KeyChain.

Autres modifications apportées au protocole TLS et à la cryptographie

Plusieurs modifications mineures ont été apportées aux bibliothèques TLS et de cryptographie dans Android 10:

• Les algorithmes de chiffrement AES/GCM/NoPadding et ChaCha20/Poly1305/NoPadding renvoient des tailles de mémoire tampon plus précises à partir de getOutputSize().
• La suite de chiffrement TLS_FALLBACK_SCSV est omise pour les tentatives de connexion avec un protocole maximal TLS 1.2 ou supérieur. En raison des améliorations apportées aux implémentations de serveurs TLS, nous vous déconseillons d'essayer un remplacement externe TLS. Nous vous recommandons plutôt de vous fier à la négociation de version TLS.
• ChaCha20-Poly1305 est un alias de ChaCha20/Poly1305/NoPadding.
• Les noms d'hôte se terminant par un point ne sont pas considérés comme des noms d'hôte SNI valides.
• L'extension supported_signature_algorithms de CertificateRequest est respectée lors du choix d'une clé de signature pour les réponses de certificat.
• Les clés de signature opaques, telles que celles d'Android Keystore, peuvent être utilisées avec des signatures RSA-PSS dans TLS.

Diffusions Wi-Fi Direct

Sous Android 10, les annonces suivantes liées à Wi-Fi Direct ne sont pas persistantes:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Si votre application comptait sur la réception de ces annonces lors de l'enregistrement, car elles étaient persistantes, utilisez la méthode get() appropriée lors de l'initialisation pour obtenir les informations.

Fonctionnalités Wi-Fi Aware

Android 10 prend en charge la création de sockets TCP/UDP à l'aide de chemins de données Wi-Fi Aware. Pour créer un socket TCP/UDP se connectant à un ServerSocket, l'appareil client doit connaître l'adresse IPv6 et le port du serveur. Auparavant, cette communication devait être communiquée hors bande, par exemple via le Bluetooth ou la messagerie de couche 2 Wi-Fi Aware, ou à l'aide d'autres protocoles, tels que le mDNS. Avec Android 10, les informations peuvent être transmises lors de la configuration du réseau.

Le serveur peut effectuer l'une des opérations suivantes:

• Initialisez un ServerSocket, puis définissez ou obtenez le port à utiliser.
• Spécifiez les informations de port dans la requête réseau Wi-Fi Aware.

L'exemple de code suivant montre comment spécifier des informations de port dans la requête réseau:

Kotlin

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

Java

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

Le client effectue ensuite une requête réseau Wi-Fi Aware pour obtenir l'IPv6 et le port fourni par le serveur:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

Java

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW sur les appareils Go

Les applications exécutées sur des appareils Android 10 (édition Go) ne peuvent pas recevoir l'autorisation SYSTEM_ALERT_WINDOW. En effet, les fenêtres de dessin en superposition utilisent une mémoire excessive, ce qui nuit particulièrement aux performances des appareils Android à faible mémoire.

Si une application exécutée sur un appareil de l'édition Go exécutant Android 9 ou une version antérieure reçoit l'autorisation SYSTEM_ALERT_WINDOW, elle la conserve même si l'appareil est mis à niveau vers Android 10. Toutefois, les applications qui ne disposent pas encore de cette autorisation ne peuvent pas être accordées après la mise à niveau de l'appareil.

Si une application sur un appareil Go envoie un intent avec l'action ACTION_MANAGE_OVERLAY_PERMISSION, le système refuse automatiquement la requête et redirige l'utilisateur vers un écran Settings (Paramètres) qui indique que l'autorisation n'est pas autorisée, car cela ralentit l'appareil. Si une application sur un appareil Go appelle Settings.canDrawOverlays(), la méthode renvoie toujours la valeur "false". Là encore, ces restrictions ne s'appliquent pas aux applications qui ont reçu l'autorisation SYSTEM_ALERT_WINDOW avant la mise à niveau de l'appareil vers Android 10.

Avertissements concernant les applications ciblant d'anciennes versions d'Android

Les appareils équipés d'Android 10 ou version ultérieure avertissent les utilisateurs la première fois qu'ils exécutent une application qui cible Android 5.1 (niveau d'API 22) ou une version antérieure. Si l'application nécessite que l'utilisateur accorde des autorisations, il a également la possibilité d'ajuster les autorisations de l'application avant qu'elle ne puisse s'exécuter pour la première fois.

En raison des exigences concernant les API cibles de Google Play, un utilisateur ne voit ces avertissements que lorsqu'il exécute une application qui n'a pas été mise à jour récemment. Pour les applications distribuées via d'autres plates-formes de téléchargement d'applications, des exigences similaires concernant les API cibles prendront effet au cours de l'année 2019. Pour en savoir plus sur ces exigences, consultez la section Exigences étendues du niveau d'API cible en 2019.

Suites de chiffrement CBC SHA-2 supprimées

Les suites de chiffrement CBC SHA-2 suivantes ont été supprimées de la plate-forme:

• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Ces suites de chiffrement sont moins sécurisées que les suites de chiffrement similaires qui utilisent GCM. La plupart des serveurs acceptent à la fois les variantes GCM et CBC de ces suites de chiffrement, ou ne prennent en charge aucune d'entre elles.

Remarque :Les applications et les bibliothèques doivent croiser l'ensemble de suites de chiffrement souhaité avec la valeur renvoyée de getSupportedCipherSuites() jusqu'à la sélection de la suite de chiffrement pérenne en vue de futures suppressions.

Consommation par application

Android 10 introduit les changements de comportement suivants liés à l'utilisation des applications:

• Amélioration des statistiques d'utilisation des applications - - Fonctionnalité affichage avec précision des statistiques d'utilisation De plus, Android 10 suit correctement l'utilisation instantanée des applications.

• Niveaux de gris par application : 1 mode d'affichage Android et par application

• état de distraction par application -

• Suspension et lecture -

Modifications des connexions HTTPS

Si une application exécutant Android 10 transmet null à setSSLSocketFactory(), une IllegalArgumentException se produit. Dans les versions précédentes, transmettre null à setSSLSocketFactory() avait le même effet que transmettre la fabrique par défaut actuelle.

La bibliothèque android.preference est obsolète

La bibliothèque android.preference est obsolète depuis Android 10. Les développeurs doivent utiliser à la place la bibliothèque de préférences AndroidX, qui fait partie d'Android Jetpack. Pour obtenir des ressources supplémentaires qui facilitent la migration et le développement, consultez le guide des paramètres mis à jour, ainsi que notre application exemple publique et notre documentation de référence.

Modifications apportées à la bibliothèque d'utilitaires de fichiers ZIP

Android 10 apporte les modifications suivantes aux classes du package java.util.zip, qui gère les fichiers ZIP. Ces modifications rendent le comportement de la bibliothèque plus cohérent entre Android et les autres plates-formes qui utilisent java.util.zip.

Gonflable

Dans les versions précédentes, certaines méthodes de la classe Inflater généraient une exception IllegalStateException si elles étaient appelées après un appel à end(). Dans Android 10, ces méthodes génèrent une exception NullPointerException à la place.

Fichier ZIP

Dans Android 10 et versions ultérieures, le constructeur de ZipFile qui accepte des arguments de type File, int et Charset ne génère pas de ZipException si le fichier ZIP fourni ne contient aucun fichier.

ZipOutputStream

Dans Android 10 et versions ultérieures, la méthode finish() dans ZipOutputStream ne génère pas d'erreur ZipException si elle tente d'écrire un flux de sortie pour un fichier ZIP qui ne contient aucun fichier.

Modifications de l'appareil photo

De nombreuses applications utilisant l'appareil photo supposent que si l'appareil est en mode portrait, l'appareil physique est également en orientation portrait, comme décrit dans la section Orientation de l'appareil photo. Auparavant, il s'agissait d'une hypothèse sûre, mais cela a changé avec l'expansion des facteurs de forme disponibles, tels que les pliables. Cette hypothèse sur ces appareils peut entraîner une rotation incorrecte ou une mise à l'échelle (ou les deux) du viseur de l'appareil photo.

Les applications qui ciblent le niveau d'API 24 ou supérieur doivent définir explicitement android:resizeableActivity et fournir les fonctionnalités nécessaires pour gérer le mode multifenêtre.

Suivi de l'utilisation de la batterie

À partir d'Android 10, SystemHealthManager réinitialise ses statistiques d'utilisation de la batterie chaque fois que l'appareil est débranché après un événement de recharge majeur. De manière générale, un événement de recharge majeur est l'un des cas suivants: l'appareil a été complètement chargé, ou l'appareil est passé d'une charge presque entièrement déchargée à une charge majoritairement chargée.

Avant Android 10, les statistiques d'utilisation de la batterie étaient réinitialisées chaque fois que l'appareil était débranché, quel que soit le peu de changement au niveau du niveau de la batterie.

Abandon d'Android Beam

Dans Android 10, nous abandonnons officiellement Android Beam, une ancienne fonctionnalité permettant d'initier le partage de données entre des appareils via la technologie NFC (communication en champ proche). Nous abandonnons également plusieurs API NFC associées. Android Beam reste éventuellement disponible pour les fabricants d'appareils partenaires qui souhaitent l'utiliser, mais il n'est plus en développement actif. Android continuera toutefois de prendre en charge d'autres fonctionnalités et API NFC, et les cas d'utilisation tels que la lecture à partir de tags et les paiements continueront de fonctionner comme prévu.

Modification du comportement de java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() ne conserve plus les zéros de fin à la fin, ce qui constitue un cas particulier si la valeur d'entrée est zéro.

Modifications du comportement de java.util.regex.Matcher et de modèle

Le résultat de split() a été modifié pour ne plus commencer par un String vide ("") lorsqu'il existe une correspondance de largeur zéro au début de l'entrée. Cela affecte également String.split(). Par exemple, "x".split("") renvoie désormais {"x"}, alors qu'il renvoyait {"", "x"} sur les anciennes versions d'Android. "aardvark".split("(?=a)" renvoie désormais {"a", "ardv", "ark"} au lieu de {"", "a", "ardv", "ark"}.

Le comportement des exceptions pour les arguments non valides a également été amélioré:

• appendReplacement(StringBuffer, String) génère désormais une IllegalArgumentException au lieu de IndexOutOfBoundsException si le remplacement String se termine par une barre oblique inverse isolée, ce qui est illégal. La même exception est désormais générée si le String de remplacement se termine par une $. Auparavant, aucune exception n'était générée dans ce scénario.
• replaceFirst(null) n'appelle plus reset() sur Matcher s'il génère une erreur NullPointerException. NullPointerException est désormais également généré en l'absence de correspondance. Auparavant, il n'était généré qu'en cas de correspondance.
• start(int group), end(int group) et group(int group) génèrent désormais une IndexOutOfBoundsException plus générale si l'index de groupe est hors limites. Auparavant, ces méthodes généraient ArrayIndexOutOfBoundsException.

L'angle par défaut de GradientDrawable est désormais TOP_BOTTOM

Dans Android 10, si vous définissez un GradientDrawable au format XML et que vous ne fournissez pas de mesure d'angle, l'orientation du dégradé est définie par défaut sur TOP_BOTTOM. Il s'agit d'un changement par rapport aux versions précédentes d'Android, où la valeur par défaut était LEFT_RIGHT.

Pour contourner ce problème, si vous passez à la version la plus récente d'AAPT2, l'outil définit une mesure d'angle de 0 pour les anciennes applications si aucune mesure d'angle n'est spécifiée.

Journalisation des objets sérialisés à l'aide du SUID par défaut

À partir d'Android 7.0 (niveau d'API 24), la plate-forme a apporté une correction au serialVersionUID par défaut pour les objets sérialisables. Ce correctif n'a pas affecté les applications qui ciblaient le niveau d'API 23 ou inférieur.

À partir d'Android 10, si une application cible le niveau d'API 23 ou inférieur et utilise l'ancienne valeur par défaut serialVersionUID incorrecte, le système enregistre un avertissement et suggère une correction de code.

Plus précisément, le système enregistre un avertissement si toutes les conditions suivantes sont remplies:

• L'application cible le niveau d'API 23 ou inférieur.
• Une classe est sérialisée.
• La classe sérialisée utilise la serialVersionUID par défaut, au lieu de définir explicitement un serialVersionUID.
• Le serialVersionUID par défaut est différent de serialVersionUID si l'application ciblait le niveau d'API 24 ou supérieur.

Cet avertissement est consigné une seule fois pour chaque classe concernée. Le message d'avertissement inclut une suggestion de correction, qui consiste à définir explicitement serialVersionUID sur la valeur par défaut qui serait calculée si l'application ciblait le niveau d'API 24 ou supérieur. Grâce à ce correctif, vous pouvez vous assurer que si un objet de cette classe est sérialisé dans une application qui cible le niveau d'API 23 ou inférieur, il sera correctement lu par les applications qui ciblent le niveau 24 ou supérieur, et inversement.

Modifications de java.io.FileChannel.map()

À partir d'Android 10, FileChannel.map() n'est plus compatible avec les fichiers non standards, tels que /dev/zero, dont la taille ne peut pas être modifiée avec truncate(). Les versions précédentes d'Android emportaient l'erreur renvoyée par truncate(), mais Android 10 génère une IOException. Si vous avez besoin de l'ancien comportement, vous devez utiliser du code natif.