Modifiche del comportamento: tutte le app

Android 10 include modifiche del comportamento che potrebbero interessare la tua app. Le modifiche elencate in questa pagina si applicano alla tua app quando viene eseguita su Android 10, indipendentemente dal relativo targetSdkVersion. Devi testare l'app e modificarla se necessario per supportare correttamente queste modifiche.

Se il valore targetSdkVersion dell'app è 29 o superiore, dovrai supportare anche ulteriori modifiche. Per informazioni dettagliate, leggi Modifiche del comportamento per le app che hanno come target 29.

Nota : oltre alle modifiche elencate in questa pagina, Android 10 introduce un numero elevato di modifiche e limitazioni basate sulla privacy, tra cui:

• Accesso in background alla posizione del dispositivo
• L'attività in background inizia
• Informazioni sull'affinità dei contatti
• Randomizzazione degli indirizzi MAC
• Metadati della videocamera
• Modello di autorizzazioni

Queste modifiche interessano tutte le app e migliorano la privacy dell'utente. Per scoprire di più su come supportare queste modifiche, consulta la pagina Modifiche alla privacy.

Limitazioni relative all'interfaccia non SDK

Per garantire stabilità e compatibilità delle app, la piattaforma ha iniziato a limitare le interfacce non SDK che la tua app può utilizzare in Android 9 (livello API 28). Android 10 include elenchi aggiornati di interfacce non SDK limitate in base alla collaborazione con sviluppatori Android e ai test interni più recenti. Il nostro obiettivo è assicurarci che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.

Se non scegli come target Android 10 (livello API 29), alcune di queste modifiche potrebbero non riguardarti immediatamente. Tuttavia, anche se al momento puoi utilizzare alcune interfacce non SDK (a seconda del livello API target della tua app), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di danneggiare la tua app.

Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare l'app per scoprirlo. Se la tua app si basa su interfacce non SDK, dovresti iniziare a pianificare una migrazione a alternative SDK. Tuttavia, sappiamo che alcune app hanno casi d'uso validi per l'utilizzo di interfacce non SDK. Se non riesci a trovare un'alternativa all'utilizzo di un'interfaccia non SDK per una funzionalità nella tua app, devi richiedere una nuova API pubblica.

Per scoprire di più, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 10 e consulta Limitazioni relative alle interfacce non SDK.

Navigazione tramite gesti

A partire da Android 10, gli utenti possono attivare la navigazione tramite gesti sul dispositivo. Se un utente attiva la navigazione tramite gesti, influisce su tutte le app sul dispositivo, indipendentemente dal fatto che l'app abbia come target il livello API 29. Ad esempio, se l'utente scorre in entrata dal bordo dello schermo, il sistema interpreta il gesto come una navigazione a ritroso, a meno che un'app non sostituisca in modo specifico il gesto per alcune parti dello schermo.

Per rendere l'app compatibile con la navigazione tramite gesti, estende i contenuti dell'app da un bordo all'altro e gestisci in modo appropriato i gesti in conflitto. Per informazioni, consulta la documentazione sulla navigazione tramite gesti.

ND

Android 10 include le seguenti modifiche relative all'NDK.

Gli oggetti condivisi non possono contenere riposizionazioni di testo

Android 6.0 (livello API 23) non consente l'uso dei riposizionamenti di testo negli oggetti condivisi. Il codice deve essere caricato così com'è e non deve essere modificato. Questa modifica migliora i tempi di caricamento delle app e la sicurezza.

SELinux applica questa limitazione alle app destinate ad Android 10 o versioni successive. Se queste app continuano a usare oggetti condivisi che contengono trasferimenti di testo, sono ad alto rischio di non funzionare.

Modifiche alle librerie Bionic e ai percorsi dei linker dinamici

A partire da Android 10, diversi percorsi sono link simbolici anziché file normali. Le app che usavano percorsi di file normali potrebbero non funzionare:

• /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

Queste modifiche si applicano anche alle varianti a 64 bit del file, con lib/ sostituito con lib64/.

Per garantire la compatibilità, i collegamenti simbolici sono forniti nei percorsi precedenti. Ad esempio, /system/lib/libc.so è un collegamento simbolico a /apex/com.android.runtime/lib/bionic/libc.so. Pertanto dlopen(“/system/lib/libc.so”) continua a funzionare, ma le app noteranno la differenza quando proveranno effettivamente a esaminare le librerie caricate tramite la lettura /proc/self/maps o simili, cosa che non è solita, ma abbiamo scoperto che alcune app lo fanno nell'ambito del loro processo anti-compromissione. In questo caso, i percorsi /apex/… devono essere aggiunti come percorsi validi per i file Bionic.

