La piattaforma Android 16 include modifiche al comportamento che potrebbero influire sulla tua app.
Le seguenti modifiche al comportamento si applicano a tutte le app quando vengono eseguite su Android 16,
indipendentemente da targetSdkVersion
. Dovresti testare l'app e poi modificarla come necessario per supportare queste modifiche, se applicabili.
Assicurati di esaminare anche l'elenco delle modifiche al comportamento che interessano solo le app con target Android 16.
Funzionalità di base
Android 16 include le seguenti modifiche che modificano o ampliano varie funzionalità di base del sistema Android.
Ottimizzazioni delle quote di JobScheduler
A partire da Android 16, stiamo modificando la quota di tempo di esecuzione per l'esecuzione di job regolari e accelerati in base ai seguenti fattori:
- Il bucket di app in standby in cui si trova l'applicazione: in Android 16, i bucket di app in standby attivi inizieranno a essere applicati da una quota di runtime generosa.
- Se il job inizia l'esecuzione mentre l'app è in uno stato superiore: in Android 16, i job avviati mentre l'app è visibile all'utente e continuano dopo che l'app diventa invisibile, rispetteranno la quota di tempo di esecuzione del job.
- Se il job è in esecuzione durante l'esecuzione di un servizio in primo piano: in Android 16, i job in esecuzione contemporaneamente a un servizio in primo piano rispetteranno la quota di tempo di esecuzione del job. Se utilizzi i job per il trasferimento di dati avviato dall'utente, ti consigliamo di utilizzare i job di trasferimento di dati avviati dall'utente.
Questa modifica interessa le attività pianificate utilizzando WorkManager, JobScheduler e DownloadManager. Per eseguire il debug del motivo dell'interruzione di un job, ti consigliamo di registrare il motivo dell'interruzione chiamando WorkInfo.getStopReason()
(per i job JobScheduler, chiama JobParameters.getStopReason()
).
Per ulteriori informazioni sulle best practice per l'ottimizzazione dell'utilizzo della batteria per le API di pianificazione delle attività, consulta le indicazioni su come ottimizzare l'utilizzo della batteria per le API di pianificazione delle attività.
Ti consigliamo inoltre di utilizzare la nuova API JobScheduler#getPendingJobReasonsHistory
introdotta in Android 16 per capire perché un job non è stato eseguito.
Test
Per testare il comportamento dell'app, puoi attivare l'override di determinate ottimizzazioni della quota di job, a condizione che l'app sia in esecuzione su un dispositivo Android 16.
Per disattivare l'applicazione dell'impostazione "lo stato superiore rispetterà la quota di runtime del job", esegui il seguente comando adb
:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME
Per disattivare l'applicazione forzata del criterio "i job in esecuzione contemporaneamente a un servizio in primo piano rispetteranno la quota di tempo di esecuzione del job", esegui il seguente comando adb
:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME
Per testare determinati comportamenti del bucket in standby dell'app, puoi impostare il bucket in standby dell'app utilizzando il seguente comando adb
:
adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted
Per capire il bucket in cui si trova la tua app, puoi ottenere il bucket in standby della tua app utilizzando il seguente comando adb
:
adb shell am get-standby-bucket APP_PACKAGE_NAME
Motivo dell'interruzione dei job vuoti abbandonati
Un job abbandonato si verifica quando l'oggetto JobParameters
associato al job è stato sottoposto a garbage collection, ma JobService#jobFinished(JobParameters,
boolean)
non è stato chiamato per segnalare il completamento del job. Ciò indica che il job potrebbe essere in esecuzione e essere riprogrammato senza che l'app lo sappia.
Le app che si basano su JobScheduler non mantengono un riferimento forte all'oggettoJobParameters
e ora al timeout verrà concesso il nuovo motivo di interruzione del jobSTOP_REASON_TIMEOUT_ABANDONED
, anziché STOP_REASON_TIMEOUT
.
Se si verificano spesso casi del nuovo motivo di interruzione dell'abbandono, il sistema prenderà provvedimenti per ridurre la frequenza dei job.
Le app devono utilizzare il nuovo motivo di interruzione per rilevare e ridurre i job abbandonati.
Se utilizzi WorkManager, AsyncTask o DownloadManager, non sono interessati perché queste API gestiscono il ciclo di vita dei job per conto della tua app.
Ritiro completo di JobInfo#setImportantWhileForeground
Il metodo JobInfo.Builder#setImportantWhileForeground(boolean)
indica l'importanza di un job quando l'app di pianificazione è in primo piano o quando è temporaneamente esente dalle limitazioni in background.
Questo metodo è stato ritirato da Android 12 (livello API 31). A partire da Android 16, non funziona più in modo efficace e la chiamata di questo metodo verrà ignorata.
Questa rimozione di funzionalità si applica anche a
JobInfo#isImportantWhileForeground()
. A partire da Android
16, se il metodo viene chiamato, restituisce false
.
L'ambito della priorità di trasmissione ordinata non è più globale
Le app per Android possono definire le priorità per i ricevitori di trasmissione per controllare
l'ordine in cui i ricevitori ricevono ed elaborano la trasmissione. Per i gestori dichiarati nel file manifest, le app possono utilizzare l'attributo android:priority
per definire la priorità e per i gestori registrati nel contesto, le app possono utilizzare l'API IntentFilter#setPriority()
per definire la priorità. Quando viene inviata una trasmissione, il sistema la consegna ai ricevitori in ordine di priorità, dalla più alta alla più bassa.
In Android 16, l'ordine di invio delle trasmissioni che utilizzano l'attributo android:priority
o IntentFilter#setPriority()
in diversi processi non sarà garantito. Le priorità di trasmissione verranno rispettate solo all'interno della stessa procedura di applicazione e non in tutte le procedure.
Inoltre, le priorità di trasmissione verranno automaticamente limitate all'intervallo
(SYSTEM_LOW_PRIORITY
+ 1,
SYSTEM_HIGH_PRIORITY
- 1). Solo i componenti di sistema potranno impostare SYSTEM_LOW_PRIORITY
, SYSTEM_HIGH_PRIORITY
come priorità di trasmissione.
La tua app potrebbe essere interessata se esegue una delle seguenti azioni:
- La tua applicazione ha dichiarato più processi con lo stesso intento di trasmissione e si aspetta di ricevere questi intent in un determinato ordine in base alla priorità.
- La procedura di applicazione interagisce con altri processi e ha aspettative sulla ricezione di un'intenzione di trasmissione in un determinato ordine.
Se le procedure devono coordinarsi tra loro, devono comunicare utilizzando altri canali di coordinamento.
Modifiche interne all'ART
Android 16 include gli aggiornamenti più recenti all'ambiente di runtime Android (ART) che migliorano le prestazioni dell'ambiente di runtime Android (ART) e forniscono il supporto di funzionalità Java aggiuntive. Tramite gli aggiornamenti di sistema di Google Play, questi miglioramenti sono disponibili anche per oltre un miliardo di dispositivi con Android 12 (livello API 31) e versioni successive.
Man mano che queste modifiche vengono rilasciate, le librerie e il codice delle app che si basano sulle strutture interne di ART potrebbero non funzionare correttamente sui dispositivi con Android 16 e sulle versioni precedenti di Android che aggiornano il modulo ART tramite gli aggiornamenti di sistema di Google Play.
Fare affidamento su strutture interne (ad esempio interfacce non SDK) può sempre portare a problemi di compatibilità, ma è particolarmente importante evitare di fare affidamento su codice (o librerie contenenti codice) che sfrutta strutture ART interne, poiché le modifiche ART non sono legate alla versione della piattaforma su cui è in esecuzione il dispositivo e vengono rilasciate su oltre un miliardo di dispositivi tramite gli aggiornamenti di sistema di Google Play.
Tutti gli sviluppatori devono verificare se la loro app è interessata testando le proprie app in modo approfondito su Android 16. Inoltre, controlla i problemi noti per verificare se la tua app dipende da librerie che abbiamo identificato come basate su strutture ART interne. Se hai dipendenze di codice dell'app o della libreria che sono interessate, cerca alternative API pubbliche, se possibile, e richiedi API pubbliche per nuovi casi d'uso creando una richiesta di funzionalità nel nostro issue tracker.
Modalità di compatibilità con le dimensioni pagina di 16 kB
Android 15 ha introdotto il supporto per le pagine di memoria da 16 KB per ottimizzare le prestazioni della piattaforma. Android 16 aggiunge una modalità di compatibilità, che consente ad alcune app create per pagine di memoria da 4 KB di essere eseguite su un dispositivo configurato per pagine di memoria da 16 KB.
Se Android rileva che la tua app ha pagine di memoria allineate a 4 KB, utilizza automaticamente la modalità di compatibilità e mostra una finestra di dialogo di notifica all'utente. L'impostazione della proprietà android:pageSizeCompat
in AndroidManifest.xml
per attivare la modalità di compatibilità con le versioni precedenti impedisce la visualizzazione della
finestra di dialogo al momento dell'avvio dell'app. Per ottenere le migliori prestazioni, affidabilità e stabilità,
la tua app deve comunque essere allineata a 16 KB. Per ulteriori dettagli, consulta il nostro recente post del blog sull'aggiornamento delle app per supportare le pagine di memoria di 16 KB.

