Mises à jour dynamiques du système dans Android Q: comment Project Treble améliorera les futures versions d'Android

Parallèlement à la sortie d'Android 8.0 Oreo, Google a dévoilé Projet triple: une réarchitecture majeure dans la façon dont le framework du système d'exploitation Android et les HAL des fournisseurs et le noyau Linux communiquent. Treble est une initiative majeure conçue pour réduire la version de la plateforme Android et fragmentation des correctifs de sécurité, et tous les appareils de marque Android lancés avec Android Pie doivent prendre en charge Project Treble. Les OEM et les fournisseurs testent la compatibilité Treble en démarrant une image système générique (GSI) (une version purement stockée d'Android d'AOSP) et en passant le test. Suite de tests du fournisseur (VTS) et suite de tests de compatibilité sur image système générique (CTS-on-GSI). Le GSI s'est avéré utile non seulement en permettant aux ingénieurs logiciels travaillant pour les constructeurs OEM de tester la compatibilité des aigus, mais il a également ouvert la porte à un

grande communauté ROM personnalisée sur XDA. Pour la version Android Q, Google souhaite rendre les GSI utiles à un autre groupe: les développeurs d'applications.

Étant donné que la première version stable et la suppression du code source d'une version de plate-forme Android donnée surviennent généralement en août, les développeurs qui souhaitent tester la prochaine version d'Android sur un appareil réel ont généralement besoin d'accéder à un smartphone Google s'ils ne veulent pas attendre que la mise à jour atteigne leur propre matériel. Cependant, Google a travaillé avec les constructeurs OEM pour apporter une Android P bêta à plusieurs appareils l'année dernière, et ils ont suivi cette année avec un Android Q bêta. Parallèlement à une version bêta officielle d'Android Q, Google a également publié cette année un Q bêta officielle GSI Ainsi, tout développeur disposant d'un appareil compatible Project Treble peut installer la dernière version de Q sans avoir à attendre des mois pour que la version atteigne ses appareils. Cette nouvelle façon de tester la prochaine version d'Android donne aux développeurs plus de possibilités, et donc plus de temps, pour tester leurs applications. changements majeurs dans Android.

Malheureusement, la méthode actuelle de installer un GSI peut être difficile. Cela nécessite de déverrouiller le chargeur de démarrage (ce qui signifie effacer toutes les données utilisateur et/ou annuler la garantie) et de flasher une image via le protocole de démarrage rapide. Ce n'est pas un processus simple et rapide à suivre pour un développeur d'applications, si son appareil permet même de déverrouiller le bootloader. C'est pourquoi, pour le ces derniers mois, Google a travaillé sur une nouvelle façon de démarrer les GSI. Entrez une nouvelle fonctionnalité appelée Dynamic System Update, ou DSU.