Librerie/binari di sistema mappati alla memoria di sola esecuzione

A partire da Android 10, i segmenti eseguibili di librerie e programmi binari di sistema vengono mappati nella memoria di sola esecuzione (non leggibile) come tecnica di protezione contro gli attacchi da riutilizzo del codice. Se la tua app esegue operazioni di lettura in segmenti di memoria contrassegnati come di sola esecuzione, che si tratti di bug, vulnerabilità o ispezione intenzionale della memoria, il sistema invia un indicatore SIGSEGV all'app.

Puoi stabilire se questo comportamento ha causato un arresto anomalo esaminando il file di tombstone correlato in /data/tombstones/. Un arresto anomalo correlato solo all'esecuzione contiene il seguente messaggio di interruzione:

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

Per aggirare questo problema ed eseguire operazioni come l'ispezione della memoria, è possibile contrassegnare i segmenti di sola esecuzione come lettura+esecuzione richiamando mprotect(). Tuttavia, ti consigliamo vivamente di ripristinare la modalità Solo esecuzione in un secondo momento, poiché questa impostazione di autorizzazione di accesso offre una migliore protezione per la tua app e i tuoi utenti.

Nota: le chiamate a ptrace non sono interessate da questo comportamento, puoi quindi eseguire il debug di ptrace.

Sicurezza

Android 10 include le seguenti modifiche relative alla sicurezza.

TLS 1.3 abilitato per impostazione predefinita

In Android 10 e versioni successive, TLS 1.3 è attivato per impostazione predefinita per tutte le connessioni TLS. Ecco alcuni dettagli importanti sull'implementazione di TLS 1.3:

• Le suite di crittografia TLS 1.3 non possono essere personalizzate. Le suite di crittografia TLS 1.3 supportate sono sempre abilitate quando TLS 1.3 è abilitato. Qualsiasi tentativo di disabilitazione chiamando setEnabledCipherSuites() viene ignorato.
• Quando viene negoziato TLS 1.3, gli oggetti HandshakeCompletedListener vengono chiamati prima che le sessioni vengano aggiunte alla cache delle sessioni. In TLS 1.2 e nelle altre versioni precedenti, questi oggetti vengono chiamati dopo l'aggiunta di sessioni alla cache delle sessioni.
• In alcune situazioni in cui le istanze SSLEngine generano un SSLHandshakeException nelle versioni precedenti di Android, queste istanze includono SSLProtocolException invece su Android 10 e versioni successive.
• La modalità 0-RTT non è supportata.

Se vuoi, puoi ottenere un SSLContext con TLS 1.3 disabilitato chiamando SSLContext.getInstance("TLSv1.2"). Puoi anche abilitare o disabilitare le versioni del protocollo in base alla connessione chiamando setEnabledProtocols() su un oggetto appropriato.

I certificati firmati con SHA-1 non sono attendibili in TLS

In Android 10, i certificati che utilizzano l'algoritmo hash SHA-1 non sono attendibili nelle connessioni TLS. Le CA radice non rilasciano questo certificato dal 2016 e non sono più considerate attendibili in Chrome o nei principali browser.

Qualsiasi tentativo di connessione non va a buon fine se la connessione è a un sito che presenta un certificato utilizzando SHA-1.

Modifiche e miglioramenti al comportamento di KeyChain

Alcuni browser, come Google Chrome, consentono agli utenti di scegliere un certificato quando un server TLS invia un messaggio di richiesta di certificato nell'ambito di un TLS handshake. A partire da Android 10, gli oggetti KeyChain rispettano gli emittenti e i parametri delle specifiche principali quando chiamino KeyChain.choosePrivateKeyAlias() per mostrare agli utenti una richiesta di selezione dei certificati. In particolare, questo prompt non contiene scelte non conformi alle specifiche del server.

Se non sono disponibili certificati selezionabili dall'utente, come nel caso in cui nessun certificato corrisponde alla specifica del server o se in un dispositivo non è installato alcun certificato, la richiesta di selezione dei certificati non viene visualizzata.

Inoltre, su Android 10 o versioni successive non è necessario avere un blocco schermo del dispositivo per importare chiavi o certificati CA in un oggetto KeyChain.

