Cambiamenti del comportamento: tutte le app

Android 10 include modifiche al comportamento che potrebbero influire sulla tua app. Le modifiche elencate in questa pagina si applicano alla tua app quando viene eseguita su Android 10, indipendentemente dal targetSdkVersion dell'app. Devi testare la tua app e modificarla in base alle esigenze per supportare correttamente queste modifiche.

Se la versione targetSdk della tua app è 29 o successiva, dovrai anche supportare modifiche aggiuntive. Per maggiori dettagli, leggi la sezione relativa alle modifiche al comportamento per le app con targeting 29.

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

• Accesso in background alla posizione del dispositivo
• Avvio delle attività in background
• Informazioni sull'affinità dei contatti
• Selezione casuale dell'indirizzo MAC
• Metadati della fotocamera
• Modello di autorizzazioni

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

Limitazioni relative alle interfacce non SDK

Per contribuire a garantire la stabilità e la 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 con limitazioni in base alla collaborazione con gli sviluppatori Android e agli ultimi test interni. 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 interessarti 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 interrompere la tua app.

Se non sai con certezza se la tua app utilizza interfacce non SDK, puoi testarla per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare la migrazione ad alternative SDK. Tuttavia, siamo consapevoli 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 saperne di più, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 10 e Limitazioni relative alle interfacce non SDK.

Navigazione tramite gesti

A partire da Android 10, gli utenti possono attivare la navigazione con i gesti sul dispositivo. Se un utente attiva la navigazione con i gesti, questa operazione interessa tutte le app sul dispositivo, indipendentemente dal fatto che l'app abbia come target il livello API 29 o meno. Ad esempio, se l'utente scorre dall'interno verso l'esterno del bordo dello schermo, il sistema interpreta il gesto come un movimento di navigazione indietro, a meno che un'app non sovrascrive specificamente il gesto per alcune parti dello schermo.

Per rendere la tua app compatibile con la navigazione con gesti, ti consigliamo di estendere i contenuti dell'app da un bordo all'altro e di gestire in modo appropriato i gesti in conflitto. Per informazioni, consulta la documentazione relativa alla navigazione con gesti.

NDK

Android 10 include le seguenti modifiche all'NDK.

Gli oggetti condivisi non possono contenere ricollocazioni di testo

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

SELinux applica questa limitazione alle app che hanno come target Android 10 o versioni successive. Se queste app continuano a utilizzare oggetti condivisi che contengono riallocazioni di testo, rischiano di non funzionare.

Modifiche alle librerie Bionic e ai percorsi del linker dinamico

A partire da Android 10, diversi percorsi sono link simbolici anziché file regolari. Le app che si basano sul fatto che i percorsi siano file regolari 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, conlib/ sostituito da lib64/.

Per motivi di compatibilità, i link simbolici vengono forniti nei vecchi percorsi. Ad esempio, /system/lib/libc.so è un link 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 tenteranno di esaminare le librerie caricate leggendo dlopen(“/system/lib/libc.so”) o simili, il che non è normale, ma abbiamo riscontrato che alcune app lo fanno come parte del loro processo anti-hacking./proc/self/maps In questo caso, i percorsi/apex/… devono essere aggiunti come percorsi validi per i file Bionic.

Binari/librerie di sistema mappati alla memoria di sola esecuzione

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

Puoi identificare se questo comportamento ha causato un arresto anomalo esaminando il file tombstone correlato in /data/tombstones/. Un arresto anomalo correlato 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 chiamando mprotect(). Tuttavia, ti consigliamo vivamente di ripristinare la modalità di esecuzione solo successivamente, poiché questa impostazione dell'autorizzazione di accesso offre una protezione migliore per la tua app e i tuoi utenti.

Nota: le chiamate a ptrace non sono interessate da questo comportamento, il che ti consente di eseguire il debug di ptrace.

Sicurezza

Android 10 include le seguenti modifiche alla sicurezza.

TLS 1.3 abilitato per impostazione predefinita

In Android 10 e versioni successive, TLS 1.3 è abilitato per impostazione predefinita per tutte le connessioni TLS. Ecco alcuni dettagli importanti sulla nostra 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 attivate quando è attivato TLS 1.3. Qualsiasi tentativo di disattivarli 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 altre versioni precedenti, questi oggetti vengono chiamati dopo l'aggiunta delle sessioni alla cache delle sessioni.
• In alcuni casi in cui le istanze SSLEngine generano un messaggio SSLHandshakeException su versioni precedenti di Android, su Android 10 e versioni successive generano un messaggio SSLProtocolException.
• La modalità 0-RTT non è supportata.

