Android 10 include modifiche al comportamento di sistema aggiornate che potrebbero influire sulla 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 su un valore superiore, devi modificarla per supportare correttamente questi comportamenti, ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche al comportamento che interessano tutte le app su Android 10.
Nota: oltre alle modifiche elencate in questa pagina, Android 10 introduce un gran numero di modifiche e limitazioni incentrate sulla privacy, tra cui:
- Spazio di archiviazione basato sugli ambiti
- Accedere 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 che hanno come target il livello API 29 o versioni successive, migliorano la privacy degli utenti. Per scoprire di più su come supportare queste modifiche, consulta la pagina Modifiche alla privacy.
Aggiornamenti alle 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.
Memoria condivisa
Ashmem ha modificato il formato delle mappe dalvik in /proc/<pid>/maps, influendo sulle app che analizzano direttamente il file delle mappe. Gli sviluppatori di applicazioni devono testare il formato /proc/<pid>/maps sui dispositivi con Android 10 o versioni successive e analizzarlo di conseguenza se l'app dipende dai formati delle mappe dalvik.
Le app destinate ad Android 10 non possono utilizzare direttamente ashmem
(/dev/ashmem) e devono invece accedere alla memoria condivisa tramite la
classe ASharedMemory dell'NDK.
Inoltre, le app non possono eseguire IOCTL diretti ai descrittori file ashmem esistenti
e devono invece utilizzare la classe ASharedMemory dell'NDK o le API Java di Android
per creare regioni di memoria condivisa. Questa modifica aumenta la sicurezza e la 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 di file dalla home directory dell'app scrivibile costituisce una violazione W^X. Le app devono caricare solo il codice binario incorporato nel file APK di un'app.
Le app non attendibili che hanno come target Android 10 non possono invocare execve()
direttamente sui file all'interno della home directory dell'app.
Inoltre, le app che hanno come target Android 10 non possono modificare in memoria il codice eseguibile dei file aperti con dlopen() e non possono aspettarsi che queste modifiche vengano scritte su disco, perché la libreria non può essere mappata PROT_EXEC tramite un descrittore file scrivibile. Sono inclusi tutti
i file di oggetti condivisi (.so) con spostamenti di testo.
Il runtime Android accetta solo file OAT generati dal sistema
Il runtime Android (ART) non richiama più dex2oat dal processo
dell'applicazione. Ciò significa che l'ART accetterà solo i file OAT generati dal sistema.
Applicazione della correttezza AOT in ART
In passato, la compilazione anticipata (AOT) eseguita da Android Runtime (ART) poteva causare arresti anomali di runtime se l'ambiente classpath non era lo stesso in fase di compilazione e di runtime. Android 10 e versioni successive richiedono sempre che questi contesti dell'ambiente siano gli stessi, con le seguenti modifiche al comportamento:
- I caricatori di classi personalizzati, ovvero quelli scritti dalle app, a differenza dei caricatori di classi del pacchetto
dalvik.system, non sono compilati con AOT. Questo accade perché ART non può conoscere l'implementazione della ricerca di classi personalizzate in fase di esecuzione. - I file dex secondari, ovvero i file dex caricati manualmente dalle app non presenti nell'APK principale, vengono compilati in 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 suddivisioni e abbandonare i file di indicizzazione secondari.
- Le librerie condivise in Android (le voci <library> e <uses-library> in un file manifest di Android) sono implementate utilizzando una distinta gerarchia del caricatore delle classi rispetto a quella utilizzata nelle versioni precedenti della piattaforma.
Modifiche alle autorizzazioni per gli intent a schermo intero
Le app che hanno come target Android 10 o versioni successive e utilizzano notifiche con
intent
a schermo intero devono richiedere
l'USE_FULL_SCREEN_INTENT
autorizzazione nel file manifest della propria app. Si tratta di una normale permissione, pertanto il sistema la concede automaticamente all'app che la richiede.
Se un'app che ha come target 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 genera il seguente messaggio di log:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Supporto per i dispositivi pieghevoli
Android 10 include 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à multifinestra o su più display, tutte le attività principali che possono avere il focus negli stack visibili sono nello stato di ripresa, ma solo una di queste, l'attività "riprendi più in alto", ha effettivamente il focus. Quando viene eseguito su versioni precedenti ad Android 10, è possibile riprendere contemporaneamente solo una singola attività nel sistema, mentre tutte le altre attività visibili vengono messe in pausa.
Non confondere "in primo piano" con l'attività "riprendi più in alto". Il sistema assegna le priorità alle attività in base all'ordine z per dare la priorità alle attività con cui l'utente ha interagito per ultimo. Un'attività può essere ripresa dall'alto, ma non avere lo stato attivo (ad esempio, se la tendina delle 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 di ripresa più alta. Si tratta dell'equivalente dello stato di ripresa prima di Android 10 e può essere utile come suggerimento se la tua app utilizza 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 messa in 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 i rapporti screenshot supportati dalla tua app.
A partire dalla versione 3.5, lo strumento di emulazione di Android Studio include dispositivi virtuali da 7,3" e 8" per testare il codice con schermi più grandi.
Per ulteriori informazioni, consulta Creare app per dispositivi pieghevoli.