Modifiche al comportamento: tutte le app

Android 9 (livello API 28) introduce una serie di modifiche al sistema Android. Le seguenti modifiche al comportamento si applicano a tutte le app quando vengono eseguite sulla piattaforma Android 9, indipendentemente dal livello API di destinazione. Tutti gli sviluppatori devono esaminare queste modifiche e modificare le proprie app per supportarle correttamente, se applicabili all'app.

Per le modifiche che interessano solo le app che hanno come target il livello API 28 o versioni successive, consulta Modifiche al comportamento: app che hanno come target il livello API 28 e versioni successive.

Gestione alimentazione

Android 9 introduce nuove funzionalità per migliorare la gestione della carica del dispositivo. Queste modifiche, insieme alle funzionalità già presenti prima di Android 9, contribuiscono a garantire che le risorse di sistema vengano rese disponibili per le app che ne hanno più bisogno.

Per maggiori dettagli, vedi Gestione dell'alimentazione.

Modifiche alla privacy

Per migliorare la privacy degli utenti, Android 9 introduce diverse modifiche al comportamento, ad esempio la limitazione dell'accesso delle app in background ai sensori del dispositivo, la limitazione delle informazioni recuperate dalle ricerche Wi-Fi e nuove regole e nuovi gruppi di autorizzazioni relativi alle chiamate, allo stato dello smartphone e alle ricerche Wi-Fi.

Queste modifiche interessano tutte le app in esecuzione su Android 9, indipendentemente dalla versione dell'SDK di destinazione.

Accesso limitato ai sensori in background

Android 9 limita la capacità delle app in background di accedere ai dati dei sensori e all'input dell'utente. Se la tua app è in esecuzione in background su un dispositivo con Android 9, il sistema applica le seguenti limitazioni all'app:

• La tua app non può accedere al microfono o alla fotocamera.
• I sensori che utilizzano la modalità di generazione di report continuo, come accelerometri e giroscopi, non ricevono eventi.
• I sensori che utilizzano le modalità di generazione dei report al variare o una tantum non ricevono eventi.

Se la tua app deve rilevare eventi del sensore su dispositivi con Android 9, utilizza un servizio in primo piano.

Accesso limitato ai registri chiamate

Android 9 introduce il gruppo di autorizzazioni CALL_LOG e sposta le autorizzazioni READ_CALL_LOG, WRITE_CALL_LOG e PROCESS_OUTGOING_CALLS in questo gruppo. Nelle versioni precedenti di Android, queste autorizzazioni si trovavano nel gruppo di autorizzazioni PHONE.

Questo gruppo di autorizzazioni CALL_LOG offre agli utenti un maggiore controllo e visibilità sulle app che devono accedere a informazioni sensibili sulle chiamate, ad esempio la lettura dei registri delle chiamate e l'identificazione dei numeri di telefono.

Se la tua app richiede l'accesso ai registri chiamate o deve elaborare le chiamate in uscita, devi richiedere esplicitamente queste autorizzazioni dal gruppo di autorizzazioni CALL_LOG. In caso contrario, viene visualizzato un messaggio SecurityException.

Accesso limitato ai numeri di telefono

Le app in esecuzione su Android 9 non possono leggere i numeri di telefono o lo stato del telefono senza acquistare prima l'autorizzazione READ_CALL_LOG, oltre alle altre autorizzazioni richieste dai casi d'uso della tua app.

I numeri di telefono associati alle chiamate in arrivo e in uscita sono visibili nel broadcast dello stato dello smartphone, ad esempio per le chiamate in arrivo e in uscita e sono accessibili dalla classe PhoneStateListener. Tuttavia, senza l'autorizzazione READ_CALL_LOG il campo del numero di telefono fornito nelle trasmissioni PHONE_STATE_CHANGED e tramite PhoneStateListener è vuoto.

Per leggere i numeri di telefono dallo stato dello smartphone, aggiorna l'app in modo da richiedere le autorizzazioni necessarie in base al tuo caso d'uso:

• Per leggere i numeri dall'azione intent PHONE_STATE, hai bisogno sia dell'autorizzazione READ_CALL_LOG che dell'autorizzazione READ_PHONE_STATE.
• Per leggere i numeri da onCallStateChanged(), è necessaria solo l'autorizzazione READ_CALL_LOG. Non è necessaria l'autorizzazione READ_PHONE_STATE.