Esperienza utente e interfaccia utente di sistema
Android 16 include le seguenti modifiche volte a creare un'esperienza utente più coerente e intuitiva.
Ritiro degli annunci di accessibilità che causano interruzioni
Android 16 ritira gli annunci di accessibilità, caratterizzati dall'utilizzo di
announceForAccessibility
o dall'invio di
TYPE_ANNOUNCEMENT
eventi di accessibilità. Ciò può creare esperienze utente incoerenti per gli utenti di TalkBack e dello screen reader di Android e le alternative soddisfano meglio una gamma più ampia di esigenze degli utenti in una serie di tecnologie per la disabilità di Android.
Esempi di alternative:
- Per modifiche significative all'interfaccia utente, come le modifiche alle finestre, utilizza
Activity.setTitle(CharSequence)
esetAccessibilityPaneTitle(java.lang.CharSequence)
. In Scrivi, usaModifier.semantics { paneTitle = "paneTitle" }
- Per informare l'utente delle modifiche all'interfaccia utente di importanza critica, utilizza
setAccessibilityLiveRegion(int)
. In Scrivi, usaModifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]}
. Questi annunci devono essere utilizzati con parsimonia, in quanto potrebbero generare annunci ogni volta che una visualizzazione viene aggiornata. - Per notificare gli utenti degli errori, invia un
AccessibilityEvent
di tipoAccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR
e impostaAccessibilityNodeInfo#setError(CharSequence)
oppure utilizzaTextView#setError(CharSequence)
.
La documentazione di riferimento per l'API announceForAccessibility
obsoleta include ulteriori dettagli sulle alternative suggerite.
Supporto della navigazione con tre pulsanti
Android 16 introduce il supporto del pulsante Indietro predittivo alla navigazione con tre pulsanti per le app che hanno effettuato correttamente la migrazione al pulsante Indietro predittivo. Se premi a lungo il pulsante Indietro, viene avviata un'animazione di Indietro predittiva che ti mostra un'anteprima della destinazione del gesto Indietro.
Questo comportamento si applica a tutte le aree del sistema che supportano le animazioni Indietro predittive, incluse le animazioni di sistema (torna alla schermata Home, passaggio da un'attività all'altra e così via).
Fattori di forma del dispositivo
Android 16 include le seguenti modifiche per le app quando vengono proiettate sui display dai proprietari di dispositivi virtuali.
Sostituzioni del proprietario del dispositivo virtuale
Un proprietario di dispositivo virtuale è un'app attendibile o con privilegi che crea e gestisce un dispositivo virtuale. I proprietari di dispositivi virtuali eseguono app su un dispositivo virtuale e poi le proiettano sul display di un dispositivo remoto, ad esempio un personal computer, un dispositivo di realtà virtuale o un sistema di infotainment per auto. Il proprietario del dispositivo virtuale si trova su un dispositivo locale, ad esempio un cellulare.

