Android 10 include modifiche aggiornate del comportamento del sistema che potrebbero interessare la tua app.
Le modifiche elencate in questa pagina si applicano esclusivamente alle app che hanno come target
l'API 29 o versioni successive. Se la tua app imposta targetSdkVersion su "29" o
un valore superiore, devi modificare l'app per supportare correttamente questi comportamenti,
ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano tutte le app eseguite su Android 10.
Nota : oltre alle modifiche elencate in questa pagina, Android 10 introduce un gran numero di modifiche e limitazioni basate sulla privacy, tra cui:
- Archiviazione mirata
- Accesso al numero di serie del dispositivo USB
- Possibilità di attivare, disattivare e configurare il Wi-Fi
- Autorizzazioni di accesso alla posizione per le API di connettività
Queste modifiche, che interessano le app destinate al livello API target 29 o successivi, migliorano la privacy degli utenti. Per scoprire di più su come supportare queste modifiche, consulta la pagina Modifiche relative alla privacy.
Aggiornamenti alle limitazioni delle interfacce non SDK
Per garantire la stabilità e la compatibilità dell'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 agli ultimi test interni. Il nostro obiettivo è assicurarci che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.
Se non sceglierai 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 metodi o campi 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, devi iniziare a pianificare una migrazione alle alternative all'SDK. Ciononostante, 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 scoprire di più, consulta Aggiornamenti alle limitazioni delle interfacce non SDK in Android 10 e Limitazioni sulle interfacce non SDK.
Ricordo condiviso
Ashmem ha cambiato il formato delle mappe Dalvik in /proc/<pid>/maps, influenzando le app che analizzano direttamente il file delle mappe. Gli sviluppatori di applicazioni dovrebbero testare il formato /proc/<pid>/maps sui dispositivi con Android 10 o versioni successive e analizzare di conseguenza se l'app dipende dai formati delle mappe Dalvik.
Le app che hanno come target Android 10 non possono utilizzare direttamente ashmem
(/dev/ashmem) e devono invece accedere alla memoria condivisa tramite la
classe ASharedMemory di NDK.
Inoltre, le app non possono generare IOCTL dirette ai descrittori dei file ashmem esistenti, ma devono utilizzare la classe ASharedMemory di NDK o le API Java di Android per creare regioni di memoria condivise. Questa modifica aumenta la sicurezza
e robustezza quando si lavora con la memoria condivisa, migliorando le prestazioni e la sicurezza
di Android in generale.
È stata rimossa l'autorizzazione di esecuzione per la home directory dell'app
L'esecuzione dei file dalla home directory dell'app scrivibile è una violazione W^X. Le app devono caricare soltanto il codice binario incorporato nel file APK dell'app.
Le app non attendibili che hanno come target Android 10 non possono richiamare execve()
direttamente sui file all'interno della home directory dell'app.
Inoltre, le app destinate ad Android 10 non possono modificare in memoria il codice eseguibile dei file che sono stati aperti con dlopen() e si aspettano che le modifiche vengano scritte tramite il disco, perché la libreria non può essere stata mappata PROT_EXEC tramite un descrittore di file scrivibile. Sono inclusi i file di qualsiasi oggetto condiviso (.so) con rilocazioni del testo.
Il runtime Android accetta solo file OAT generati dal sistema
Il runtime Android (ART) non richiama più dex2oat dal processo di applicazione. Questa modifica significa che ART accetterà solo file OAT generati dal sistema.
Applicare la correttezza AOT in ART
In passato, la compilazione anticipata (AOT) eseguita dall'Android Runtime (ART) poteva causare arresti anomali di runtime se l'ambiente classpath non era lo stesso in fase di compilazione e runtime. Android 10 e versioni successive richiedono sempre che questi contesti dell'ambiente siano gli stessi, il che comporta i seguenti cambiamenti di comportamento:
- I caricatori di classi personalizzati, ovvero i caricatori di classi scritti da app, a differenza dei caricatori di classi del pacchetto
dalvik.system, non sono compilati AOT. Questo perché ART non può conoscere l'implementazione personalizzata della ricerca di classe in fase di runtime. - I file dex secondari, ovvero i file dex caricati manualmente da app non presenti nell'APK principale, vengono compilati AOT in background. Questo perché la compilazione al primo utilizzo potrebbe essere troppo costosa, causando una latenza indesiderata prima dell'esecuzione. Tieni presente che per le app è consigliabile adottare le divisioni e abbandonare i file Dex secondari.
- Le librerie condivise in Android (le voci <library> e <uses-library> in un manifest Android) vengono implementate utilizzando una gerarchia di caricamento delle classi diversa da quella utilizzata nelle versioni precedenti della piattaforma.
Modifiche delle autorizzazioni per gli intent a schermo intero
Le app destinate ad Android 10 o versioni successive che utilizzano notifiche con
intent
a schermo intero devono richiedere
l'autorizzazione
USE_FULL_SCREEN_INTENT
nel file manifest dell'app. Si tratta di un'autorizzazione normale, quindi il sistema la concede automaticamente all'app richiedente.
Se un'app destinata ad Android 10 o versioni successive tenta di creare una notifica con un intent a schermo intero senza richiedere l'autorizzazione necessaria, il sistema ignora l'intent a schermo intero e restituisce il seguente messaggio di log:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Supporto per pieghevoli
Android 10 è stato sottoposto ad alcune modifiche che supportano i dispositivi pieghevoli e con schermi di grandi dimensioni.
Quando un'app viene eseguita su Android 10, i metodi
onResume() e
onPause() funzionano
in modo diverso. Quando più app vengono visualizzate contemporaneamente in modalità multi-finestra o multi-display, tutte le attività principali attivabili negli stack visibili sono nello stato ripreso, mentre solo una di queste, l'attività "più alta ripresa", viene evidenziata. Se utilizzi versioni precedenti ad Android 10, è possibile riprendere solo
una singola attività nel sistema alla volta, mentre tutte le altre attività visibili
vengono messe in pausa.
Non confondere lo stato attivo con l'attività "ripresa più in alto". Il sistema assegna delle priorità alle attività in base all'ordine z per dare una priorità maggiore alle ultime attività con cui l'utente ha interagito. Un'attività può essere ripresa dall'alto, ma non è stata evidenziata (ad esempio se l'area notifiche è espansa).
In Android 10 (livello API 29) e versioni successive, puoi iscriverti al callback onTopResumedActivityChanged() per ricevere una notifica quando la tua attività acquisisce o perde la posizione ripresa più in alto. Questo è l'equivalente dello stato ripristinato prima di Android 10 e può essere utile
come suggerimento se la tua app usa risorse esclusive o singleton che potrebbero dover essere
condivise con altre app.
Anche il comportamento dell'attributo manifest resizeableActivity è cambiato. Se un'app imposta resizeableActivity=false in Android 10 (livello API 29) o versioni successive, potrebbe essere attivata la modalità di compatibilità quando le dimensioni dello schermo disponibili cambiano o se l'app passa da una schermata all'altra.
Le app possono utilizzare l'attributo android:minAspectRatio, introdotto in Android 10, per indicare le proporzioni di schermo supportate dall'app.
A partire dalla versione 3.5, l'emulatore di Android Studio include dispositivi virtuali da 7,3" e 8", che consentono di testare il codice su schermi più grandi.
Per ulteriori informazioni, vedi Progettare le app per i pieghevoli.