Modifiche al 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 necessità per supportare correttamente queste modifiche.

Se il valore targetSdkVersion della tua app è 29 o superiore, dovrai anche supportare modifiche aggiuntive. Per maggiori dettagli, assicurati di leggere le modifiche del comportamento per le app che hanno come target 29.

Limitazioni relative alle interfacce non SDK

Per 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 limitate in base alla collaborazione con gli sviluppatori Android e ai test interni più recenti. Il nostro obiettivo è garantire 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 interruzione dell'app.

Se non sai 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 una 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à della 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 tramite gesti su tutto il dispositivo. Se un utente attiva la navigazione tramite gesti, questa opzione influisce su tutte le app sul dispositivo, indipendentemente dal fatto che l'app abbia come livello API target il livello API 29. Ad esempio, se l'utente scorre verso l'interno dal bordo dello schermo, il sistema interpreta questo gesto come una navigazione a ritroso, a meno che un'app non esegua l'override specifico di questo gesto per parti dello schermo.

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

NDK

Android 10 include le seguenti modifiche all'NDK.

Gli oggetti condivisi non possono contenere rilocazioni di testo

Android 6.0 (livello API 23) non consentiva l'utilizzo di rilocazioni di testo negli oggetti condivisi. Il codice deve essere caricato così com'è e non deve essere modificato. Questa modifica migliora i tempi di caricamento e la sicurezza 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 rilocazioni 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 normali. Le app che si basano sui percorsi come 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 da lib64/.

Per garantire la compatibilità, i collegamenti simbolici vengono 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 troveranno la differenza quando provano effettivamente a esaminare le librerie caricate leggendo /proc/self/maps o simili, il che non è usuale, ma abbiamo scoperto che alcune app lo fanno nell'ambito del loro processo anti-hacking. In questo caso, i percorsi /apex/… devono essere aggiunti come percorsi validi per i file Bionic.

File binari/librerie di sistema mappati alla memoria di sola esecuzione

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

Puoi identificare se questo comportamento ha causato un arresto anomalo esaminando il file tombstone correlato in /data/tombstones/. Un arresto anomalo relativo alla modalità di sola esecuzione contiene il seguente messaggio di interruzione:

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

Per risolvere questo problema ed eseguire operazioni come il Controllo memoria, è possibile contrassegnare i segmenti di sola esecuzione come lettura+esecuzione chiamando mprotect(). Tuttavia, ti consigliamo vivamente di reimpostarla su "Solo esecuzione" in un secondo momento, poiché questa impostazione di autorizzazione di accesso offre una protezione migliore per la tua app e i tuoi utenti.

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 cifrari TLS 1.3 supportate sono sempre attive quando TLS 1.3 è abilitato. 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 che le sessioni sono state aggiunte alla cache delle sessioni.
• In alcune situazioni in cui le istanze SSLEngine generano un SSLHandshakeException su versioni precedenti di Android, queste istanze generano invece un SSLProtocolException 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 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 considerati 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 emettono questo 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 è a un sito che presenta un certificato che utilizza SHA-1.

Modifiche e miglioramenti del 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 i parametri di specifica delle chiavi e delle autorità di certificazione quando chiamano KeyChain.choosePrivateKeyAlias() per mostrare agli utenti un prompt 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, ad esempio quando nessun certificato corrisponde alla specifica del server o se su un dispositivo non sono installati certificati, il prompt di selezione del certificato non viene visualizzato.

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 relative a TLS e crittografia

Sono state apportate diverse modifiche minori alle librerie TLS e di crittografia che diventano effettive su Android 10:

• I sistemi di crittografia AES/GCM/NoPadding e ChaCha20/Poly1305/NoPadding restituiscono dimensioni del buffer più accurate da getOutputSize().
• La suite di crittografia TLS_FALLBACK_SCSV viene omessa dai tentativi di connessione con un protocollo massimo TLS 1.2 o versioni successive. A causa dei miglioramenti nelle implementazioni dei server TLS, sconsigliamo di tentare il fallback esterno a TLS. Ti 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 quando si sceglie una chiave di firma per le risposte dei certificati.
• Le chiavi di firma opache, come quelle di Android Keystore, 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 fisse:

• 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 sticky, 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 dati Wi-Fi Aware. Per creare un socket TCP/UDP che si connetta a un ServerSocket, il dispositivo client deve conoscere l'indirizzo IPv6 e la porta del server. In precedenza, questo doveva essere comunicato fuori banda, ad esempio utilizzando la messaggistica di livello 2 BT o Wi-Fi Aware, o rilevato in banda utilizzando altri protocolli, come mDNS. Con Android 10, le informazioni possono essere comunicate nell'ambito della 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 nell'ambito della richiesta di rete:

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

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:

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)

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 su dispositivi Android 10 (Go edition) non possono ricevere l'autorizzazione SYSTEM_ALERT_WINDOW. Questo perché il disegno di finestre in overlay utilizza una quantità eccessiva di memoria, il che è particolarmente dannoso per le prestazioni dei dispositivi Android con poca memoria.