Sostituzioni per app
Sui dispositivi con Android 16, i proprietari di dispositivi virtuali possono eseguire l'override delle impostazioni delle app su alcuni dispositivi virtuali gestiti. Ad esempio, per migliorare il layout delle app, un proprietario di un dispositivo virtuale può ignorare le limitazioni relative a orientamento, formato e ridimensionamento durante la proiezione delle app su un display esterno.
Modifiche che provocano un errore comuni
Il comportamento di Android 16 potrebbe influire sull'interfaccia utente della tua app su fattori di forma con schermi di grandi dimensioni, come display dell'auto o Chromebook, in particolare sui layout progettati per schermi di piccole dimensioni in orientamento verticale. Per scoprire come rendere la tua app adattabile a tutti i fattori di forma del dispositivo, consulta Informazioni sui layout adattabili.
Riferimenti
Streaming di app complementari
Sicurezza
Android 16 include modifiche che promuovono la sicurezza del sistema per contribuire a proteggere app e utenti da app dannose.
Maggiore sicurezza contro gli attacchi di reindirizzamento degli intent
Android 16 fornisce sicurezza predefinita contro gli attacchi di reindirizzamento Intent
generici, con requisiti minimi di compatibilità e modifiche richieste agli sviluppatori.
Stiamo introducendo soluzioni di rafforzamento della sicurezza predefinite per gli exploit di Intent
ridirezione. Nella maggior parte dei casi, le app che utilizzano gli intent normalmente non riscontrano problemi di compatibilità. Abbiamo raccolto le metriche durante il nostro processo di sviluppo per monitorare le app che potrebbero riscontrare interruzioni.
Il reindirizzamento di intent in Android si verifica quando un malintenzionato può controllare parzialmente o completamente i contenuti di un intent utilizzato per avviare un nuovo componente nel contesto di un'app vulnerabile, mentre l'app vittima avvia un intent di livello secondario non attendibile in un campo extra di un intent ("di primo livello"). Ciò può portare all'app malintenzionata a lanciare componenti privati nel contesto dell'app vittima, a attivare azioni privilegiate o a ottenere l'accesso tramite URI a dati sensibili, potenzialmente conducendo a furto di dati ed esecuzione di codice arbitrario.
Disattivare la gestione del reindirizzamento intent
Android 16 introduce una nuova API che consente alle app di disattivare le protezioni di sicurezza al momento del lancio. Ciò potrebbe essere necessario in casi specifici in cui il comportamento di sicurezza predefinito interferisce con casi d'uso legittimi delle app.
Per le applicazioni compilate con l'SDK Android 16 o versioni successive
Puoi utilizzare direttamente il metodo removeLaunchSecurityProtection()
sull'oggetto Intent.
val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
Per le applicazioni compilate per Android 15 (livello API 35) o versioni precedenti
Sebbene non sia consigliato, puoi utilizzare la riflessione per accedere al metodo
removeLaunchSecurityProtection()
.
val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
// Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }