Changements de comportement : toutes les applications

Android 10 inclut des modifications de comportement susceptibles d'affecter votre application. Les modifications listées sur cette page s'appliquent à votre application lorsqu'elle s'exécute sous Android 10, quel que soit le targetSdkVersion de l'application. Vous devez tester votre application et la modifier si nécessaire afin de prendre en charge ces changements correctement.

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

Remarque : En plus des modifications répertoriées sur cette page, Android 10 introduit un grand nombre de modifications et de restrictions liées à la confidentialité, y compris les suivantes:

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

Ces modifications concernent toutes les applications et renforcent la confidentialité des données des utilisateurs. Pour en savoir plus sur la prise en charge de ces changements, consultez la page Modifications concernant 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 sous 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 ne vous affecteront peut-être pas 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'un champ ou d'une méthode 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 d'interface 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, cela affecte toutes les applications de l'appareil, qu'elles ciblent ou non le niveau d'API 29. Par exemple, si l'utilisateur balaie l'écran depuis le bord de l'écran, le système interprète ce geste comme une navigation "Retour", sauf si une application ignore spécifiquement ce geste pour certaines parties de l'écran.

Pour que votre application soit compatible avec la navigation par gestes, vous devez étendre le contenu de l'application 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 suivantes du NDK.

Les objets partagés ne peuvent pas contenir de transferts de texte

Android 6.0 (niveau d'API 23) a interdit l'utilisation des transferts de texte dans les objets partagés. Le code doit être chargé tel quel et ne doit pas être modifié. Cette modification améliore la sécurité et les 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 transferts de texte, elles présentent un risque élevé 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 les chemins d'accès à des fichiers standards peuvent rencontrer des problèmes:

  • /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, lib/ étant remplacé par lib64/.

Pour des raisons de compatibilité, les liens symboliques sont fournis dans les 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 constateront la différence lorsqu'elles tenteront d'examiner les bibliothèques chargées en lisant /proc/self/maps ou un élément similaire, ce qui n'est pas courant, mais nous avons constaté que certaines applications le font dans le cadre de leur processus de protection contre le 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 sur la mémoire d'exécution uniquement

À partir d'Android 10, les segments exécutables des binaires et des bibliothèques système sont mappés en exécution seule (non lisible) en mémoire 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 étant en exécution uniquement (par exemple, à la suite d'un bug, d'une faille ou d'une inspection intentionnelle de la mémoire), le système envoie un signal SIGSEGV à votre application.

Vous pouvez déterminer si ce comportement a causé un plantage en examinant 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 seule comme lecture et exécution en appelant mprotect(). Toutefois, nous vous recommandons vivement de rétablir l'exécution uniquement après, car ce paramètre d'autorisation d'accès offre une meilleure protection à votre application et à vos utilisateurs.

Sécurité

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

TLS 1.3 activé par défaut

Sous 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 l'ajout des sessions au cache de session. (Dans TLS 1.2 et d'autres versions précédentes, ces objets sont appelés après l'ajout des sessions au cache de session.)
  • Dans les cas où les instances SSLEngine génèrent une exception SSLHandshakeException sur des 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. En particulier, 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 aucun certificat n'est installé sur un appareil), 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 sur 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 des tentatives de connexion avec un protocole maximal TLS 1.2 ou supérieur. En raison des améliorations apportées aux implémentations de serveur TLS, nous vous déconseillons de tenter 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:

Si votre application s'est appuyée sur la réception de ces annonces lors de l'enregistrement parce qu'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 est compatible avec 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, il fallait communiquer hors bande, par exemple via BT ou la messagerie de couche 2 Wi-Fi Aware, ou être découvert dans la bande à l'aide d'autres protocoles, tels que mDNS. Avec Android 10, les informations peuvent être communiquées 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 sur le 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 exécute ensuite une requête réseau Wi-Fi Aware pour obtenir l'IPv6 et le port fournis 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, le dessin de fenêtres en superposition utilise 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 équipé d'Android 9 ou 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 pourront 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) indiquant 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 pour les applications ciblant les 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 version antérieure. Si l'application nécessite que l'utilisateur accorde des autorisations, celui-ci a également la possibilité de modifier les autorisations de l'application avant qu'elle ne soit autorisée à s'exécuter pour la première fois.