Se vuoi, puoi ottenere un SSLContext con TLS 1.3 disabilitato chiamando SSLContext.getInstance("TLSv1.2"). Puoi anche attivare o disattivare 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 considerati attendibili nelle connessioni TLS. Le CA radice non hanno emesso questo tipo di certificato dal 2016 e non sono più considerate attendibili in Chrome o in altri browser principali.

Qualsiasi tentativo di connessione non va a buon fine se la connessione è con un sito che presenta un certificato che utilizza 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 handshake TLS. A partire da Android 10, gli oggetti KeyChain rispettano gli emittenti e i parametri di specifica principali quando viene chiamata la funzione KeyChain.choosePrivateKeyAlias() per mostrare agli utenti una richiesta di selezione del certificato. In particolare, questo prompt non contiene scelte che non rispettano le specifiche del server.

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

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

Altre modifiche a TLS e crittografia

Sono state apportate diverse modifiche minori alle librerie TLS e di crittografia che entrano in vigore su Android 10:

• Le crittografie AES/GCM/NoPadding e ChaCha20/Poly1305/NoPadding restituiscono dimensioni del buffer più accurate a partire da getOutputSize().
• Il pacchetto di crittografia TLS_FALLBACK_SCSV viene omesso dai tentativi di connessione con un protocollo massimo TLS 1.2 o versioni successive. A causa dei miglioramenti apportati alle implementazioni dei server TLS, sconsigliamo di provare il fallback TLS esterno. Ti consigliamo invece di fare affidamento sulla negoziazione della versione TLS.
• ChaCha20-Poly1305 è un alias per 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 quando si sceglie una chiave di firma per le risposte del certificato.
• Le chiavi di firma opache, come quelle dell'archivio chiavi Android, possono essere utilizzate con le firme RSA-PSS in TLS.

Trasmissioni Wi-Fi Direct

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

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Se la tua app si basava sulla ricezione di queste trasmissioni al momento della registrazione perché erano permanenti, utilizza il metodo get() appropriato all'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 dati Wi-Fi Aware. Per creare una 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 out-of-band, ad esempio utilizzando la messaggistica di livello 2 BT o Wi-Fi Aware o scoperto in-band 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 nell'ambito della richiesta di rete Wi-Fi Aware.

Il seguente esempio di codice mostra come specificare le informazioni sulla porta nell'ambito 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 forniti 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 in esecuzione sui dispositivi Android 10 (versione Go) non possono ricevere l'autorizzazione SYSTEM_ALERT_WINDOW. Questo perché il disegno delle finestre in overlay utilizza una quantità eccessiva di memoria, che è particolarmente dannosa per le prestazioni dei dispositivi Android con poca memoria.

Se un'app in esecuzione su un dispositivo con Android Go o versioni precedenti riceve l'autorizzazioneSYSTEM_ALERT_WINDOW, l'app mantiene l'autorizzazione anche se viene eseguito l'upgrade del dispositivo ad Android 10. Tuttavia, le app che non dispongono già di questa permission non possono ottenerne una dopo l'upgrade del dispositivo.

Se un'app su un dispositivo Go invia un intent con l'azione ACTION_MANAGE_OVERLAY_PERMISSION, il sistema rifiuta 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. Ancora una volta, 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 un'app che ha come target Android 5.1 (livello API 22) o versioni precedenti. Se l'app richiede all'utente di concedere le autorizzazioni, l'utente ha anche la possibilità di modificare le autorizzazioni dell'app prima che l'app venga eseguita per la prima volta.

A causa dei requisiti relativi all'API target di Google Play, un utente visualizza questi avvisi solo quando esegue un'app che non è stata aggiornata di recente. Per le app distribuite tramite altri store, verranno applicati requisiti simili per le API target nel corso del 2019. Per ulteriori informazioni su questi requisiti, consulta l'articolo Espansione dei requisiti relativi al livello API target nel 2019.

Suite di crittografia CBC SHA-2 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 di quelle simili che utilizzano GCM e la maggior parte dei server supporta entrambe le varianti GCM e CBC di queste suite di crittografia o non supporta nessuna delle due.

Nota: le app e le librerie devono intersecare l'insieme di suite di crittografia preferito con il valore restituito da getSupportedCipherSuites() per la selezione di suite di crittografia future-proof contro le rimozioni future.

Utilizzo di app

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

• Miglioramenti all'utilizzo delle app con UsageStats: Android 10 monitora con precisione l'utilizzo delle app con UsageStats quando le app vengono utilizzate in modalità schermo diviso o Picture in picture. Inoltre, Android 10 monitora correttamente l'utilizzo delle app istantanee.

• Sospensione e riproduzione: In Android 10, le app sospese non sono in grado di riprodurre l'audio.

Modifiche alla connessione HTTPS