Accesso limitato alle informazioni sulla posizione e sulla connessione Wi-Fi

In Android 9, i requisiti di autorizzazione per consentire a un'app di eseguire ricerche di reti Wi-Fi sono più rigorosi rispetto alle versioni precedenti. Per maggiori dettagli, consulta Limitazioni della ricerca Wi-Fi.

Limitazioni simili si applicano anche al metodo getConnectionInfo(), che restituisce un oggetto WifiInfo che descrive la connessione Wi-Fi corrente. Puoi utilizzare i metodi di questo oggetto solo per recuperare i valori SSID e BSSID se l'app chiamante dispone delle seguenti autorizzazioni:

• ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION
• ACCESS_WIFI_STATE

Per recuperare l'SSID o il BSSID, è necessario anche attivare i servizi di localizzazione sul dispositivo (in Impostazioni > Posizione).

Informazioni rimosse dai metodi di servizio Wi-Fi

In Android 9, i seguenti eventi e trasmissioni non ricevono informazioni sulla posizione dell'utente o su dati di identificazione personale:

• I metodi getScanResults() e getConnectionInfo() da WifiManager.
• I metodi discoverServices() e addServiceRequest() da WifiP2pManager.
• L'annuncio NETWORK_STATE_CHANGED_ACTION.

Il broadcast di sistema NETWORK_STATE_CHANGED_ACTION dal Wi-Fi non contiene più SSID (in precedenza EXTRA_SSID), BSSID (in precedenza EXTRA_BSSID) o informazioni di connessione (in precedenza EXTRA_NETWORK_INFO). Se la tua app ha bisogno di queste informazioni, chiama getConnectionInfo() instead.

Le informazioni di telefonia ora si basano sull'impostazione di geolocalizzazione del dispositivo

Se l'utente ha disattivato la localizzazione del dispositivo su un dispositivo con Android 9, i seguenti metodi non forniscono risultati:

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

Restrizioni relative all'utilizzo di interfacce non SDK

Per garantire la stabilità e la compatibilità delle app, la piattaforma limita l'utilizzo di alcuni metodi e campi non SDK. Queste limitazioni si applicano anche se si tenta di accedere a questi metodi e campi direttamente, tramite la riflessione o utilizzando JNI. In Android 9, la tua app può continuare ad accedere a queste interfacce limitate. La piattaforma utilizza avvisi e voci di log per richiamarle alla tua attenzione. Se la tua app mostra un messaggio di questo tipo, è importante che tu scelga una strategia di implementazione diversa dall'interfaccia con restrizioni. Se ritieni che non sia possibile adottare una strategia alternativa, puoi segnalare un bug per richiedere una rivalutazione della limitazione.

La pagina Limitazioni relative alle interfacce non SDK contiene ulteriori informazioni importanti. Ti consigliamo di esaminarlo per assicurarti che la tua app continui a funzionare correttamente.

Modifiche al comportamento della sicurezza

Modifiche alla sicurezza del dispositivo

Android 9 aggiunge diverse funzionalità che migliorano la sicurezza della tua app, indipendentemente dalla versione di destinazione.

Modifiche all'implementazione di TLS

L'implementazione di TLS del sistema ha subito diverse modifiche in Android 9:

• Se un'istanza di SSLSocket non riesce a collegarsi durante la creazione, il sistema genera un IOException anziché un NullPointerException.
• La classe SSLEngine gestisce in modo pulito eventuali allarmi close_notify che si verificano.

Per scoprire di più su come effettuare richieste web sicure in un'app per Android, consulta Un esempio di HTTPS.

Filtro SECCOMP più rigoroso

Android 9 limita ulteriormente le chiamate di sistema disponibili per le app. Questo comportamento è un'estensione del filtro SECCOMP incluso in Android 8.0 (livello API 26).

Modifiche alla crittografia

Android 9 introduce diverse modifiche all'implementazione e alla gestione degli algoritmi di crittografia.

Implementazioni di Conscrypt di parametri e algoritmi