Altre modifiche a TLS e alla crittografia

Sono state apportate diverse modifiche di lieve entità alle librerie TLS e di crittografia che sono state applicate su Android 10:

• Le crittografie AES/GCM/NoPadding e ChaCha20/Poly1305/NoPadding restituiscono dimensioni del buffer più precise da getOutputSize().
• La suite di crittografia TLS_FALLBACK_SCSV viene omessa dai tentativi di connessione con un protocollo massimo di TLS 1.2 o superiore. A causa dei miglioramenti nelle implementazioni del server TLS, sconsigliamo di tentare di utilizzare il fallback TLS-esterno. Consigliamo invece di fare affidamento sulla negoziazione della versione TLS.
• ChaCha20-Poly1305 è un alias di ChaCha20/Poly1305/NoPadding.
• I nomi host con punti finali non sono considerati nomi host SNI validi.
• L'estensione supported_signature_algorithms in CertificateRequest viene rispettata nella scelta di una chiave di firma per le risposte dei certificati.
• In TLS, è possibile utilizzare chiavi di firma opache, come quelle dell'archivio chiavi Android, con le firme RSA-PSS.

Trasmissioni Wi-Fi Direct

Su Android 10, le seguenti trasmissioni relative a Wi-Fi Direct non sono fisse:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Se la tua app ha fatto affidamento sulla ricezione di questi annunci al momento della registrazione perché erano fissi, utilizza il metodo get() appropriato durante l'inizializzazione per ottenere le informazioni.

Funzionalità Wi-Fi Aware

Android 10 aggiunge il supporto per semplificare la creazione di socket TCP/UDP utilizzando i percorsi di dati sensibili al Wi-Fi. Per creare un socket TCP/UDP che si connette a un ServerSocket, il dispositivo client deve conoscere l'indirizzo IPv6 e la porta del server. In precedenza doveva essere comunicato fuori banda, ad esempio utilizzando messaggi BT o Wi-Fi Aware livello 2, oppure rilevato in banda utilizzando altri protocolli, come mDNS. Con Android 10, le informazioni possono essere comunicate durante la configurazione della rete.

Il server può eseguire una delle seguenti operazioni:

• Inizializza un ServerSocket e imposta o ottieni la porta da utilizzare.
• Specifica le informazioni sulla porta come parte della richiesta di rete Wi-Fi Aware.

Il seguente esempio di codice mostra come specificare le informazioni sulla porta come parte della richiesta di rete:

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();

Il client esegue quindi una richiesta di rete Wi-Fi Aware per ottenere l'IPv6 e la porta fornite dal server:

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 sui dispositivi Go

Le app eseguite su dispositivi Android 10 Go non possono ricevere l'autorizzazione SYSTEM_ALERT_WINDOW. Questo perché disegnare finestre overlay utilizza troppa memoria, il che è particolarmente dannoso per le prestazioni dei dispositivi Android con poca memoria.

Se un'app eseguita su un dispositivo Go con Android 9 o versioni precedenti riceve l'autorizzazione SYSTEM_ALERT_WINDOW, l'app la mantiene anche se viene eseguito l'upgrade del dispositivo ad Android 10. Tuttavia, le app che non dispongono già di questa autorizzazione non possono essere concesse dopo l'upgrade del dispositivo.

Se un'app su un dispositivo Go invia un intent con l'azione ACTION_MANAGE_OVERLAY_PERMISSION, il sistema nega automaticamente la richiesta e indirizza l'utente a una schermata Impostazioni in cui viene indicato che l'autorizzazione non è consentita perché rallenta il dispositivo. Se un'app su un dispositivo Go chiama Settings.canDrawOverlays(), il metodo restituisce sempre false. Come già detto, queste limitazioni non si applicano alle app che hanno ricevuto l'autorizzazione SYSTEM_ALERT_WINDOW prima dell'upgrade del dispositivo ad Android 10.

Avvisi per le app che hanno come target versioni precedenti di Android

I dispositivi con Android 10 o versioni successive avvisano gli utenti la prima volta che eseguono app destinate ad Android 5.1 (livello API 22) o versioni precedenti. Se l'app richiede all'utente di concedere autorizzazioni, all'utente viene anche offerta la possibilità di modificare le autorizzazioni dell'app prima che l'app possa essere eseguita per la prima volta.

