Modifiche al comportamento: tutte le app

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. Devi testare la tua app e poi modificarla in base alle necessità per supportare queste modifiche, ove applicabile.

Assicurati di esaminare anche l'elenco delle modifiche al comportamento che interessano solo le app che hanno come target Android 16.

Funzionalità di base

Android 16 (livello API 36) include le seguenti modifiche che modificano o espandono varie funzionalità di base del sistema Android.

Ottimizzazioni della quota di JobScheduler

A partire da Android 16, stiamo modificando la quota di runtime per l'esecuzione di job regolari e rapidi in base ai seguenti fattori:

• In quale bucket standby app si trova l'applicazione: in Android 16, i bucket standby attivi inizieranno a essere applicati da una generosa quota di runtime.
• Se l'esecuzione del job inizia mentre l'app è in primo piano: in Android 16, i job avviati mentre l'app è visibile all'utente e continuano dopo che l'app diventa invisibile, rispettano la quota di runtime del job.
• Se il job viene eseguito durante l'esecuzione di un servizio in primo piano: in Android 16, i job eseguiti contemporaneamente a un servizio in primo piano rispettano la quota di runtime del job. Se utilizzi i job per il trasferimento di dati avviato dall'utente, valuta la possibilità di utilizzare i job di trasferimento di dati avviato dall'utente.

Questa modifica influisce sulle attività pianificate utilizzando WorkManager, JobScheduler e DownloadManager. Per eseguire il debug del motivo per cui un job è stato interrotto, ti consigliamo di registrare il motivo per cui il job è stato interrotto chiamando WorkInfo.getStopReason() (per i job JobScheduler, chiama JobParameters.getStopReason()).

Per informazioni su come lo stato dell'app influisce sulle risorse che può utilizzare, consulta Limiti delle risorse di gestione dell'alimentazione. Per ulteriori informazioni sulle best practice per l'ottimizzazione della batteria, 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 della tua app, puoi attivare l'override di alcune ottimizzazioni della quota di job purché l'app sia in esecuzione su un dispositivo Android 16.

Per disattivare l'applicazione di "top state will adhere to job runtime quota", esegui il seguente comando adb:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

Per disattivare l'applicazione di "i job in esecuzione contemporaneamente a un servizio in primo piano rispetteranno la quota di runtime del job", esegui questo comando adb:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

Per testare il comportamento di determinati bucket di standby delle app, puoi impostare il bucket di standby delle app della tua app utilizzando il seguente comando adb:

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

Per capire in quale bucket di standby dell'app si trova la tua app, puoi recuperare il bucket di standby dell'app utilizzando il seguente comando adb:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Motivo di 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.

Deprecazione completa 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 di priorità della trasmissione ordinata non è più globale

Android apps are allowed to define priorities on broadcast receivers to control the order in which the receivers receive and process the broadcast. For manifest-declared receivers, apps can use the android:priority attribute to define the priority and for context-registered receivers, apps can use the IntentFilter#setPriority() API to define the priority. When a broadcast is sent, the system delivers it to receivers in order of their priority, from highest to lowest.

In Android 16, broadcast delivery order using the android:priority attribute or IntentFilter#setPriority() across different processes will not be guaranteed. Broadcast priorities will only be respected within the same application process rather than across all processes.

