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 dal 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 delle quote di JobScheduler

从 Android 16 开始，我们将根据以下因素调整常规作业和加急作业的执行运行时配额：

• 应用所处的应用待机存储分区：在 Android 16 中，活跃待机存储分区将开始通过宽松的运行时配额强制执行。
• 如果作业在应用处于前台状态时开始执行：在 Android 16 中，如果作业在应用对用户可见时开始执行，并在应用变为不可见后继续执行，则会遵守作业运行时配额。
• 如果作业在运行前台服务时执行：在 Android 16 中，与前台服务同时执行的作业将遵守作业运行时配额。如果您利用作业进行用户发起的数据传输，请考虑改用用户发起的数据传输作业。

此变更会影响使用 WorkManager、JobScheduler 和 DownloadManager 调度的任务。如需调试作业停止的原因，我们建议您通过调用 WorkInfo.getStopReason()（对于 JobScheduler 作业，请调用 JobParameters.getStopReason()）来记录作业停止的原因。

如需了解应用的状态如何影响其可使用的资源，请参阅电源管理资源限制。 如需详细了解电池优化方面的最佳实践，请参阅有关针对任务调度 API 优化电池使用的指南。

我们还建议利用 Android 16 中引入的新 JobScheduler#getPendingJobReasonsHistory API 来了解作业未执行的原因。

测试

如需测试应用的行为，只要应用在 Android 16 设备上运行，您就可以启用对某些作业配额优化功能的替换。

如需停用“顶级状态将遵守作业运行时配额”的强制执行，请运行以下 adb 命令：

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

如需停用“在与前台服务同时执行时，作业将遵守作业运行时配额”的强制执行，请运行以下 adb 命令：

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

如需测试特定应用待机分桶行为，您可以使用以下 adb 命令设置应用的应用待机分桶：

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

如需了解应用所在的待机分桶，您可以使用以下 adb 命令获取应用的待机分桶：

adb shell am get-standby-bucket APP_PACKAGE_NAME

Motivo di interruzione dei processi 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:

1. 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à.
2. 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 ad 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 引入了对 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.

Ritiro degli annunci di accessibilità invasivi

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 dei dispositivi

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 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 proiettano le app 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 per 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 sicurezza predefinita contro gli attacchi di reindirizzamento Intent generali, con modifiche minime alla compatibilità e allo sviluppo richieste.

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 在配套设备配对流程期间引入了一种新行为，以防恶意应用侵犯用户的位置信息隐私。在 Android 16 上运行的所有配套应用都不再直接通过 RESULT_DISCOVERY_TIMEOUT 收到发现超时通知。而是通过可视对话框通知用户超时事件。当用户关闭对话框时，系统会通过 RESULT_USER_REJECTED 提醒应用关联失败。

搜索时长也从原来的 20 秒延长到了 30 秒，并且用户可以在搜索期间的任何时间停止设备发现。如果在开始搜索的前 20 秒内发现了至少 1 部设备，CDM 会停止搜索其他设备。

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 cauzione

A partire da Android 16, lo stack Bluetooth è stato aggiornato per migliorare la sicurezza e l'esperienza utente quando viene rilevata una perdita del legame remoto. In precedenza, il sistemarimuoveva automaticamente il legame e avviava una nuova procedura di accoppiamento, che poteva portare a un'accoppiata non intenzionale. In molti casi abbiamo notato che le app non gestiscono l'evento di perdita del legame in modo coerente.

Per unificare l'esperienza, Android 16 ha migliorato la gestione della perdita del legame con il sistema. Se un dispositivo Bluetooth accoppiato in precedenza non può essere autenticato al nuovo collegamento, il sistema scollega il link, conserva le informazioni sull'accoppiamento locale e mostra una finestra di dialogo di sistema che informa gli utenti della perdita dell'accoppiamento e li invita a eseguire nuovamente l'accoppiamento.