A causa dei requisiti dell'API target di Google Play, un utente vede questi avvisi solo quando esegue un'app che non è stata aggiornata di recente. Per le app distribuite tramite altri store, nel 2019 entreranno in vigore requisiti API target simili. Per ulteriori informazioni su questi requisiti, consulta la pagina relativa ai requisiti relativi ai livelli API target dell'espansione nel 2019.

Suite di crittografia SHA-2 CBC rimosse

Le seguenti suite di crittografia CBC SHA-2 sono state rimosse dalla piattaforma:

• 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

Queste suite di crittografia sono meno sicure rispetto a quelle simili che utilizzano GCM e la maggior parte dei server supporta entrambe le varianti GCM e CBC o nessuna di queste.

Nota: le app e le librerie devono incrociare l'insieme desiderato di pacchetti di crittografia con il valore restituito da getSupportedCipherSuites() alla selezione di suite di crittografia a prova di futuro contro rimozioni future.

Utilizzo di app

Android 10 introduce le seguenti modifiche del comportamento relative all'utilizzo delle app:

• Miglioramenti all'utilizzo delle app - Inoltre, Android 10 monitora correttamente l'utilizzo delle app istantanee.

• Modalità di visualizzazione in scala di grigi per app su base di grigio

• Stato di distrazione per app

• Sospensione e riproduzione -

Modifiche alla connessione HTTPS

Se un'app con Android 10 trasmette null a setSSLSocketFactory(), si verifica un IllegalArgumentException. Nelle versioni precedenti, il passaggio di null in setSSLSocketFactory() ha avuto lo stesso effetto del passaggio nell'attuale fabbrica predefinita.

La libreria android.preference è deprecata

La raccolta android.preference è deprecata a partire da Android 10. Gli sviluppatori dovrebbero invece utilizzare la libreria di preferenze AndroidX, che fa parte di Android Jetpack. Per ulteriori risorse che semplificano la migrazione e lo sviluppo, consulta la Guida alle impostazioni aggiornata, la nostra app pubblica di esempio e la documentazione di riferimento.

Modifiche alle librerie di utilità dei file ZIP

Android 10 introduce le seguenti modifiche alle classi nel pacchetto java.util.zip, che gestisce i file ZIP. Queste modifiche rendono più coerente il comportamento della raccolta tra Android e altre piattaforme che utilizzano java.util.zip.

Inferiore

Nelle versioni precedenti, alcuni metodi della classe Inflater lanciavano un IllegalStateException se venivano richiamati dopo una chiamata a end(). In Android 10, questi metodi visualizzano invece un NullPointerException.

File ZIP

In Android 10 e versioni successive, il costruttore per ZipFile che accetta argomenti di tipo File, int e Charset non restituisce ZipException se il file ZIP fornito non contiene alcun file.

ZipOutputStream

In Android 10 e versioni successive, il metodo finish() in ZipOutputStream non restituisce ZipException se tenta di scrivere un flusso di output per un file ZIP che non contiene alcun file.

Modifiche fotocamera

Molte app che utilizzano la fotocamera presuppongono che se il dispositivo è in una configurazione verticale, anche il dispositivo fisico è in orientamento verticale, come descritto in Orientamento della fotocamera. In passato questo era un presupposto sicuro, ma questo è cambiato con l'espansione dei fattori di forma disponibili, come i pieghevoli. Su questi dispositivi, il mirino della fotocamera può essere ruotato o scalato in modo errato (o in entrambi i casi).

Le applicazioni che hanno come target il livello API 24 o versioni successive devono impostare esplicitamente android:resizeableActivity e fornire la funzionalità necessaria per gestire il funzionamento multi-finestra.

Monitoraggio dell'utilizzo della batteria

A partire da Android 10, SystemHealthManager reimposta le statistiche sull'utilizzo della batteria ogni volta che il dispositivo viene scollegato dopo un importante evento di ricarica. In generale, un evento di ricarica importante è il seguente: il dispositivo è stato completamente carico oppure il dispositivo è passato da quasi completamente esaurito a quasi la carica.

Prima di Android 10, le statistiche sull'utilizzo della batteria venivano reimpostate ogni volta che il dispositivo era scollegato, a prescindere dalle variazioni minime del livello della batteria.

Ritiro di Android Beam