Also, broadcast priorities will be automatically confined to the range (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Only system components will be allowed to set SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY as broadcast priority.

Your app might be impacted if it does either of the following:

1. Your application has declared multiple processes with the same broadcast intent, and has expectations around receiving those intents in a certain order based on the priority.
2. Your application process interacts with other processes and has expectations around receiving a broadcast intent in a certain order.

If the processes need to coordinate with each other, they should communicate using other coordination channels.

Modifiche interne di ART

Android 16 包含 Android 运行时 (ART) 的最新更新，这些更新可提升 Android 运行时 (ART) 的性能，并支持更多 Java 功能。通过 Google Play 系统更新，搭载 Android 12（API 级别 31）及更高版本的 10 亿多部设备也将受益于这些改进。

发布这些变更后，依赖于 ART 内部结构的库和应用代码在搭载 Android 16 的设备以及通过 Google Play 系统更新来更新 ART 模块的较低 Android 版本上可能无法正常运行。

依赖于内部结构（例如非 SDK 接口）始终会导致兼容性问题，但避免依赖于利用内部 ART 结构的代码（或包含代码的库）尤为重要，因为 ART 更改与设备所运行的平台版本无关，并且会通过 Google Play 系统更新推送到超过 10 亿部设备。

所有开发者都应在 Android 16 上对其应用进行全面测试，以检查其应用是否受到影响。此外，请查看已知问题，了解您的应用是否依赖于我们发现的任何依赖于内部 ART 结构的库。如果您的应用代码或库依赖项受到影响，请尽可能寻找公共 API 替代方案，并在问题跟踪器中创建功能请求，为新用例请求公共 API。

Modalità di compatibilità con le dimensioni pagina di 16 kB

Android 15 引入了对 16 KB 内存页面的支持，以优化平台性能。Android 16 添加了兼容模式，让一些针对 4 KB 内存页面构建的应用可以在配置为 16 KB 内存页面的设备上运行。

当您的应用在搭载 Android 16 或更高版本的设备上运行时，如果 Android 检测到您的应用具有 4 KB 对齐的内存页面，则会自动使用兼容模式并向用户显示通知对话框。在 AndroidManifest.xml 中设置 android:pageSizeCompat 属性以启用向后兼容模式，将会阻止应用启动时显示对话框。如需使用 android:pageSizeCompat 属性，请使用 Android 16 SDK 编译您的应用。

为了实现最佳性能、可靠性和稳定性，应用仍应以 16 KB 对齐。如需了解详情，请参阅我们近期发布的博文，了解如何更新应用以支持 16 KB 的内存页面。

兼容模式对话框：当系统检测到 4 KB 对齐的应用在 16 KB 对齐的情况下可以更高效地运行时，系统会显示此对话框。

Esperienza utente e UI di sistema

Android 16 (livello API 36) include le seguenti modifiche volte a creare un'esperienza utente più coerente e intuitiva.

Deprecazione 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) e setAccessibilityPaneTitle(java.lang.CharSequence). In Scrivi, usa Modifier.semantics { paneTitle = "paneTitle" }
• Per informare l'utente delle modifiche all'interfaccia utente di importanza critica, utilizza setAccessibilityLiveRegion(int). In Scrivi, usa Modifier.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 tipo AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR e imposta AccessibilityNodeInfo#setError(CharSequence) oppure utilizza TextView#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).

Le animazioni Indietro predittive in modalità di navigazione con tre pulsanti.

Icone delle app a tema automatiche

A partire da Android 16 QPR 2, Android applica automaticamente i temi alle icone delle app per creare un'esperienza coerente nella schermata Home. Ciò si verifica se un'app non fornisce la propria icona dell'app a tema. Le app possono controllare il design dell'icona dell'app a tema includendo un livello monocromatico nell'icona adattiva e visualizzando l'aspetto dell'icona dell'app in Android Studio.

Fattori di forma del dispositivo

Android 16 (livello API 36) include le seguenti modifiche per le app quando vengono proiettate sui display dai proprietari di dispositivi virtuali.

Override del proprietario del dispositivo virtuale

Un proprietario del 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, come un computer personale, 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.

Il proprietario del dispositivo virtuale sullo smartphone crea un dispositivo virtuale che proietta l'app sul display remoto.

Override per app

Sui dispositivi con Android 16 (livello API 36), i proprietari di dispositivi virtuali possono ignorare le impostazioni delle app su determinati dispositivi virtuali che gestiscono. Ad esempio, per migliorare il layout delle app, il proprietario di un dispositivo virtuale può ignorare le limitazioni di orientamento, proporzioni e ridimensionamento durante la proiezione delle app su un display esterno.

Modifiche che provocano un errore comuni