Se un'app con Android 10 passa null a setSSLSocketFactory(), avviene un IllegalArgumentException. Nelle versioni precedenti, il passaggio di null a setSSLSocketFactory() aveva lo stesso effetto del passaggio dell'attuale fabbrica predefinita.

La libreria android.preference è deprecata

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

Modifiche alla libreria di utilità per i file ZIP

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

Gonfiatore

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

ZipFile

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

ZipOutputStream

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

Modifiche alla videocamera

Molte app che utilizzano la fotocamera presuppongono che, se il dispositivo è in una configurazione verticale, anche il dispositivo fisico sia in orientamento verticale, come descritto in Orientamento della fotocamera. In passato era un'ipotesi sicura, ma la situazione è cambiata con l'espansione dei fattori di forma disponibili, come i pieghevoli. Questa assunzione su questi dispositivi può portare a una visualizzazione errata della rotazione o della scala (o di entrambe) del mirino della fotocamera.

Le applicazioni che hanno come target il livello API 24 o versioni successive devono impostare esplicitamente android:resizeableActivity e fornire le funzionalità necessarie per gestire il funzionamento a più finestre.

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 evento di caricamento importante. In linea di massima, un evento di ricarica importante si verifica quando il dispositivo è completamente carico o quando passa da quasi scarico a quasi carico.

Prima di Android 10, le statistiche relative all'utilizzo della batteria venivano reimpostate ogni volta che il dispositivo veniva scollegato, indipendentemente da quanto fosse piccola la variazione del livello della batteria.

Ritiro di Android Beam

In Android 10 stiamo ritirando ufficialmente Android Beam, una funzionalità precedente per avviare la condivisione di dati tra dispositivi tramite NFC (Near Field Communication). Stiamo inoltre ritirando diverse 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 casi d'uso come la lettura dei tag e i 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 inserito è zero.

Modifiche al comportamento di 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 zero all'inizio dell'input. Ciò riguarda anche String.split(). Ad esempio, "x".split("") ora restituisce {"x"} mentre restituisce {"", "x"} sulle versioni precedenti di Android. "aardvark".split("(?=a)" ora restituisce {"a", "ardv", "ark"} anziché {"", "a", "ardv", "ark"}.

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

• Ora appendReplacement(StringBuffer, String) genera un messaggio di errore IllegalArgumentException anziché IndexOutOfBoundsException se il testo sostitutivo String termina con una barra inversa singola, che non è consentita. Ora viene lanciata la stessa eccezione se il valore sostitutivo String termina con $. In precedenza, in questo scenario non veniva lanciata alcuna eccezione.
• replaceFirst(null) non chiama più reset() su Matcher se genera un NullPointerException. Ora NullPointerException viene generato anche quando non c'è corrispondenza. In precedenza, veniva generato solo in caso di corrispondenza.
• start(int group), end(int group) e group(int group) ora generano un IndexOutOfBoundsException più generale se l'indice del gruppo non è compreso nell'intervallo consentito. In precedenza, questi metodi generavano un'eccezione ArrayIndexOutOfBoundsException.

L'angolo predefinito per GradientDrawable ora è TOP_BOTTOM

In Android 10, se definisci un GradientDrawable in XML e non fornisci una misurazione dell'angolo, l'orientamento del gradiente viene impostato su TOP_BOTTOM. Si tratta di un cambiamento rispetto alle versioni precedenti di Android, in cui l'impostazione predefinita 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.

Log per gli oggetti serializzati che utilizzano l'UID predefinito

A partire da Android 7.0 (livello API 24), la piattaforma ha apportato una correzione al valore predefinito serialVersionUID per gli oggetti serializzabili. Questa correzione non ha interessato le app che avevano come target il livello API 23 o versioni precedenti.

A partire da Android 10, se un'app ha come target il livello API 23 o versioni precedenti e si basa sul vecchio valore predefinito serialVersionUID errato, 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 versioni precedenti.
• Un corso viene serializzato.
• La classe serializzata utilizza il valore predefinito serialVersionUID anziché impostare esplicitamente un valore serialVersionUID.
• Il valore serialVersionUID predefinito è diverso da quello che avrebbe serialVersionUID se l'app avesse come target il livello API 24 o versioni successive.

Questo avviso viene registrato una volta per ogni classe interessata. Il messaggio di avviso include una correzione suggerita, ovvero impostare esplicitamente serialVersionUID sul valore predefinito che verrebbe calcolato se l'app avesse come target il livello API 24 o versioni successive. Se utilizzi questa correzione, puoi assicurarti che se un oggetto di questa classe viene serializzato in un'app che ha come target il livello API 23 o precedente, l'oggetto verrà letto correttamente dalle app che hanno come 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 ignoravano l'errno restituito da truncate(), ma Android 10 lancia un'eccezione IOException. Se hai bisogno del vecchio comportamento, devi utilizzare il codice nativo.