En raison des exigences de l'API cible 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, des exigences d'API cibles similaires entreront en vigueur en 2019. Pour en savoir plus sur ces exigences, consultez Élargissement des exigences concernant le niveau d'API cible en 2019.

Suites de chiffrement CBC SHA-2 supprimées

Les suites de chiffrement SHA-2 CBC 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 et la plupart des serveurs acceptent à la fois les variantes GCM et CBC de ces suites, ou aucune d'entre elles.

Consommation par application

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

  • Utilisation des statistiques d'utilisation des applications : De plus, Android 10 suit correctement l'utilisation des applis instantanées.

  • Nombre de niveaux de gris 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 plutôt utiliser la bibliothèque de préférences AndroidX, qui fait partie d'Android Jetpack. Pour obtenir des ressources supplémentaires afin de faciliter la migration et le développement, consultez le guide des paramètres mis à jour, ainsi que notre application exemple publique et la documentation de référence.

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

Android 10 introduit les modifications suivantes dans les 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.

Gonfleur

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

Sous Android 10 ou version ultérieure, le constructeur de ZipFile qui accepte les 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 ou version ultérieure, la méthode finish() dans ZipOutputStream ne génère pas de ZipException si elle tente d'écrire un flux de sortie pour un fichier ZIP ne contenant aucun fichier.

Modifications apportées à l'appareil photo

De nombreuses applications utilisant l'appareil photo partent du principe que si l'appareil est en mode portrait, l'appareil physique est également en mode portrait, comme décrit dans la section Orientation de l'appareil photo. Auparavant, cette hypothèse était sûre, mais cela a changé avec l'expansion des facteurs de forme disponibles, tels que les appareils pliables. Cette hypothèse sur ces appareils peut entraîner une rotation ou une mise à l'échelle incorrecte (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 peut se produire: l'appareil a été complètement chargé, ou l'appareil est passé d'être presque entièrement chargé.

Avant Android 10, les statistiques d'utilisation de la batterie étaient réinitialisées chaque fois que l'appareil était débranché, quelle que soit la légère modification du niveau de la batterie.

Abandon d'Android Beam

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

Changement de comportement de java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() ne conserve plus les zéros de fin en tant que cas spécial si la valeur d'entrée est zéro.

Modifications du comportement de java.util.regex.Matcher et du 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 nulle au début de l'entrée. Cela a également une incidence sur String.split(). Par exemple, "x".split("") renvoie désormais {"x"}, alors qu'il affichait {"", "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 l'String de remplacement se termine par une seule barre oblique inverse, ce qui est illégal. La même exception est désormais générée si l'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 NullPointerException. Désormais, NullPointerException est également généré en l'absence de correspondance. Auparavant, cette fonction n'était générée 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 du groupe est hors limites. Auparavant, ces méthodes généraient ArrayIndexOutOfBoundsException.

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

Dans Android 10, si vous définissez un GradientDrawable en XML et que vous ne fournissez pas de mesure d'angle, l'orientation du dégradé est TOP_BOTTOM par défaut. Il s'agit d'une modification 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é un correctif au serialVersionUID par défaut pour les objets sérialisables. Ce correctif n'a pas eu d'incidence sur les applications ciblant 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 s'appuie sur l'ancien serialVersionUID par défaut, incorrect, le système enregistre un avertissement et suggère une correction de code.

Plus précisément, le système consigne 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 valeur serialVersionUID par défaut, au lieu de définir explicitement un élément serialVersionUID.
  • La valeur par défaut serialVersionUID est différente de serialVersionUID si l'application ciblait le niveau d'API 24 ou supérieur.

Cet avertissement est consigné une 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 ciblant le niveau 24 ou supérieur, et inversement.

Modifications apportées à 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 à l'aide de truncate(). Les versions précédentes d'Android ont emporté l'erreur renvoyée par truncate(), mais Android 10 génère une exception IOException. Si vous avez besoin de l'ancien comportement, vous devez utiliser du code natif.