(Cette fonctionnalité a été précédemment développée sous les noms « Live Image », « Dynamic Android » et « Android on Tap », alors ne soyez pas surpris si Google l'appelle autrement dans quelques semaines ou mois.)

Mises à jour dynamiques du système dans Android Q

L'objectif de la fonctionnalité DSU est de permettre à un développeur de démarrer sur un GSI sans interférer avec l'installation en cours. Cela signifie que le chargeur de démarrage n'a pas besoin d'être déverrouillé et que les données utilisateur n'ont pas besoin d'être effacées. Le processus d'installation est également grandement simplifié puisque Google a fourni une interface de ligne de commande via ADB et une application qui peut être contrôlée via des intentions. Voici à quoi cela ressemble pour démarrer un GSI à l'aide de DSU :

Dans cette vidéo*, un Google Pixel 3 XL exécutant Android Q bêta 3 redémarre sur un GSI. Dans cet environnement, un développeur d'applications peut installer et tester la compatibilité de son application avec l'API Q. Une fois les tests terminés, ils peuvent simplement redémarrer avec le logiciel Q beta 3 standard sur l'appareil. En gros, vous effectuez un double démarrage sur un GSI afin de pouvoir tester votre application en toute sécurité !

*Nous avons enregistré cette vidéo lors de Google I/O 2019 alors que DSU n'était pas encore accessible au public. La version bêta 3 de Q sur le Pixel 3 XL filmé a donc été légèrement modifiée par Google pour inclure la prise en charge de DSU. Les appareils exécutant Q beta 4 et versions ultérieures sont éligibles à la prise en charge de DSU s'ils répondent aux exigences ci-dessous.

Exigences pour les mises à jour dynamiques du système

Faire fonctionner ce qui est essentiellement un double démarrage n’a pas été une tâche facile pour Google. Des changements majeurs ont dû être apportés à la manière dont les partitions sont gérées sur le Pixel 3, le banc d'essai de Google pour DSU. Ainsi, la première exigence majeure pour la prise en charge de DSU est que l'appareil prenne en charge partitions dynamiques. Les partitions dynamiques impliquent une partition réelle de stockage divisée en partitions logiques redimensionnables telles que le système, le fournisseur, l'odm, l'oem, le produit, etc. Lors de l'installation d'un GSI, de l'espace est réservé pour les nouvelles partitions système et de données utilisateur en prenant les blocs inutilisés de la partition de données utilisateur existante. Étant donné que la taille de ces nouvelles partitions peut atteindre plusieurs gigaoctets, la prise en charge de DSU n'a de sens qu'avec des partitions logiques. partitions, sinon un périphérique devrait réserver en permanence plusieurs gigaoctets d'espace de stockage pour GSI installations.

D'autres exigences incluent un disque virtuel, qui décide s'il faut démarrer sur la récupération, le système ou une partition logique, et une partition de métadonnées pour stocker les métadonnées du GSI. En général, les éléments constitutifs de la prise en charge de DSU sont les exigences de lancement d'Android Q., selon Iliyan Malchev, responsable du projet Treble. Nous ne sommes pas sûrs si tout ce qui est nécessaire pour prendre en charge DSU est une exigence de lancement d'Android Q, mais nous pouvons présumer que la plupart, sinon tous les appareils se lancent avec Android Q peut prennent en charge le DSU même si Google ne l'exige pas actuellement. Jusqu'à présent, seuls les Pixel 3, Pixel 3 XL, Pixel 3a et Pixel 3a XL disposent de partitions dynamiques, et parmi ces appareils, seuls les Pixel 3 et Pixel 3 XL prennent en charge le DSU dans Android Q bêta 4. Bien que la prise en charge de DSU ne soit pas requise, Google espère que les OEM activeront quand même cette fonctionnalité, car elle simplifie les tests sécurisés de compatibilité Treble. Par exemple, un ingénieur logiciel OEM peut mettre un GSI sur une carte SD afin qu'ils puissent démarrer rapidement sur plusieurs appareils pour tester la compatibilité Treble.

Sécurité pour les mises à jour dynamiques du système

Étant donné que DSU introduit essentiellement un deuxième système d'exploitation dans le mix, Google doit s'assurer que cette nouvelle installation ne peut pas être falsifiée pour briser l'intégrité de l'appareil. Ainsi, le les mêmes protections de sécurité de base pour l'installation d'origine sont en place pour l'installation de GSI: Politiques de démarrage vérifié Android et SELinux. De plus, seules les applications dotées de la signature INSTALL_DYNAMIC_SYSTEM|autorisation privilégiée peuvent lancer un GSI. l'installation, tandis que les applications avec l'autorisation de signature MANAGE_DYNAMIC_SYSTEM peuvent activer/désactiver ou effacer un GSI installation. Cela signifie que seules les applications fiables au niveau du système peuvent fonctionner avec DSU.

Pour garantir la protection des données utilisateur d'origine, Google a ajouté un mécanisme de protection supplémentaire dans Android Q. Appelé "Point de contrôle", la fonctionnalité protège contre la destruction des données utilisateur en restaurant les partitions soumises à des points de contrôle à leur état d'origine. Cependant, les points de contrôle ne sont pas seulement utiles pour le DSU. Ils sont également utilisés pour protéger contre les erreurs Ligne principale du projet Module APEX et UN B Mises à jour OTA. (Appareils avec partitions A/B disposent déjà d'une protection contre la restauration, mais ces restaurations nécessitent des réinitialisations des données d'usine, contrairement aux points de contrôle des données utilisateur.)

Installer un GSI

Si votre appareil prend en charge DSU comme la série Pixel 3, il est alors facile d'installer un GSI. Vous devez d’abord vous assurer que l’indicateur de fonctionnalité Dynamic System est activé de l’une des deux manières suivantes :

1. Si vous utilisez une version userdebug, activez l'indicateur settings_dynamic_android dans Paramètres > Système > Options du développeur > Indicateurs de fonctionnalités.
2. Si vous utilisez une version utilisateur, exécutez la commande adb shell suivante :

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Ensuite, téléchargez la dernière version bêta d'Android Q GSI à partir de Google ou le fabricant OEM de votre appareil. (DSU permet uniquement d'installer des GSI signés par Google ou un OEM.) Une fois téléchargé, utilisez simg2img pour convertir l'image clairsemée en image brute. Utilisez gzip pour compresser l'image brute, puis copiez l'archive résultante vers un emplacement sur le disque dur de votre appareil. stockage externe (par exemple /data/media/0/Download) ou un véritable support de stockage externe (comme une carte SD physique carte). Enfin, lancez l'application DynamicSystemInstallationService avec la bonne intention pour commencer l'installation :

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