Android 9 fornisce implementazioni aggiuntive dei parametri dell'algoritmo in Conscrypt. Questi parametri includono: AES, DESEDE, OAEP ed EC. Le versioni di Bouncy Castle di questi parametri e di molti algoritmi sono state ritirate a partire da Android 9.

Se la tua app ha come target Android 8.1 (livello API 27) o versioni precedenti, riceverai un avviso quando richiedi l'implementazione di Bouncy Castle di uno di questi algoritmi ritirati. Tuttavia, se scegli come target Android 9, ciascuna di queste richieste genera un messaggio di errore NoSuchAlgorithmException.

Altre modifiche

Android 9 introduce diverse altre modifiche relative alla crittografia:

• Quando utilizzi le chiavi PBE, se Bouncy Castle si aspetta un vettore di inizializzazione (IV) e la tua app non ne fornisce uno, ricevi un avviso.
• L'implementazione di Conscrypt del cifrario ARC4 consente di specificare ARC4/ECB/NoPadding o ARC4/NONE/NoPadding.
• Il provider Crypto Java Cryptography Architecture (JCA) è stato rimosso. Di conseguenza, se la tua app chiama SecureRandom.getInstance("SHA1PRNG", "Crypto"), viene visualizzato un messaggio NoSuchProviderException.
• Se l'app analizza le chiavi RSA da buffer più grandi della struttura della chiave, non si verifica più un'eccezione.

Per scoprire di più sull'utilizzo delle funzionalità di crittografia di Android, consulta Crittografia.

I file criptati protetti di Android non sono più supportati

Android 9 rimuove completamente il supporto per i file con crittografia sicura Android (ASEC).

In Android 2.2 (livello API 8), Android ha introdotto gli ASEC per supportare la funzionalità delle app sulla scheda SD. Su Android 6.0 (livello API 23), la piattaforma ha introdotto una tecnologia di dispositivo di archiviazione adottabile che gli sviluppatori possono utilizzare al posto degli ASEC.

Aggiornamenti alle librerie ICU

Android 9 utilizza la versione 60 della libreria ICU. Android 8.0 (livello API 26) e Android 8.1 (livello API 27) utilizzano ICU 58.

ICU viene utilizzato per fornire API pubbliche sotto android.icu package e viene utilizzato internamente nella piattaforma Android per il supporto dell'internazionalizzazione. Ad esempio, viene utilizzato per implementare le classi Android in java.util, java.text e android.text.format.

L'aggiornamento a ICU 60 contiene molte piccole ma utili modifiche, tra cui il supporto dei dati Emoji 5.0 e formati di data/ora migliorati, come documentato nelle note di rilascio di ICU 59 e ICU 60.

Modifiche principali in questo aggiornamento:

• Il modo in cui la piattaforma gestisce i fusi orari è cambiato.
  • La piattaforma gestisce meglio GMT e UTC; UTC non è più sinonimo di GMT.

    ICU ora fornisce i nomi delle zone tradotti per GMT e UTC. Questa modifica influisce sul comportamento di formattazione e analisi sintattica di android.icu per le zone come "GMT", "Etc/GMT", "UTC", "Etc/UTC" e "Zulu".

  • java.text.SimpleDateFormat ora utilizza ICU per fornire nomi visualizzati per UTC /GMT, il che significa che:
    • La formattazione zzzz genera una stringa localizzata lunga per molti paesi. In precedenza, generava "UTC" per UTC e stringhe come "GMT+00:00" per GMT.
    • L'analisi zzzz riconosce stringhe come "Universal Coordinated Time" e "Greenwich Mean Time".
    • Le app potrebbero riscontrare problemi di compatibilità se presuppongono che "UTC" o "GMT+00:00" vengano visualizzati per zzzz in tutte le lingue.
  • Il comportamento di java.text.DateFormatSymbols.getZoneStrings() è cambiato:
    • Come per SimpleDateFormat, ora UTC e GMT hanno nomi lunghi. Le varianti con ora legale dei nomi dei fusi orari per la zona UTC, ad esempio "UTC", "Etc/UTC" e "Zulu", diventano GMT+00:00, che è il valore predefinito quando non sono disponibili nomi, anziché la stringa hardcoded UTC.
    • Alcuni ID zona vengono riconosciuti correttamente come sinonimi di altre zone, in modo che Android trovi stringhe per ID zona arcaici, come Eire, che in precedenza non potevano essere risolti.
  • Asia/Hanoi non è più una zona riconosciuta. Per questo motivo, java.util.TimeZones.getAvailableIds() non restituisce questo valore e java.util.TimeZone.getTimeZone() non lo riconosce. Questo comportamento è coerente con il comportamento android.icu esistente.
