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

Android 10 include modifiche aggiornate al 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 in esecuzione su Android 10.

Nota : oltre alle modifiche elencate in questa pagina, Android 10 introduce un numero elevato di modifiche e limitazioni basate sulla privacy, tra cui:

  • Archiviazione con ambito
  • 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 che hanno come target il livello API 29 o superiore, 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 garantire stabilità e 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 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 scegli come target Android 10 (livello API 29), alcune di queste modifiche potrebbero non riguardarti 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 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, dovresti iniziare a pianificare una migrazione a alternative SDK. Tuttavia, sappiamo 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 relative alle interfacce non SDK in Android 10 e consulta Limitazioni relative alle interfacce non SDK.

Ricordo condiviso

Ashmem ha modificato il formato delle mappe dalvik in /proc/<pid>/maps, interessando 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 l'app 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 dell'NDK. Inoltre, le app non possono creare IOCTL diretti per i descrittori dei file ashmem esistenti e devono invece utilizzare la classe ASharedMemory di 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.

Autorizzazione di esecuzione rimossa per la home directory dell'app

L'esecuzione di file dalla home directory dell'app scrivibile è una violazione di 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 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 dai file aperti con dlopen() e prevedono che queste modifiche vengano scritte su disco, perché la libreria non può essere mappata PROT_EXEC tramite un descrittore di file scrivibile. Sono inclusi tutti i file di oggetti condivisi (.so) con riposizionazioni di testo.

Il runtime Android accetta solo file OAT generati dal sistema

Il runtime Android (ART) non richiama più dex2oat dal processo dell'applicazione. Questa modifica significa che ART accetterà solo file OAT generati dal sistema.

Applicare la correttezza AOT in ART

In passato, la compilazione in anticipo (AOT) eseguita da Android Runtime (ART) poteva causare arresti anomali di runtime se l'ambiente classpath era diverso al momento della compilazione e nel runtime. Android 10 e versioni successive richiede sempre lo stesso contesto di ambiente, con il risultato di 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 classi in fase di runtime.
  • I file dex secondari, ovvero i file dex caricati manualmente da app non presenti nell'APK principale, vengono compilati in background. Questo perché la compilazione al primo utilizzo potrebbe essere troppo costosa, generando una latenza indesiderata prima dell'esecuzione. Tieni presente che per le app è consigliabile adottare le suddivisioni 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 alle autorizzazioni per gli intent a schermo intero

Le app destinate ad Android 10 o versioni successive e 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, pertanto 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 pieghevoli

Android 10 presenta 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 ripristinato, ma solo una di queste, l'attività "ripresa più in alto", è in realtà attiva. Con versioni precedenti ad Android 10, è possibile riprendere una sola attività alla volta nel sistema, mentre tutte le altre attività visibili vengono messe in pausa.

Non confondere la "concentrazione" con l'attività "ripresa più in alto". Il sistema assegna le priorità alle attività in base all'ordine Z per dare una priorità maggiore alle attività con cui l'utente ha interagito per ultime. Un'attività può essere ripresa dall'inizio, ma non avere lo stato attivo (ad esempio, se l'area notifiche è espansa).

In Android 10 (livello API 29) e versioni successive, puoi abbonarti al callback di onTopResumedActivityChanged() per ricevere una notifica quando la tua attività acquisisce o perde la posizione ripresa più alta. Equivale allo stato ripristinato precedente 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 attivata in modalità di compatibilità quando cambiano le dimensioni dello schermo disponibili o se l'app si sposta da una schermata all'altra.

Le app possono usare l'attributo android:minAspectRatio, introdotto in Android 10, per indicare le razioni di schermo supportate dalla tua app.

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

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