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 scelte come target
API 29 o superiore. Se la tua app imposta targetSdkVersion su "29" o
devi modificare l'app 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 numero elevato di modifiche e restrizioni basate sulla privacy, tra cui: le seguenti:
- 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 versioni successive, migliorare la privacy degli utenti. Per scoprire di più su come supportare queste modifiche, vedi la pagina Modifiche alla privacy.
Aggiornamenti alle limitazioni relative alle interfacce non SDK
Per contribuire a garantire stabilità e compatibilità delle app, la piattaforma ha iniziato a applicare limitazioni quali 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 test interni più recenti. Il nostro obiettivo è far sì che sono disponibili alternative 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, sebbene al momento tu possa utilizzare interfacce non SDK (a seconda del livello API target dell'app), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di danneggiare dell'app.
Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare la tua app per scoprirlo. Se la tua app si basa su interfacce non SDK, dovresti iniziare a pianificare una migrazione alle alternative dell'SDK. Tuttavia, sappiamo che alcune app hanno e validi casi d'uso 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 all'interfaccia non SDK in Android 10 e consulta le Limitazioni relative alle interfacce non SDK.
Ricordo condiviso
Ashmem ha cambiato il formato delle mappe dalvik in /proc/<pid>/maps, interessa le app che analizzano direttamente il file delle mappe. Gli sviluppatori di applicazioni dovrebbero testare il formato /proc/<pid>/maps sui dispositivi che eseguono Android 10 o versioni successive e analizzali di conseguenza se l'app dipende da formati di 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 creare IOCTL diretti per i descrittori dei file ashmem esistenti.
e deve utilizzare la classe ASharedMemory dell'NDK o il codice Java per Android
API per la creazione di regioni di memoria condivisa. Questa modifica aumenta la sicurezza
robustezza quando si lavora con memoria condivisa, miglioramento di prestazioni e sicurezza
di Android nel complesso.
Autorizzazione di esecuzione rimossa 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 richiamare execve()
direttamente sui file nella home directory dell'app.
Inoltre, le app destinate ad Android 10 non possono apportare modifiche in memoria
codice eseguibile da file che sono stati aperti con dlopen() e si aspettano
le modifiche in modo che vengano scritte su disco, perché la libreria non può avere
PROT_EXEC è stato mappato tramite un descrittore di file scrivibile. Ciò include qualsiasi
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 dall'applicazione
e il processo di sviluppo. Ciò significa che l'ART accetterà solo i file OAT generati dal sistema.
Applicare la correttezza AOT in ART
In passato, la compilation di contenuti previsionali (AOT) eseguita da Android Il runtime (ART) potrebbe causare arresti anomali di runtime se l'ambiente classpath non era al momento della compilazione e del runtime. Android 10 e versioni successive richiedono sempre che questi contesti di ambiente siano gli stessi, i seguenti cambiamenti di comportamento:
- Caricatori di classi personalizzati, ovvero caricatori di classi scritti da app, a differenza delle classi
caricatori del pacchetto
dalvik.system, non sono compilati AOT. Questo accade perché ART non può conoscere l'implementazione della ricerca di classi personalizzate in fase di esecuzione. - File dex secondari, ovvero i file dex caricati manualmente da app non presenti nel APK principale: vengono compilati AOT in background. Questo perché il primo utilizzo la compilazione potrebbe essere troppo costosa, generando una latenza indesiderata prima dell'esecuzione. Tieni presente che, per le app, adottare le suddivisioni e allontanarsi dalle app i file dex.
- Librerie condivise in Android (le voci <library> e <uses-library> in un file manifest Android) vengono implementate utilizzando un'interfaccia una gerarchia del caricatore di classi rispetto a quella utilizzata nelle versioni precedenti della piattaforma.
Modifiche alle autorizzazioni per gli intent a schermo intero
App destinate ad Android 10 o versioni successive che utilizzano notifiche con
a schermo intero
intent devono richiedere
il
USE_FULL_SCREEN_INTENT
nel file manifest dell'app. È un comportamento normale
autorizzazione, in modo che il sistema
la concede automaticamente all'app richiedente.
Se un'app che ha come target Android 10 o versioni successive tenta di creare un una notifica con un intent a schermo intero senza richiedere i necessari l'autorizzazione, il sistema ignora l'intent a schermo intero e restituisce il seguente codice messaggio di log:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Supporto per pieghevoli
Android 10 include modifiche che supportano i dispositivi pieghevoli e con schermi di grandi dimensioni.
Quando un'app viene eseguita su Android 10,
onResume() e
I metodi onPause() funzionano
in modo diverso. Quando più app vengono visualizzate contemporaneamente in modalità multi-finestra o
modalità multi-display, tutte le attività principali attivabili in gruppi visibili
sono nello stato Ripreso, ma solo uno di questi, il "ripristino più in alto" attività,
si concentra. Quando vengono eseguite su versioni precedenti ad Android 10, è disponibile solo una
singola attività nel sistema può essere ripresa alla volta, tutte le altre
sono in pausa.
Non confondere la "concentrazione" con il comando "riprendi in alto" attività. Il sistema assegna priorità alle attività in base all'ordine z per dare una priorità maggiore le ultime attività con cui l'utente ha interagito. Un'attività può essere in alto, ma senza lo stato attivo (ad esempio, se l'area notifiche è espanso).
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 attivata in modalità di compatibilità
quando cambiano le dimensioni dello schermo disponibili o se l'app passa da una schermata a
un'altra.
Le app possono utilizzare
android:minAspectRatio
introdotto in Android 10, per indicare lo schermo
proporzioni supportate dalla tua app.
A partire dalla versione 3.5, l'emulatore di Android Studio include 7,3" e 8" dispositivi virtuali per testare il codice su schermi più grandi.
Per ulteriori informazioni, consulta Creare app per dispositivi pieghevoli.