In Android 10 ritireremo ufficialmente Android Beam, una funzionalità meno recente che consente di avviare la condivisione dei dati tra dispositivi tramite Near Field Communication (NFC). Stiamo inoltre ritirando molte delle API NFC correlate. Android Beam rimane facoltativamente disponibile per i partner produttori di dispositivi che vogliono utilizzarlo, ma non è più in fase di sviluppo attivo. Tuttavia, Android continuerà a supportare altre API e funzionalità NFC e i casi d'uso come la lettura di tag e pagamenti continueranno a funzionare come previsto.

Modifica del comportamento di java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() non conserva più gli zeri finali come caso speciale se il valore di input è zero.

Modifiche al comportamento java.util.regex.Matcher e pattern

Il risultato di split() è stato modificato in modo che non inizi più con un String ("") vuoto quando è presente una corrispondenza di larghezza pari a zero all'inizio dell'input. Riguarda anche String.split(). Ad esempio, ora "x".split("") restituisce {"x"}, mentre in precedenza restituiva {"", "x"} su versioni precedenti di Android. "aardvark".split("(?=a)" ora restituisce {"a", "ardv", "ark"} anziché {"", "a", "ardv", "ark"}.

È stato migliorato anche il comportamento delle eccezioni per argomenti non validi:

• appendReplacement(StringBuffer, String) ora genera un IllegalArgumentException invece di IndexOutOfBoundsException se la sostituzione String termina con una barra rovesciata solitaria, che non è valida. La stessa eccezione ora viene generata se il valore String sostitutivo termina con un $. In precedenza, non era prevista alcuna eccezione in questo scenario.
• replaceFirst(null) non chiama più reset() su Matcher se genera un NullPointerException. Ora viene lanciata anche NullPointerException in caso di assenza di corrispondenze. In precedenza, veniva lanciato solo quando c'era una partita.
• start(int group), end(int group) e group(int group) ora generano un IndexOutOfBoundsException più generale se l'indice del gruppo è fuori intervallo. In precedenza, questi metodi lanciavano ArrayIndexOutOfBoundsException.

L'angolo predefinito per GradientDrawable ora è TOP_BOTTOM

In Android 10, se definisci un elemento GradientDrawable in XML e non fornisci una misurazione dell'angolo, l'orientamento del gradiente viene impostato automaticamente su TOP_BOTTOM. Si tratta di una modifica rispetto alle versioni precedenti di Android, in cui il valore predefinito era LEFT_RIGHT.

Come soluzione alternativa, se esegui l'aggiornamento alla versione più recente di AAPT2, lo strumento imposta una misurazione dell'angolo pari a 0 per le app precedenti se non viene specificata alcuna misurazione dell'angolo.

Logging per oggetti serializzati utilizzando SUID predefinito

A partire da Android 7.0 (livello API 24), la piattaforma ha apportato una correzione al valore predefinito di serialVersionUID per gli oggetti serializzabili. Questa correzione non ha interessato le app destinate al livello API 23 o precedente.

A partire da Android 10, se un'app ha come target il livello API 23 o un livello precedente e si basa sul precedente valore predefinito serialVersionUID, il sistema registra un avviso e suggerisce una correzione del codice.

In particolare, il sistema registra un avviso se tutte le seguenti condizioni sono vere:

• L'app ha come target il livello API 23 o precedente.
• Una classe è serializzata.
• La classe serializzata utilizza il valore serialVersionUID predefinito, anziché impostare esplicitamente un serialVersionUID.
• Il valore predefinito serialVersionUID è diverso da serialVersionUID se l'app ha come target il livello API 24 o un livello superiore.

Questo avviso viene registrato una volta per ogni classe interessata. Il messaggio di avviso include una correzione suggerita, che consiste nell'impostare esplicitamente serialVersionUID sul valore predefinito che verrebbe calcolato se l'app ha come target il livello API 24 o superiore. Utilizzando questa correzione, puoi garantire che se un oggetto di quella classe è serializzato su un'app che ha come target il livello API 23 o un livello inferiore, l'oggetto verrà letto correttamente dalle app con target 24 o versioni successive e viceversa.

Modifiche a java.io.FileChannel.map()

A partire da Android 10, FileChannel.map() non è supportato per i file non standard, come /dev/zero, le cui dimensioni non possono essere modificate utilizzando truncate(). Le versioni precedenti di Android hanno inghiottito l'errore restituito da truncate(), ma Android 10 genera un'IOException. Se hai bisogno del comportamento precedente, devi usare il codice nativo.