La seconde préversion pour les développeurs d’Android 16 est désormais accessible pour tester vos applications. Cette version comprend des modifications visant à améliorer l’expérience utilisateur, l’autonomie de la batterie et les performances tout en minimisant les incompatibilités. Vos retours sont essentiels pour nous aider à comprendre l’impact global de ce travail.
**Profilage déclenché par le système**
`ProfilingManager` a été ajouté dans Android 15, donnant aux applications la possibilité de demander la collecte de données de profilage en utilisant Perfetto sur des appareils publics déployés. Pour aider à capturer des scénarios de trace complexes tels que les démarrages ou les ANR, `ProfilingManager` inclut désormais le profilage déclenché par le système. Les applications peuvent utiliser `ProfilingManager#addProfilingTriggers()` pour enregistrer leur intérêt à recevoir des informations sur ces flux. Les flux couverts dans cette version incluent `onFullyDrawn` pour les démarrages à froid basés sur les activités et les ANR.
« `
val anrTrigger = ProfilingTrigger.Builder(
ProfilingTrigger.TRIGGER_TYPE_ANR
)
.setRateLimitingPeriodHours(1)
.build()
val startupTrigger: ProfilingTrigger = //…
mProfilingManager.addProfilingTriggers(listOf(anrTrigger, startupTrigger))
« `
**Démarrer le composant dans `ApplicationStartInfo`**
`ApplicationStartInfo` a été ajouté dans Android 15, permettant à une application de voir les raisons du démarrage du processus, le type de démarrage, les heures de démarrage, la limitation de débit et d’autres données de diagnostic utiles. Android 16 ajoute `getStartComponent()` pour distinguer quel type de composant a déclenché le démarrage, ce qui peut être utile pour optimiser le flux de démarrage de votre application.
**Haptique plus riche**
Android a exposé un contrôle limité sur l’actionneur haptique depuis sa création.
Android 11 a ajouté le support pour des effets haptiques plus complexes que les actionneurs plus avancés peuvent supporter via `VibrationEffect.Compositions` de primitives sémantiques définies par l’appareil.
Android 16 ajoute des `API haptic` qui permettent aux applications de définir les courbes d’amplitude et de fréquence d’un effet haptique tout en faisant abstraction des différences entre les capacités des appareils.
**Meilleure introspection des tâches**
Android 16 introduit `JobScheduler#getPendingJobReasons(int jobId)` qui peut renvoyer de multiples raisons pour lesquelles une tâche est en attente, en raison à la fois de contraintes explicites définies par le développeur et de contraintes implicites définies par le système.
Nous introduisons également `JobScheduler#getPendingJobReasonsHistory(int jobId)`, qui renvoie une liste des changements de contraintes les plus récents.
Cette API peut vous aider à déboguer pourquoi vos tâches ne s’exécutent pas, surtout si vous constatez une diminution des taux de réussite de certaines tâches ou des problèmes de latence lors de l’achèvement des tâches. Cela peut également vous aider à mieux comprendre si certaines tâches ne s’achèvent pas en raison de contraintes définies par le système ou de contraintes définies explicitement.
**Taux de rafraîchissement adaptatif**
Le taux de rafraîchissement adaptatif (TRA), introduit dans Android 15, permet au taux de rafraîchissement d’affichage sur le matériel pris en charge de s’adapter à la fréquence d’images du contenu en utilisant des étapes de synchronisation verticale discrètes. Cela réduit la consommation d’énergie tout en éliminant le besoin d’un changement de mode potentiellement saccadé.
Android 16 DP2 introduit `hasArrSupport()` et `getSuggestedFrameRate(int)` tout en restaurant `getSupportedRefreshRates()` pour faciliter la prise en charge du TRA par vos applications.
RecyclerView 1.4 prend en charge le TRA en interne lorsqu’il se stabilise après un balayage ou un défilement fluide, et nous poursuivons nos efforts pour ajouter la prise en charge du TRA dans davantage de bibliothèques Jetpack. Cet article sur la fréquence d’images couvre de nombreuses API que vous pouvez utiliser pour définir la fréquence d’images afin que votre application puisse exploiter directement le TRA.
**Optimisations de l’exécution des tâches**
À partir d’Android 16, nous ajusterons le quota d’exécution des tâches régulières et accélérées en fonction des facteurs suivants :
* Dans quel compartiment de mise en veille de l’application l’application se trouve ; les compartiments de mise en veille active bénéficieront d’un quota d’exécution généreux.
* Les tâches démarrées alors que l’application est visible pour l’utilisateur et qui se poursuivent après que l’application devient invisible adhéreront au quota d’exécution des tâches.
* Les tâches qui s’exécutent simultanément avec un service au premier plan adhéreront au quota d’exécution des tâches. Si vous devez effectuer un transfert de données qui peut prendre beaucoup de temps, envisagez d’utiliser un transfert de données initié par l’utilisateur.
**Remarque :** Pour comprendre comment déboguer et tester davantage ce changement de comportement, découvrez-en plus sur les optimisations du quota de JobScheduler.
**Obsolescence complète de `JobInfo#setImportantWhileForeground`**
La méthode `JobInfo.Builder#setImportantWhileForeground(boolean)` indique l’importance d’une tâche alors que l’application de planification est au premier