Une fois que vous aurez cliqué sur redémarrer, vous démarrerez dans le GSI. La convivialité de l'appareil dans le GSI dépend de la manière dont le fabricant OEM de votre appareil a implémenté Treble (ou plutôt du peu de violation des Treble). compatibilité.) Certains appareils fonctionneront mieux avec les GSI que d'autres, mais en général, ne vous attendez pas à utiliser cette installation quotidiennement. conducteur. Vous êtes censé tester votre application, puis sortir en redémarrant. Si vous souhaitez rester dans l'installation GSI pour des tests plus approfondis, vous pouvez utiliser le gsi_tool commande shell.

Les instructions d'installation complètes de GSI pour DSU peuvent être trouvées ici. Des bogues peuvent être déposés sur le Suivi des problèmes Google,Reddit, ou Débordement de pile.

La raison des mises à jour dynamiques du système

Lorsque j'ai parlé à Iliyan Malchev sur Google I/O, il a réitéré ce que Hung-ying Tyan de l'équipe Treble avait dit à propos de l'accès anticipé au GSI à Sommet des développeurs Android de novembre. Google a créé un DSU pour solliciter les commentaires d’un public aussi large que possible. L'objectif est d'améliorer la qualité du GSI, ce qui à son tour améliore la qualité de la future version d'Android puisqu'un GSI est la forme la plus pure d'Android. Google est actuellement la seule entreprise à tester la compatibilité GSI de la prochaine version (par exemple, le fonctionnement de l'image système Android Q sur Android P). mise en œuvre du fournisseur), mais à mesure que de plus en plus de personnes flashent les GSI et donnent leur avis, les OEM peuvent corriger les violations de compatibilité Treble afin que les GSI fonctionnent encore mieux dans le avenir. Iliyan affirme que les constructeurs OEM et les fournisseurs comme Qualcomm sont très intéressés par la réutilisation des images des fournisseurs de la version précédente d'Android avec l'image système de la prochaine version. Des initiatives telles que DSU aident Google et les constructeurs OEM à combler le manque de couverture des tests automatisés tels que VTS et CTS-on-GSI. Ainsi, Google demande à davantage de bêta-testeurs de donner leur avis sur la prochaine version d'Android, tout en étant informé des violations de compatibilité Treble afin que les OEM puissent améliorer leur travail.

L'ajout de mises à jour dynamiques du système dans Android Q est le bienvenu, mais ce ne sera pas la solution à double démarrage que certains d'entre vous espèrent. Comme mentionné précédemment, seules les images système signées par Google ou les OEM peuvent être installées. Lorsque j'ai interrogé Iliyan sur la possibilité d'étendre DSU pour prendre en charge un écosystème d'Android alternatif systèmes, il a déclaré qu'il était techniquement possible de le faire car le DSU est simplement un canal pour fournir le système images. N’importe quel OEM peut l’utiliser comme il le souhaite tant que le résultat final est compatible avec Android. Google n'a pas créé d'alternative au système OTA ici, et DSU n'est pas destiné à être utilisé pour un véritable double démarrage. Quoi qu'il en soit, le travail effectué par Google sur Treble rend Android plus modulaire. Je ne serais donc pas surpris si le double démarrage natif devenait réalité à l'avenir.