• Il metodo android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) può generare un ParseException anche durante l'analisi del testo della valuta legittimo. Evita questo problema utilizzando NumberFormat.parseCurrency, disponibile da Android 7.0 (livello API 24), per il testo della valuta in stile PLURALCURRENCYSTYLE.

Modifiche ad Android Test

Android 9 introduce diverse modifiche alla libreria e alla struttura delle classi del framework Android Test. Queste modifiche aiutano gli sviluppatori a utilizzare API pubbliche supportate dal framework, ma consentono anche una maggiore flessibilità nella creazione e nell'esecuzione di test utilizzando librerie di terze parti o logica personalizzata.

Librerie rimosse dal framework

Android 9 riorganizza le classi basate su JUnit in tre librerie: android.test.base, android.test.runner e android.test.mock. Questa modifica ti consente di eseguire test su una versione di JUnit che funziona meglio con le dipendenze del tuo progetto. Questa versione di JUnit potrebbe essere diversa da quella fornita da android.jar.

Per scoprire di più su come le classi basate su JUnit sono organizzate in queste librerie e su come preparare il progetto dell'app per scrivere ed eseguire i test, consulta Configurare il progetto per Android Test.

Modifiche alla build della suite di test

Il metodo addRequirements() della classe TestSuiteBuilder è stato rimosso e la classe TestSuiteBuilder stessa è stata ritirata. Il metodo addRequirements() richiedeva agli sviluppatori di fornire argomenti i cui tipi sono API nascoste, rendendo l'API non valida.

Decodificatore UTF Java

UTF-8 è il set di caratteri predefinito in Android. Una sequenza di byte UTF-8 può essere decodificata da un costruttore String, ad esempio String(byte[] bytes).

Il decodificatore UTF-8 in Android 9 segue gli standard Unicode più rigorosamente rispetto alle versioni precedenti. Le modifiche includono:

• La forma non più breve di UTF-8, ad esempio <C0, AF>, viene considerata non valida.
• La forma surrogata di UTF-8, ad esempio U+D800..U+DFFF, viene considerata come non formattata correttamente.
• La sottoparte massima viene sostituita da un singolo U+FFFD. Ad esempio, nella sequenza di byte "41 C0 AF 41 F4 80 80 41", le parti massime sono "C0", "AF" e "F4 80 80". "F4 80 80" può essere la sottosezione iniziale di "F4 80 80 80", ma "C0" non può essere la sottosezione iniziale di alcuna sequenza di unità di codice ben formattata. Pertanto, l'output dovrebbe essere "A\ufffd\ufffdA\ufffdA".
• Per decodificare una sequenza UTF-8 / CESU-8 modificata in Android 9 o versioni successive, utilizza il metodo DataInputStream.readUTF() o il metodo JNI NewStringUTF().

Verifica del nome host utilizzando un certificato

L'RFC 2818 descrive due metodi per associare un nome di dominio a un certificato: utilizzando i nomi disponibili nell'estensione subjectAltName (SAN) o, in assenza di un'estensione SAN, utilizzando commonName (CN).

Tuttavia, il fallback al CN è stato deprecato nell'RFC 2818. Per questo motivo, Android non utilizza più il CN come opzione di riserva. Per verificare un nome host, il server deve presentare un certificato con un SAN corrispondente. I certificati che non contengono un SAN corrispondente al nome host non sono più attendibili.

Le ricerche degli indirizzi di rete possono causare violazioni della rete

Le ricerche di indirizzi di rete che richiedono la risoluzione dei nomi possono comportare I/O di rete e pertanto sono considerate operazioni di blocco. Le operazioni di blocco sul thread principale possono causare interruzioni o scatti.

La classe StrictMode è uno strumento di sviluppo che aiuta gli sviluppatori a rilevare i problemi nel codice.

