Android 11 viendra avec DSU Loader dans les options de développement qui vous permettra de télécharger et d'installer automatiquement les GSI compatibles! Lisez la suite pour en savoir plus !
Un bon écosystème d'applications est l'un des piliers les plus importants du succès d'un système d'exploitation. Google et Apple reconnaissent tous deux l'importance d'avoir de bonnes applications sur leurs plates-formes, et les deux entreprises essaient donc d'équilibrer les besoins de leurs utilisateurs et de leurs développeurs d'applications. Les utilisateurs continuent de pousser pour des changements dans les systèmes d'exploitation, et bien que la plupart des gens apprécient généralement les nouvelles fonctionnalités, celles-ci les changements ne sont pas toujours amusants pour les développeurs d'applications car ils peuvent modifier de nombreuses fonctionnalités de base et comportement. Pour les développeurs qui s'efforcent constamment de maintenir la pertinence de leurs applications, la gestion de ces changements s'ajoute à leur liste de travail croissante. Même si ces changements n'affectent pas directement leurs applications, les développeurs doivent toujours s'assurer que leurs applications fonctionneront sur la nouvelle mise à jour du système d'exploitation. Google a apporté de nombreux changements au fil des ans pour faciliter ce processus pour les développeurs d'applications Android, et maintenant, un nouveau fonctionnalité d'Android 11, appelée DSU Loader, permettra aux développeurs d'applications de tester encore plus facilement leurs applications sur le nouvel Android versions.
Ça commence avec Project Treble
Project Treble, introduit dans Android 8.0, est un réarchitecture du système d'exploitation Android. L'objectif de Project Treble était de diviser le système d'exploitation Android en deux gros morceaux: le framework et l'implémentation du fournisseur. ("fournisseur" désigne ici le fabricant de tout composant matériel propriétaire trouvé dans un appareil, faisant généralement référence au silicium). Le framework Android OS est le système d'exploitation lui-même, y compris toutes les applications système, l'interface utilisateur et ses composants, ainsi que les API partagées entre les appareils Android. L'implémentation du fournisseur contient les HAL (Hardware Abstraction Layers) du fournisseur et le noyau Linux et les modules du noyau Linux.
Étant donné que les OEM livrent des smartphones avec de nombreux composants matériels différents de nombreux fournisseurs différents, ils doivent faire beaucoup de travail juste pour que le matériel soit opérationnel sur une seule version du système d'exploitation Android. Ensuite, à chaque nouvelle mise à jour du système d'exploitation Android, ils doivent faire encore plus de travail pour s'assurer que leur matériel fonctionne avec la nouvelle version. Mais avec Project Treble normalisant l'ABI (Application Binary Interface) entre le framework Android OS et les HAL pour une version Android particulière, Les OEM Android peuvent commencer à tester les mises à jour de leurs appareils sans avoir à attendre que les fabricants de silicium et d'autres fabricants de composants mettent à jour leur côté de le code. Ce changement s'est sensiblement accéléré la façon dont les mises à jour Android sont gérées.
C'est l'essentiel de ce que Project Treble a fait pour les mises à jour Android, mais ce qui est le plus important pour l'application développeurs ici est que Treble a permis l'utilisation d'images système génériques (GSI) pour la compatibilité essai.
L'émergence des GSI
Pour que les OEM puissent tester s'ils ont correctement implémenté Project Treble, Google exige que l'OEM soit en mesure de démarrer une version propre d'Android à partir d'AOSP sur l'appareil. Cette version propre d'Android s'appelle l'image système générique, ou GSI. Si le GSI démarre et que la plupart des composants matériels de base fonctionnent correctement, l'OEM sait que son appareil répond aux exigences de Project Treble. Le but initial des GSI était donc de tester la compatibilité Treble, mais comme nous l'avons vu avec la communauté de développement ici chez XDA-Developers, ils peuvent être utilisés à d'autres fins. Nous avons vu comment les GSI pourrait essentiellement permettre aux appareils avec de lourds UX Android de profiter de la dernière version d'Android avec des fonctionnalités de travail dans les jours suivant une nouvelle version. Mais Google envisage un autre objectif derrière le GSI: donner aux développeurs d'applications la possibilité de tester leurs applications sur une nouvelle version d'Android sur un appareil physique qu'ils possèdent déjà.
Avec Android 10, Google a publié ses propres versions GSI pour les développeurs. Google a cimenté l'idée que les développeurs d'applications devraient utiliser un GSI pour démarrer une version propre d'Android sur leur propre matériel, ce qui facilite le test du comportement de leur application par rapport à Android stock. Cette méthode s'est donc ajoutée aux options existantes de test de compatibilité des applications sur Android stock sans changement de comportement OEM, les autres étant en utilisant un smartphone Pixel, en utilisant l'émulateur Android officiel dans Android Studio ou en déployant des versions d'application sur une instance d'appareil sur le cloud.
Malgré toute la commodité apportée par les GSI, leur installation restait un processus fastidieux. Les développeurs d'applications peuvent ne pas être à l'aise avec le flashage manuel d'une image système sur un appareil Android, car c'est généralement quelque chose que seuls les amateurs ou les développeurs d'OS Android connaissent. L'installation d'un GSI nécessitait de flasher une image système via un démarrage rapide, ce qui nécessite de désactiver le démarrage vérifié d'Android et de déverrouiller le chargeur de démarrage. Le déverrouillage du chargeur de démarrage, à son tour, nécessite un effacement complet des données utilisateur. Et comme nous le savons tous, il n'y a pas exactement un seul processus ou guide pour déverrouiller le chargeur de démarrage de chaque appareil Android, il n'y a donc aucune cohérence à trouver. Par exemple, les appareils Samsung n'ont pas de démarrage rapide tandis que les appareils Xiaomi vous font sauter quelques étapes pour déverrouiller le chargeur de démarrage. C'est un gâchis pratique qui a le potentiel d'être démêlé en quelque chose de plus simple.
C'est là qu'interviennent les mises à jour dynamiques du système.
Mises à jour dynamiques du système installant simplement les GSI
Google s'est rendu compte que la méthode actuelle d'installation des GSI n'était pas une solution parfaite, alors ils ont commencé à travailler sur une meilleure solution. Sous Androïd 10, Google a commencé à tester les mises à jour dynamiques du système, ou DSU. DSU est une nouvelle façon d'installer temporairement un GSI sans avoir besoin d'utiliser des commandes fastboot pour flasher une image système, en écrasant l'installation d'origine. Avec DSU, vous pouvez démarrer dans un GSI, tester votre application, puis redémarrer facilement dans votre installation d'origine qui est restée intacte.
La raison pour laquelle DSU peut installer un GSI sans toucher à l'installation d'origine est qu'il crée de nouvelles images système et de partition de données qui sont temporairement stockées dans /data/gsi. Ces images sont ensuite montées lors du démarrage plutôt que le système d'origine et les partitions de données. Étant donné que le téléphone a besoin d'espace de stockage supplémentaire pour ces nouvelles images temporaires, votre téléphone doit avoir des "partitions logiques" à bord, qui sont des partitions redimensionnables dynamiquement. Les partitions logiques sont un nouveau système de partitionnement de l'espace utilisateur pour Android, qui est obligatoire pour les appareils lancés avec Android 10. Si votre appareil a été lancé avec Android 10, il devrait prendre en charge l'installation de GSI via DSU.
Dans Android 10, tout ce que vous avez à faire pour installer un GSI via DSU consiste à modifier une propriété système puis à lancer le DynamicSystemUpdatesInstallationService en envoyant une intention avec le chemin vers le GSI en tant qu'intention supplémentaire.
Bien que ce processus puisse sembler peu familier, il est de loin plus facile et moins intrusif par rapport à l'utilisation commandes fastboot et gérer les tracas de tout, y compris l'installation d'origine, étant essuyé. Vous avez besoin d'une certaine connaissance d'ADB et des intentions d'utiliser DSU, mais cela ne devrait pas être un problème pour la plupart des développeurs d'applications. Pourtant, il n'y a aucune raison pour que le processus ne soit pas encore simplifié. De plus, il y a le fait que l'installation d'un GSI via DSU nécessite toujours que vous déverrouilliez le chargeur de démarrage, effaçant toutes les données utilisateur au cours du processus. À cette fin, Google a mis en œuvre des modifications pour améliorer les deux aspects de l'installation de GSI. Dans Android 11, ils ont éliminé le besoin d'utiliser la ligne de commande pour installer un GSI. Séparément, ils ont également permis d'installer un GSI sans déverrouiller le chargeur de démarrage.
Chargeur DSU dans Android 11
DSU Loader est un nouvel outil présent dans les options de développement d'Android 11 qui vous permet de télécharger et installer le dernier GSI de Google sans avoir à saisir de commandes fastboot ou ADB. Appuyez simplement sur l'option DSU Loader dans les paramètres et une boîte de dialogue apparaîtra avec une liste des GSI pris en charge directement à partir de Google. Ces GSI pris en charge seront basés sur votre système d'exploitation et votre architecture actuels, vous ne pouvez donc installer que des GSI qui sont plus récents que la version de votre système d'exploitation et qui correspondent à votre architecture SoC. Choisissez simplement le GSI que vous souhaitez installer et il sera téléchargé à partir des serveurs de Google et installé automatiquement en arrière-plan.
Avec DSU Loader, les développeurs n'ont jamais à toucher à la ligne de commande pour installer un GSI. Du moins, c'est le rêve, car il reste encore un problème à résoudre.
La voie à suivre
Actuellement, pour installer un GSI via DSU Loader, vous avez besoin d'un chargeur de démarrage déverrouillé. Bien que cela puisse aller à l'encontre du but de toute l'épreuve, ce n'est pas censé être ainsi, et on nous dit que cela sera corrigé. Google a prévu que les utilisateurs puissent démarrer les GSI signés par Google via DSU sans avoir à déverrouiller le chargeur de démarrage. En fait, Google exige que tous les appareils de lancement Android 10 incluent les clés publiques Android Verified Boot des GSI Android 10, Android 11 et Android 12 signés par Google. L'inclusion des clés publiques AVB dans le disque virtuel de l'appareil garantira qu'AVB ne rejettera pas le GSI que vous essayez de démarrer. C'est pourquoi la méthode actuelle consiste à déverrouiller le chargeur de démarrage - en flashant une image vbmeta vide sur la partition vbmeta, vous désactivez AVB afin qu'il ne rejette pas le GSI que vous êtes sur le point de flasher. La désactivation d'AVB est cependant un risque majeur pour la sécurité, car cela signifie que tout la partition system/boot/product/vendor peut être chargée sur l'appareil, c'est pourquoi Google veut faire loin de cette exigence.
Alors, quand pouvez-vous espérer démarrer un GSI via DSU sans avoir à déverrouiller le chargeur de démarrage ou à utiliser des outils de ligne de commande? Espérons que bientôt, comme Google nous l'a mentionné, ils avaient quelques problèmes à régler avec les premiers aperçus du développeur Android 11 avant de pouvoir tout faire fonctionner correctement. À l'avenir, on peut s'attendre à installer les futurs GSI Developer Preview via DSU sans avoir à déverrouiller le chargeur de démarrage. Peut-être que lorsque les aperçus de développeur d'Android 12 seront disponibles, vous pourrez même le démarrer entièrement en utilisant DSU Loader dans les options de développement d'Android 11. Pour les développeurs d'applications, cela signifie qu'il y aura encore un autre moyen pour vous de tester vos applications sur du matériel physique exécutant une nouvelle version d'Android.