Google a ajouté une API qui permet aux lanceurs tiers comme Nova Launcher d'afficher des animations de transition plus fluides. Seuls les téléphones Pixel l’ont désormais.
Dans le passé, les applications de lancement tierces offraient souvent une expérience supérieure au lanceur standard trouvé sur la plupart des téléphones Android. Avec la refonte de l'écran des applications récentes et l'introduction des gestes dans Android 9 Pie, cependant, les lanceurs tiers ont été désavantagés car ces nouvelles expériences ont été intégrées au stock application de lancement. Au fil du temps, Google a essayé de rendre l'expérience des lanceurs tiers moins terrible lors de l'utilisation de gestes, et ils ont en fait commencé à y parvenir récemment.
Si vous avez utilisé une version bêta récente de Nova Launcher sur un téléphone Google Pixel au cours des derniers mois, vous avez peut-être remarqué les animations fluides lors de l'utilisation de la navigation gestuelle. Malheureusement, vous ne verrez pas ces mêmes animations lorsque vous utiliserez Nova Launcher sur un autre appareil, du moins pour le moment. Pour comprendre pourquoi nous devons d'abord expliquer brièvement ce qui différencie les lanceurs tiers comme Nova Launcher des lanceurs de stock comme Pixel Launcher de Google.
Google a introduit pour la première fois la navigation gestuelle dans Android 9 Pie. Afin de rendre les gestes aussi fluides que possible, Google devait rendre les transitions d'applications transparentes. Ils souhaitaient également permettre aux utilisateurs d'accéder à l'intégralité de leur liste d'applications à partir de l'écran des applications récentes. Pour faire ces deux choses, Google a décidé de déplacer le code qui gère l'écran des applications récentes de celui d'Android. SystemUI vers Launcher3, l'application de lancement open source d'Android à partir de laquelle sont issus la plupart des lanceurs d'origine OEM. Ainsi, le Étape rapide Le composant est né et, en raison de sa nature privilégiée, Android permet uniquement de définir l'application de lancement préinstallée comme fournisseur d'applications récentes. Cela peut être remplacé par un accès root si le lanceur tiers le prend en charge, mais pour la plupart des utilisateurs, cela signifie qu'une application de lancement tierce s'appuiera toujours sur le lanceur de stock pour gérer les gestes et l'écran des applications récentes. Le résultat, comme la plupart d’entre vous l’ont probablement constaté, peut être un peu saccadé, avec des transitions qui ne semblent pas fluides et transparentes. Sauf si vous utilisez un téléphone Google Pixel, bien sûr.
Sur la plupart des téléphones Google Pixel, il existe une API que les lanceurs tiers peuvent utiliser pour rendre la transition d'une application vers l'écran d'accueil beaucoup plus native. Certaines applications de lancement tierces comme Lanceur Niagara et le Nova Launcher susmentionné profitent de cette API, bien que ce dernier ne l'inclue que dans son versions v7 en développement. Lorsque cette API est utilisée, l'application de lancement tierce reçoit une intention et un rappel de QuickStep chaque fois que l'utilisateur effectue un geste de balayage pour rentrer chez lui. Le lanceur tiers peut alors indiquer au système gestuel comment animer la fenêtre lorsqu'elle se réduit sur une icône d'application.
Voici un exemple de ce à quoi cela ressemble dans Niagara Launcher, gracieuseté du développeur du lanceur 8bitpit:
Et voici une comparaison qui montre à quoi ressemble l'animation sur un Téléphone ASUS ROG 5 et GooglePixel 4, tous deux exécutant Nova Launcher v7.0.25 (la dernière version bêta au moment de la publication) et Android 11 :
\r\n https://www.youtube.com/watch? v=equ-8yDw_Do\r\n
Maintenant, vous vous demandez peut-être: cette API est-elle exclusive aux téléphones Google Pixel? La réponse est non, ce n'est pas le cas. L'API fait partie de Launcher3/QuickStep et peut être trouvé dans AOSP, ce qui signifie qu'il est ouvert à n'importe quelle application de lancement OEM. Alors que l'API était engagé envers Launcher3 en interne le 21 juillet 2020, il semblerait que ce soit fusionné dans la branche principale AOSP avec la version Android R QPR1 en décembre.
Kevin Barry, le développeur de Nova Launcher et l'un des premiers à avoir repéré cette API, nous a confié qu'il soupçonnait une partie du La raison pour laquelle les OEM n'utilisent pas cette API dans leurs forks de Launcher3 est qu'elle est arrivée un peu tard dans la version d'Android 11. faire du vélo. Il faut pas mal d'efforts pour fusionner les gros changements AOSP, et la mise à jour Android R QPR1 en contenait certainement beaucoup. Dans le passé, nous appelions ces versions de code une "version de maintenance", mais Google ne les fait plus vraiment après les refus des OEM (du moins c'est ce que j'ai entendu). C'est pourquoi LineageOS, la ROM personnalisée Android populaire, appelle sa dernière version "LignéeOS 18.1" plutôt que " LineageOS 18 " pour signifier que la ROM est basée sur la dernière base de code Android 11 plutôt que sur la version initiale d'Android 11.
Il convient également de noter que cette API n'est accessible sur les téléphones Google Pixel qu'après la Suppression des fonctionnalités Pixel de décembre, qui coïncide avec la sortie publique d'Android R QPR1. Et bien que le Pixel 2 obtienne son dernière mise à jour en décembre, cette mise à jour n'incluait pas la base de code Android R QPR1, c'est pourquoi les propriétaires de Pixel 2 exécutant Nova Launcher v7 n'ont pas la même expérience que les autres Pixel. (Les propriétaires de Pixel 2 peuvent télécharger une version plus récente de Pixel Launcher qui possède l'API d'un appareil Pixel plus récent, mais les rapports des utilisateurs indiquent l'animation est toujours buggée même si elle fonctionne de temps en temps. Pour rappel, Pixel Launcher est construit sur Launcher3, tout comme la plupart des lanceurs d'origine, mais il inclut également certaines fonctionnalités exclusives à Pixel.)
Alors, que faudra-t-il pour que cette API soit ajoutée à d’autres appareils Android? Malheureusement, il n'y a pas de réponse simple à cette question, car nous ne savons pas exactement comment chaque OEM développe son application de lancement. Étant donné comment Google contrôle étroitement la navigation gestuelle en plein écran, nous pensons que la plupart des OEM ne modifient pas fortement le code lié aux gestes et/ou à QuickStep. À moins qu'un OEM ne fasse tout son possible pour annuler la validation, casser le code ou refuser de mettre à jour Launcher3, nous devrions alors voir cette API être ajoutée aux lanceurs OEM chaque fois qu'ils se rebasent au-dessus du A venir Android 12 libérer. En fait, un OEM avec lequel nous avons parlé, ASUS, nous a dit qu'il prévoyait d'intégrer cette API dans sa mise à jour Android 12. Nous ne savons pas si Google a communiqué ce changement aux OEM, mais nous espérons que davantage d'OEM prendront note de ce changement. et décident d'incorporer l'API dans leurs forks de Launcher3 pour améliorer l'expérience d'utilisation de tiers lanceurs.
Mais le travail ne s'arrêtera pas là. Même après avoir inclus cette API, il reste encore du travail à faire pour atteindre la parité entre les lanceurs tiers et les lanceurs OEM. Par exemple, certains appareils OEM scintillent lorsque l'utilisateur appuie sur l'écran avant qu'une animation sur l'écran d'accueil n'apparaisse. Parfois, l'application de lancement du système apparaît à la place de l'application de lancement tierce sélectionnée (cela m'est arrivé plusieurs fois). Une animation de transition améliorée est agréable, mais personne ne veut gérer les bugs dans l'application de lancement ou dans l'écran des applications récentes, donc le code gestuel a encore besoin d'un nettoyage et/ou d'une normalisation.
Merci à Kevin Barry et Peter Huber pour leur aide dans cet article !