Se un'app in esecuzione su un dispositivo Go edition con Android 9 o versioni precedenti riceve l'autorizzazione SYSTEM_ALERT_WINDOW, l'app conserva l'autorizzazione anche se viene eseguito l'upgrade del dispositivo ad Android 10. Tuttavia, alle app che non dispongono già di questa autorizzazione non può essere concessa 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 che indica che l'autorizzazione non è consentita perché rallenta il dispositivo. Se un'app su un dispositivo Go chiama Settings.canDrawOverlays(), il metodo restituisce sempre false. Anche in questo caso, 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 di Android precedenti

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 autorizzazioni, l'utente ha anche la possibilità di modificare le autorizzazioni dell'app prima che questa possa essere eseguita per la prima volta.

A causa dei requisiti relativi ai livelli 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, requisiti simili relativi ai livelli API target entreranno in vigore nel corso del 2019. Per saperne di più su questi requisiti, consulta l'articolo Ampliamento dei requisiti relativi ai livelli API target nel 2019.

Suite di crittografia SHA-2 CBC rimosse

Le seguenti suite di crittografia SHA-2 CBC 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 ne supporta nessuna.

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.

• Scala di grigi per app - Android 10 può impostare una modalità di visualizzazione in scala di grigi per app.

• Stato di distrazione per app: Android 10 può impostare selettivamente le app su uno "stato di distrazione" in cui le notifiche vengono soppresse e le app non vengono visualizzate come app suggerite.

• Sospensione e riproduzione - In Android 10, le app sospese non possono riprodurre audio.

Modifiche alla connessione HTTPS

Se un'app con Android 10 passa null a setSSLSocketFactory(), si verifica un IllegalArgumentException. Nelle versioni precedenti, il passaggio di null a setSSLSocketFactory() aveva lo stesso effetto del passaggio della factory predefinita corrente.

La libreria android.preference è deprecata

La libreria android.preference è deprecata a partire da Android 10. Gli sviluppatori devono invece utilizzare la libreria delle 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à dei file ZIP

Android 10 introduce le seguenti modifiche alle classi nel 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.

Inflater

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

ZipFile

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

ZipOutputStream

In Android 10 e versioni successive, il metodo finish() in ZipOutputStream non genera un'eccezione ZipException se tenta di scrivere un flusso 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 configurazione verticale, anche il dispositivo fisico è in orientamento verticale, come descritto in Orientamento della fotocamera. In passato questa era un'ipotesi sicura, ma le cose sono cambiate con l'espansione dei fattori di forma disponibili, come i pieghevoli. Questa ipotesi su questi dispositivi può portare a una visualizzazione del mirino della fotocamera ruotata o ridimensionata in modo errato (o entrambe le cose).

Le applicazioni che hanno come livello API target il livello 24 o versioni successive devono impostare esplicitamente android:resizeableActivity e fornire le funzionalità necessarie per gestire il funzionamento in modalità 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 evento di ricarica importante. In generale, un evento di ricarica importante è uno dei seguenti: il dispositivo è stato ricaricato completamente o è passato da quasi scarico a quasi carico.

Prima di Android 10, le statistiche sull'utilizzo della batteria venivano reimpostate ogni volta che il dispositivo veniva scollegato, indipendentemente dalla variazione del livello batteria.

Ritiro di Android Beam

In Android 10, Android Beam, una funzionalità precedente per avviare la condivisione dei dati tra dispositivi tramite NFC (Near Field Communication), è ufficialmente deprecata. Stiamo anche ritirando diverse API NFC correlate. Android Beam rimane disponibile come opzione per i partner produttori di dispositivi che vogliono utilizzarlo, ma non è più in fase di sviluppo attivo. Tuttavia, Android continuerà a supportare altre funzionalità e API NFC e i casi d'uso come la lettura da 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 di input è zero.

Modifiche al comportamento di java.util.regex.Matcher e Pattern

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

Anche il comportamento delle eccezioni per gli argomenti non validi è stato migliorato:

• appendReplacement(StringBuffer, String) ora genera un'eccezione IllegalArgumentException anziché IndexOutOfBoundsException se la sostituzione String termina con una singola barra rovesciata, il che non è consentito. La stessa eccezione viene ora generata se la sostituzione String termina con $. In precedenza, in questo scenario non veniva generata alcuna eccezione.
• replaceFirst(null) non chiama più reset() su Matcher se genera un NullPointerException. Ora viene generato anche NullPointerException quando non esiste una corrispondenza. In precedenza, veniva generato solo quando veniva trovata una corrispondenza.
• start(int group), end(int group) e group(int group) ora generano un IndexOutOfBoundsException più generale se l'indice del gruppo non rientra nei limiti. In precedenza, questi metodi generavano 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 per impostazione predefinita. Si tratta di una modifica 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 legacy se non viene specificata alcuna misurazione dell'angolo.

Logging per oggetti serializzati che utilizzano il SUID predefinito

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

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

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

• L'app ha come target il livello API 23 o versioni precedenti.
• Una classe è serializzata.
• La classe serializzata utilizza il valore predefinito serialVersionUID, anziché impostare esplicitamente un valore serialVersionUID.
• Il valore predefinito di serialVersionUID è diverso da quello di 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 livello API target il livello API 24 o versioni successive. Utilizzando questa correzione, puoi assicurarti che, se un oggetto di quella classe viene serializzato su un'app che ha come livello API target il livello 23 o precedente, l'oggetto verrà letto correttamente dalle app che hanno come livello API target il livello 24 o successivo 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 genera un'eccezione IOException. Se hai bisogno del comportamento precedente, devi utilizzare il codice nativo.