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 esigenze 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

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.

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 includes the latest updates to the Android Runtime (ART) that improve the Android Runtime's (ART's) performance and provide support for additional Java features. Through Google Play System updates, these improvements are also available to over a billion devices running Android 12 (API level 31) and higher.

As these changes are released, libraries and app code that rely on internal structures of ART might not work correctly on devices running Android 16, along with earlier Android versions that update the ART module through Google Play system updates.

Relying on internal structures (such as non-SDK interfaces) can always lead to compatibility problems, but it's particularly important to avoid relying on code (or libraries containing code) that leverages internal ART structures, since ART changes aren't tied to the platform version the device is running on and they go out to over a billion devices through Google Play system updates.

All developers should check whether their app is impacted by testing their apps thoroughly on Android 16. In addition, check the known issues to see if your app depends on any libraries that we've identified that rely on internal ART structures. If you do have app code or library dependencies that are affected, seek public API alternatives whenever possible and request public APIs for new use cases by creating a feature request in our issue tracker.

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

Android 15 introduced support for 16 KB memory pages to optimize performance of the platform. Android 16 adds a compatibility mode, allowing some apps built for 4 KB memory pages to run on a device configured for 16 KB memory pages.

When your app is running on a device with Android 16 or higher, if Android detects that your app has 4 KB aligned memory pages, it automatically uses compatibility mode and display a notification dialog to the user. Setting the android:pageSizeCompat property in the AndroidManifest.xml to enable the backwards compatibility mode will prevent the display of the dialog when your app launches. To use the android:pageSizeCompat property, compile your app using the Android 16 SDK.

For best performance, reliability, and stability, your app should still be 16 KB aligned. Check out our recent blog post on updating your apps to support 16 KB memory pages for more details.

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

Icone delle app a tema automatiche

Beginning with Android 16 QPR 2, Android automatically applies themes to app icons to create a cohesive home screen experience. This occurs if an app does not provide its own themed app icon. Apps can control the design of their themed app icon by including a monochrome layer within their adaptive icon and previewing what their app icon will look like 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 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.

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 display piccoli 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 Intentgenerali, con modifiche minime richieste per la compatibilità e gli sviluppatori.

Stiamo introducendo soluzioni di hardening della sicurezza predefinite per gli exploit di reindirizzamento di 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 degli 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.

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().

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 obbligazioni

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.