In Android 9 e versioni successive, StrictMode rileva le violazioni della rete causate da ricerche di indirizzi di rete che richiedono la risoluzione dei nomi.

Non devi distribuire le tue app con StrictMode abilitato. In questo caso, le tue app possono presentare eccezioni, ad esempio NetworkOnMainThreadException quando utilizzi i metodi detectNetwork() o detectAll() per ottenere un criterio che rileva le violazioni della rete.

La risoluzione di un indirizzo IP numerico non è considerata un'operazione di blocco. La risoluzione degli indirizzi IP numerici funziona come nelle versioni precedenti ad Android 9.

Tagging delle prese

Nelle versioni della piattaforma precedenti ad Android 9, se una socket è contrassegnata utilizzando il metodo setThreadStatsTag(), la socket viene rimossa quando viene inviata a un altro processo utilizzando binder IPC con un contenitore ParcelFileDescriptor.

In Android 9 e versioni successive, il tag socket viene mantenuto quando viene inviato a un altro processo utilizzando l'IPC Binder. Questa modifica può influire sulle statistiche sul traffico di rete, ad esempio quando si utilizza il metodoqueryDetailsForUidTag().

Se vuoi mantenere il comportamento delle versioni precedenti, che annulla il tagging di una socket inviata a un altro processo, puoi chiamare untagSocket() prima di inviare la socket.

Quantità di byte disponibili nel socket registrata

Il metodo available() restituisce 0 quando viene chiamato dopo l'invocazione del metodo shutdownInput().

Report più dettagliati sulle funzionalità di rete per le VPN

In Android 8.1 (livello API 27) e versioni precedenti, la classe NetworkCapabilities riportava solo un insieme limitato di informazioni per le VPN, ad esempio TRANSPORT_VPN, omettendo NET_CAPABILITY_NOT_VPN. Queste informazioni limitate hanno reso difficile stabilire se l'utilizzo di una VPN comportasse addebiti per l'utente dell'app. Ad esempio, il controllo di NET_CAPABILITY_NOT_METERED non consente di determinare se le reti sottostanti sono conteggiate o meno.

In Android 9 e versioni successive, quando una VPN chiama il metodosetUnderlyingNetworks(), il sistema Android unisce i trasporti e le funzionalità di eventuali reti sottostanti e restituisce il risultato come funzionalità di rete effettive della rete VPN.

In Android 9 e versioni successive, le app che controllano già la presenza diNET_CAPABILITY_NOT_METERED ricevono le funzionalità di rete della VPN e delle reti di base.

I file nella cartella xt_qtaguid non sono più disponibili per le app

A partire da Android 9, le app non sono autorizzate ad avere accesso diretto in lettura ai file nella cartella /proc/net/xt_qtaguid. Il motivo è garantire la coerenza con alcuni dispositivi che non dispongono di questi file.

Le API pubbliche che si basano su questi file, TrafficStats e NetworkStatsManager, continuano a funzionare come previsto. Tuttavia, le funzioni di cutils non supportate, come qtaguid_tagSocket(), potrebbero non funzionare come previsto o non funzionare affatto su dispositivi diversi.

Il requisito FLAG_ACTIVITY_NEW_TASK è ora applicato

Con Android 9, non puoi avviare un'attività da un contesto non di attività, a meno che non passi il flag intent FLAG_ACTIVITY_NEW_TASK. Se provi ad avviare un'attività senza passare questo flag, l'attività non si avvia e il sistema stampa un messaggio nel log.

Modifiche alla rotazione dello schermo

A partire da Android 9, sono state apportate modifiche significative alla modalità di rotazione Ritratto. In Android 8.0 (livello API 26), gli utenti potevano passare dalla modalità di rotazione automatica a quella ritratto utilizzando un riquadro Impostazioni rapide o le impostazioni di visualizzazione. La modalità Ritratto è stata rinominata blocco rotazione e viene attivata quando la rotazione automatica è disattivata. La modalità di rotazione automatica rimane invariata.