Il comportamento di Android 16 potrebbe influire sulla UI della tua app su fattori di forma con schermi di grandi dimensioni, come display dell'auto o Chromebook, in particolare sui layout progettati per piccoli display in orientamento verticale. Per scoprire come rendere la tua app adattabile a tutti i fattori di forma dei dispositivi, consulta Informazioni sui layout adattabili.

Riferimenti

Streaming di app complementari

Sicurezza

Android 16 (livello API 36) include modifiche che promuovono la sicurezza del sistema per proteggere app e utenti da app dannose.

Maggiore sicurezza contro gli attacchi di reindirizzamento degli intent

Android 16 offre una protezione predefinita dagli attacchi di reindirizzamento Intent generali, con modifiche minime richieste per la compatibilità e gli sviluppatori.

Stiamo introducendo soluzioni di rafforzamento della sicurezza per impostazione predefinita per gli exploit di reindirizzamento Intent. Nella maggior parte dei casi, le app che utilizzano intent non riscontrano problemi di compatibilità. Abbiamo raccolto metriche durante il nostro processo di sviluppo per monitorare quali app potrebbero riscontrare interruzioni.

Il reindirizzamento degli 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 l'app malintenzionata ad avviare componenti privati nel contesto dell'app vittima, ad attivare azioni privilegiate o a ottenere l'accesso URI a dati sensibili, con conseguente 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 all'avvio. Ciò potrebbe essere necessario in casi specifici in cui il comportamento di sicurezza predefinito interferisce con casi d'uso legittimi dell'app.

Importante :la disattivazione delle protezioni di sicurezza deve essere eseguita con cautela e solo quando assolutamente necessario, in quanto può aumentare il rischio di vulnerabilità della sicurezza. Valuta attentamente il potenziale impatto sulla sicurezza della tua app prima di utilizzare questa API.

Per le applicazioni compilate con l'SDK Android 16 (livello API 36) 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 su Android 15 (livello API 35) o versioni precedenti

Anche se non è consigliato, puoi utilizzare la reflection per accedere al metodo removeLaunchSecurityProtection().

Attenzione :l'utilizzo della reflection può rendere il codice più fragile e soggetto a errori, soprattutto se l'API sottostante cambia nelle versioni future di Android. Se possibile, aggiorna l'SDK di compilazione in modo che abbia come target Android 16 (livello API 36) o versioni successive per utilizzare l'API direttamente.

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) }

Le app complementari non ricevono più notifiche relative ai timeout di rilevamento

Android 16 introduce un nuovo comportamento durante il percorso di accoppiamento del dispositivo complementare per proteggere la privacy della posizione dell'utente dalle app dannose. Tutte le app complementari in esecuzione su Android 16 non ricevono più una notifica diretta del timeout di rilevamento utilizzando RESULT_DISCOVERY_TIMEOUT. L'utente viene invece informato degli eventi di timeout con una finestra di dialogo visiva. Quando l'utente chiude la finestra di dialogo, l'app viene avvisata dell'errore di associazione con RESULT_USER_REJECTED.

La durata della ricerca è stata estesa rispetto ai 20 secondi iniziali e la ricerca del dispositivo può essere interrotta dall'utente in qualsiasi momento durante la ricerca. Se viene rilevato almeno un dispositivo nei primi 20 secondi dall'avvio della ricerca, il CDM interrompe la ricerca di altri dispositivi.

Connettività

Android 16 (livello API 36) include le seguenti modifiche nello stack Bluetooth per migliorare la connettività con i dispositivi periferici.

Gestione migliorata della perdita di associazione

Starting in Android 16, the Bluetooth stack has been updated to improve security and user experience when a remote bond loss is detected. Previously, the system would automatically remove the bond and initiate a new pairing process, which could lead to unintentional re-pairing. We have seen in many instances apps not taking care of the bond loss event in a consistent way.

To unify the experience, Android 16 improved the bond loss handling to the system. If a previously bonded Bluetooth device could not be authenticated upon reconnection, the system will disconnect the link, retain local bond information, and display a system dialog informing users of the bond loss and directing them to re-pair.