Cambiamenti del comportamento: app che hanno come target l'API 29 o versioni successive

Android 10 include modifiche al comportamento del sistema aggiornate che potrebbero influire sulla tua app. Le modifiche elencate in questa pagina si applicano esclusivamente alle app che hanno come target il livello API 29 o livelli successivi. Se la tua app imposta targetSdkVersion su "29" o su un livello 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 in esecuzione su Android 10.

Aggiornamenti alle 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 con limitazioni in base alla collaborazione con gli sviluppatori Android e ai test interni più recenti. Il nostro obiettivo è assicurarci che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.

Se non hai intenzione di scegliere 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 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 una migrazione ad alternative SDK. Tuttavia, ci rendiamo conto 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.

Memoria condivisa

Ashmem ha modificato il formato delle mappe Dalvik in /proc/<pid>/maps. La modifica interessa le 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 che hanno come target Android 10 non possono utilizzare direttamente ashmem (/dev/ashmem), ma devono invece accedere alla memoria condivisa tramite la classe ASharedMemory dell'NDK. Inoltre, le app non possono effettuare chiamate IOCTL dirette ai descrittori dei 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 stabilità quando si lavora con la memoria condivisa, migliorando le prestazioni e la sicurezza di Android in generale.

Autorizzazione di esecuzione rimossa per la home directory dell'app

L'esecuzione di file dalla home directory dell'app scrivibile è una violazione W^X. Le app devono caricare solo il codice binario incorporato nel file APK.

Le app non attendibili che hanno come target Android 10 non possono richiamare direttamente execve() nei 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(). Queste modifiche non verranno scritte su disco perché la libreria non può essere mappata con l'autorizzazione PROT_EXEC tramite un descrittore del file scrivibile. Sono inclusi tutti i file di oggetti condivisi (.so) con rilocazioni di testo.

Android Runtime accetta solo file OAT generati dal sistema

Android Runtime (ART) non richiama più dex2oat dal processo dell'applicazione. In seguito a questa modifica, ART accetterà solo i file OAT generati dal sistema.

Correttezza della compilazione AOT in ART

In passato, la compilazione ahead-of-time (AOT) eseguita da Android Runtime (ART) poteva causare arresti anomali in fase di esecuzione se l'ambiente classpath non era lo stesso in fase di compilazione ed esecuzione. In Android 10 e versioni successive gli ambienti devono essere sempre uguali, il che comporta i seguenti cambiamenti nel comportamento:

• I class loader personalizzati, ovvero i class loader scritti dalle app, a differenza dei class loader del pacchetto dalvik.system, non vengono compilati AOT. Questo perché ART non è in grado di prevedere il modo in viene effettuata la ricerca delle classi al momento dell'esecuzione.
• I file dex secondari, ovvero i file dex caricati manualmente dalle app e non presenti nell'APK principale, vengono compilati AOT in background. Questo perché la compilazione al primo utilizzo potrebbe richiedere troppo tempo e troppe risorse, causando una latenza indesiderata prima dell'esecuzione. Tieni presente che per le app è consigliabile adottare le suddivisioni e non utilizzare i file dex secondari.
• Le librerie condivise in Android (<library> e <uses-library> in un manifest Android) vengono implementate utilizzando una gerarchia di class loader diversa da 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'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 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 restituisce il seguente messaggio di log:

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

Supporto per i pieghevoli

Android 10 include modifiche che supportano pieghevoli e dispositivi 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 su più display, tutte le attività principali selezionabili negli stack visibili possono essere riprese, ma solo una di queste, l'attività ripresa in primo piano, è selezionata. Nelle versioni precedenti ad Android 10, può essere ripresa una sola attività alla volta nel sistema, mentre tutte le altre attività visibili vengono sospese.

Non confondere attività "selezionata" con attività "ripresa in primo piano". Il sistema assegna la priorità alle attività in base all'ordine Z per dare la priorità alle attività con cui l'utente ha interagito per ultime. Un'attività può essere ripresa in primo piano, ma non essere selezionata (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 in primo piano". Questo stato è l'equivalente dello stato "ripresa" nelle versioni precedenti ad 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 inserita in modalità di compatibilità quando le dimensioni dello schermo disponibili cambiano o se l'app si sposta da uno schermo all'altro.

Le app possono utilizzare l'attributo android:minAspectRatio introdotto in Android 10, per indicare le proporzioni dello schermo supportate dall'app.

A partire dalla versione 3.5, lo strumento emulatore di Android Studio include dispositivi virtuali da 7,3" e 8" per testare il codice con schermi più grandi.

Per ulteriori informazioni, vedi Progetta le app per i pieghevoli.