Quando il dispositivo è in modalità di blocco della rotazione, gli utenti possono bloccare lo schermo su qualsiasi rotazione supportata dall'attività visibile in alto. Un'attività non deve assumere che verrà sempre visualizzata in formato verticale. Se l'attività principale può essere visualizzata con più rotazioni in modalità di rotazione automatica, le stesse opzioni dovrebbero essere disponibili in modalità di rotazione bloccata, con alcune eccezioni in base all'impostazione screenOrientation dell'attività (vedi la tabella di seguito).

Le attività che richiedono un orientamento specifico (ad esempioscreenOrientation=landscape) ignorano la preferenza di blocco dell'utente e si comportano come in Android 8.0.

La preferenza di orientamento dello schermo può essere impostata a livello di attività in Android Manifest o tramite codice con setRequestedOrientation().

La modalità di blocco della rotazione funziona impostando la preferenza di rotazione dell'utente utilizzata da WindowManager per gestire la rotazione dell'attività. La preferenza di rotazione dell'utente potrebbe essere modificata nei seguenti casi. Tieni presente che esiste una tendenza a tornare alla rotazione naturale del dispositivo, che in genere è in verticale per i dispositivi con fattore di forma dello smartphone:

• Quando l'utente accetta un suggerimento di rotazione, la preferenza di rotazione viene modificata in base al suggerimento.
• Quando l'utente passa a un'app in modalità Ritratto forzata (inclusa la schermata di blocco o il programma di avvio), la preferenza di rotazione passa a Ritratto.

La seguente tabella riassume il comportamento di rotazione per gli orientamenti dello schermo più comuni:

Orientamento schermo	Comportamento
unspecified, user	In Rotazione automatica e Blocco rotazione, l'attività può essere visualizzata in formato verticale o orizzontale (e viceversa). Dovresti supportare i layout sia verticali che orizzontali.
userLandscape	In rotazione automatica e blocco rotazione, l'attività può essere visualizzata in orizzontale o in verticale. Dovresti supportare solo i layout orizzontali.
userPortrait	Con la rotazione automatica e il blocco della rotazione, l'attività può essere visualizzata in formato Ritratto o Ritratto inverso. Dovresti supportare solo i layout verticali.
fullUser	In Rotazione automatica e Blocco rotazione, l'attività può essere visualizzata in formato verticale o orizzontale (e viceversa). Dovresti supportare sia i layout verticali che orizzontali. Gli utenti con il blocco di rotazione avranno la possibilità di bloccare l'orientamento verticale inverso, spesso a 180°.
sensore, fullSensor, sensoreRitratto, sensoreOrizzontale	La preferenza della modalità di blocco della rotazione viene ignorata e trattata come se la rotazione automatica fosse attiva. Utilizza questa opzione solo in circostanze eccezionali e con un'attenta considerazione dell'esperienza utente.

Il ritiro del client HTTP Apache interessa le app con ClassLoader non standard

Con Android 6.0, abbiamo rimosso il supporto per il client HTTP Apache. Questa modifica non ha alcun effetto sulla maggior parte delle app che non hanno come target Android 9 o versioni successive. Tuttavia, la modifica può interessare alcune app che utilizzano una struttura ClassLoader non standard, anche se le app non hanno come target Android 9 o versioni successive.

Un'app può essere interessata se utilizza un ClassLoader non standard che delega esplicitamente al ClassLoader di sistema. Quando cercano corsi in org.apache.http.*, queste app devono delegare all'app ClassLoader. Se delegato al sistema ClassLoader, le app non funzioneranno su Android 9 o versioni successive con un NoClassDefFoundError, perché queste classi non sono più conosciute dal sistema ClassLoader. Per evitare problemi simili in futuro, in genere le app dovrebbero caricare i corsi tramite l'app ClassLoader anziché accedere direttamente al sistema ClassLoader.

Elenco delle videocamere

Le app in esecuzione sui dispositivi Android 9 possono rilevare tutte le videocamere disponibili chiamando getCameraIdList(). Un'app non deve presumere che il dispositivo abbia una sola fotocamera posteriore o una sola fotocamera anteriore.

Ad esempio, se la tua app ha un pulsante per passare dalla fotocamera anteriore a quella posteriore e viceversa, potrebbe essere disponibile più di una fotocamera anteriore o posteriore tra cui scegliere. Devi esaminare l'elenco delle videocamere, le caratteristiche di ciascuna e decidere quali mostrare all'utente.