Le second aperçu pour les développeurs d’Android 16 est désormais disponible pour tester avec vos applications. Cette version inclut des changements visant à améliorer l’expérience utilisateur, optimiser l’autonomie de la batterie et booster les performances tout en minimisant les incompatibilités. Vos commentaires sont essentiels pour nous aider à comprendre l’impact complet de ces modifications.
**Profilage déclenché par le système**
`ProfilingManager` a été ajouté à Android 15, donnant aux applications la possibilité de demander une collecte de données de profilage à l’aide de Perfetto sur les appareils publics sur le terrain. Pour aider à capturer des scénarios de suivi difficiles 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 manifester 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 un composant dans `ApplicationStartInfo`**
`ApplicationStartInfo` a été ajouté à 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 et d’autres données de diagnostic utiles. Android 16 ajoute `getStartComponent()` pour distinguer le type de composant qui a déclenché le démarrage, ce qui peut être utile pour optimiser le flux de démarrage de votre application.
**Haptiques plus riches**
Android a exposé un contrôle limité sur l’actionneur haptique depuis sa création.
Android 11 a ajouté la prise en charge d’effets haptiques plus complexes que les actionneurs plus avancés peuvent prendre en charge via `VibrationEffect.Compositions` de primitives sémantiques définies par l’appareil.
Android 16 ajoute des `API haptiques` 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 de l’appareil.
**Meilleure introspection des tâches**
Android 16 introduit `JobScheduler#getPendingJobReasons(int jobId)` qui peut renvoyer plusieurs raisons pour lesquelles une tâche est en attente, en raison 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 derniers changements de contraintes.
L’API peut vous aider à déboguer pourquoi vos tâches peuvent ne pas s’exécuter, surtout si vous constatez des taux de réussite réduits avec certaines tâches ou des problèmes de latence avec 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.
**Fréquence de rafraîchissement adaptative**
La fréquence de rafraîchissement adaptative (ARR), introduite dans Android 15, permet à la fréquence de rafraîchissement de l’affichage sur le matériel pris en charge de s’adapter au débit d’images du contenu en utilisant des étapes VSync discrètes. Cela réduit la consommation d’énergie tout en éliminant le besoin de commutation de mode potentiellement gênante.
Android 16 DP2 introduit `hasArrSupport()` et `getSuggestedFrameRate(int)` tout en restaurant `getSupportedRefreshRates()` pour faciliter l’exploitation de l’ARR par vos applications.
RecyclerView 1.4 prend en charge l’ARR en interne lorsqu’il se rétablit après un lancer ou un défilement fluide, et nous poursuivons nos travaux pour ajouter la prise en charge de l’ARR dans davantage de bibliothèques Jetpack. Cet article sur le débit d’images couvre de nombreuses API que vous pouvez utiliser pour définir le débit d’images afin que votre application puisse directement exploiter l’ARR.
**Optimisations de l’exécution des tâches**
À partir d’Android 16, nous ajustons le quota d’exécution des tâches régulières et accélérées en fonction des facteurs suivants :
* Dans quel emplacement de veille de l’application se trouve l’application ; les emplacements de veille actifs bénéficieront d’un quota d’exécution généreux.
* Les tâches lancées lorsque l’application est visible pour l’utilisateur et qui continuent après que l’application devient invisible respecteront le quota d’exécution des tâches.
* Les tâches qui s’exécutent simultanément avec un service de premier plan respecteront le 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 le changement de comportement, lisez-en plus sur les optimisations du quota JobScheduler.
**