Vous avez peut-être déjà entendu parler des mises à jour transparentes. Cela implique quelque chose appelé « partitions A/B ». De quoi s’agit-il et comment cela affecte-t-il le développement personnalisé sur XDA ?
Lorsque Android Nougat est sorti, nous en avons parlé toutes sortes de nouvelles fonctionnalités. Nous avons obtenu une interface utilisateur récemment mise à jour pour les débutants, ainsi que des fonctionnalités multi-fenêtres tant attendues et la prise en charge de l'API Vulkan Graphics. Mais un ajout caché sous le capot a survolé la tête de la plupart des utilisateurs. Android Nougat a introduit les « mises à jour transparentes » sur les appareils prenant en charge les partitions A/B. La grande majorité des appareils Android existants (à l'exception des nouveaux Google Pixel et Google Pixel XL) ne disposaient pas de partitions A/B à l'époque et ne pouvaient donc pas profiter de mises à jour transparentes. Le principe de base de cette fonctionnalité est que le périphérique dispose d'un deuxième ensemble de partitions système, de démarrage, de fournisseur et d'autres partitions importantes, et lorsque vous obtenez un OTA mise à jour, la mise à jour s'effectue en arrière-plan pendant que le deuxième ensemble de partitions est corrigé, ce qui vous permet de redémarrer de manière transparente dans une version logicielle mise à jour. Si une mise à jour échoue, vous serez renvoyé à une version fonctionnelle, ce qui signifie que les entreprises auront moins de problèmes à gérer et que les consommateurs seront mieux protégés.
La prise en charge des mises à jour transparentes n'est pas une exigence pour tout nouvel appareil Android, contrairement à Project Treble. En tant que tel, la grande majorité des nouveaux appareils Android ne prennent pas en charge cette fonctionnalité. Nous avons conservé jusqu'à présent une liste de tous les appareils pris en charge, et il est clair que cette fonctionnalité n'est pas largement prise en charge. C'est dommage car les partitions A/B apportent de nombreux avantages aussi bien aux utilisateurs réguliers qu'aux utilisateurs expérimentés. Cependant, cette fonctionnalité a une mauvaise réputation au sein de la communauté des passionnés, car elle est perçue comme rendant le développement Android et le flashage de modifications personnalisées plus difficiles. Ce n'est pas réellement le cas, nous voulions donc démystifier les mises à jour transparentes et expliquer comment les partitions A/B affectent le développement personnalisé sur XDA.
Un grand merci au membre senior XDA npjohnson, un Contributeur de LineageOS et responsable du Motorola Moto Z2 Force, qui nous a aidé à vérifier cet article.
Partitions sur un appareil Android
Une partition est simplement une section discrète de la mémoire interne du téléphone où les données sont conservées. Le type de données conservées sur chaque partition dépend du matériel, du système d'exploitation et de nombreux autres facteurs. Le chargeur de démarrage en aura un, le système (OS Android) en aura un, les données utilisateur en auront un... et ainsi de suite. Lorsque vous voyez des gens parler de "/system" et "/cache", ils font référence aux noms donnés à ces partitions. Le OnePlus 6, par exemple, a 72 partitions. Cela semble beaucoup, mais le OnePlus 6 est l'un des appareils prenant en charge les mises à jour transparentes, ce qui signifie que bon nombre de ces partitions sont simplement des doublons les unes des autres.
Sortie partielle des partitions sur le OnePlus 6. Certaines partitions A/B sont soulignées à des fins de démonstration.
Il existe de nombreuses partitions sur un appareil dont vous n'aurez jamais à vous soucier en tant qu'utilisateur. Beaucoup de ces partitions ne sont jamais modifiées lors du flashage de ROM personnalisées, de noyaux, de récupérations ou de modifications comme Magisk ou Xposed. Beaucoup de ces partitions seront soit inutilisées pour nos besoins, soit trop dangereuses pour être touchées à moins que vous ne sachiez ce que vous faites (XLOADER et OEMINFO sur Huawei/Honor appareils viennent à l'esprit.) Pour la grande majorité des utilisateurs d'Android, les partitions que nous traitons principalement sont le système, le démarrage, la récupération, les données utilisateur et plus récemment le fournisseur et vbmeta. Voici une brève explication du but de chaque partition :
- système - contient le système d'exploitation Android, les bibliothèques système, les applications système et d'autres supports système tels que les animations de démarrage, les fonds d'écran, les sonneries, etc.
- boot - contient le noyau, le disque virtuel et, sur les périphériques A/B, également la récupération
- recovery - contient la récupération, où TWRP est le plus souvent flashé sur les appareils A uniquement (les appareils A/B n'ont pas de partition de récupération dédiée)
- userdata - contient toutes vos données d'application, de système et de stockage interne
- fournisseur - contient les HAL spécifiques à la plate-forme et à l'appareil, les fichiers nécessaires au système d'exploitation Android pour communiquer avec le matériel sous-jacent
- vbmeta - la partition pour Android Verified Boot 2.0 qui vérifie l'intégrité du processus de démarrage
Les fabricants d'appareils OEM peuvent modifier leurs schémas de partition pour utiliser la disposition de leur choix. Par exemple, Huawei divise la partition de démarrage en ramdisk_recovery et kernel. Il existe également de nombreuses partitions supplémentaires pouvant contenir d'autres applications système telles que Cust, Product et OEM, et bien que ceux-ci peuvent être modifiés en toute sécurité, il n'est généralement pas recommandé si vous souhaitez faciliter le retour en stock. Alors, où les partitions A/B jouent-elles un rôle ?
Le schéma de partition A/B
Comment fonctionnent les mises à jour sur les appareils dotés de mises à jour transparentes
L'image très simple que j'ai réalisée ci-dessous illustre comment une mise à jour est gérée sur un appareil prenant en charge la partition A/B. La partition illustrée est la partition système, bien que d'autres partitions telles que le démarrage et le fournisseur puissent également être mises à jour avec n'importe quelle mise à jour OTA donnée provenant d'un OEM. Ce processus de mise à jour se produit non seulement avec les mises à jour majeures de la version Android, mais également avec les mises à jour des correctifs de sécurité.
- Nous commençons avec deux partitions système, system_a et system_b, toutes deux sur la même version d'Android.
- En supposant que system_a est actif, la mise à jour OTA corrigera system_b, la partition inactive, en arrière-plan.
- system_a est défini sur inactif et system_b devient alors actif une fois que l'utilisateur redémarre.
- La partition désormais inactive, system_a, sera mise à jour lors du prochain déploiement de la mise à jour OTA.
Quels sont les avantages de ce processus de mise à jour ?
- Si une mise à jour échoue, l'appareil reviendra à la version de travail sur l'autre emplacement.
- Vos données restent parfaitement intactes, même si la mise à jour échoue, car il n'y a qu'une seule partition (userdata) qui héberge vos données.
- Streaming de mise à jour: si votre partition de données est pleine, la mise à jour peut être téléchargée et diffusée sur l'emplacement inactif. C'est une fonctionnalité plutôt intéressante qui signifie que vous n'avez pas à gaspiller de stockage temporaire pour vos mises à jour. C'est pourquoi il n'y a pas de partition de cache sur les périphériques A/B car ils ne sont plus nécessaires.
Quel impact le schéma de partitionnement A/B a-t-il sur le stockage d'un appareil ?
Le fait que les mises à jour transparentes entraînent un grand nombre de partitions dupliquées signifie-t-il que vous perdez beaucoup d'espace de stockage? Pas du tout. Google affirme que les appareils prenant en charge les mises à jour transparentes ne devraient perdre que quelques centaines de mégaoctets grâce à la suppression des partitions /cache et /recovery. La suppression des deux équilibre le coût de l’ajout d’un deuxième ensemble de partitions. Selon Google, l'image système A/B du Pixel fait la moitié de la taille de l'image système A uniquement. La majeure partie de l'utilisation du stockage supplémentaire provient en réalité de l'ajout d'une deuxième partition du fournisseur. Cela est logique car la partition du fournisseur héberge tous les binaires propriétaires utilisés par les OEM (qui font partie du Project Treble), elle devrait donc prendre un peu de place. Bien que Google ne recommande pas d'avoir un partitionnement A/B sur les appareils dotés de 4 Go de stockage (car il représente près de 10 % du stockage total disponible), ils le recommandent sur les appareils dotés de 8 Go et plus.
Voici une répartition de l'espace de stockage utilisé sur un Google Pixel avec et sans partitions A/B.
Tailles des partitions |
UN B |
A-seulement |
---|---|---|
Chargeur de démarrage |
50 Mo*2 |
50 Mo |
Botte |
32 Mo*2 |
32 Mo |
Récupération |
32 Mo |
|
Cache |
100 Mo |
|
Radio |
70 Mo*2 |
70 Mo |
Fournisseur |
300 Mo*2 |
300 Mo |
Système |
2048 Mo*2 |
4096 Mo |
Total |
5000 Mo |
4680 Mo |
Qu'est-il arrivé à la partition de récupération ?
Le noyau Linux sous-jacent sur les appareils Android permet à Android de reconnaître et d'utiliser correctement le matériel sur un smartphone. Sur les appareils Android A uniquement, vous disposez généralement de deux versions du noyau: l'une est contenue dans la partition de récupération tandis que l'autre se trouve dans la partition de démarrage. Sur les appareils A/B prenant en charge les mises à jour transparentes, la récupération se trouve désormais dans l'image de démarrage avec le noyau. La fonction principale de la récupération était d'installer les mises à jour, mais comme cela est géré par le système lui-même (mise à jour_moteur) pendant le démarrage d'Android, la partition de récupération dédiée n'est plus nécessaire.
Pour installer une récupération personnalisée sur les appareils A/B, nous devons donc modifier la partition de démarrage et remplacer la récupération de stock par la nôtre. C'est pourquoi pour installer TWRP, vous devez d'abord utiliser une commande fastboot pour démarrer une image de démarrage personnalisée et alors flashez le script d'installation TWRP, car fastboot ne peut pas corriger les partitions, il suffit de les flasher entièrement. Vous pouvez techniquement pré-patcher votre image de démarrage existante avec TWRP, puis la flasher via fastboot, mais cela pose plus de problèmes que cela n'en vaut la peine. Le script d'installation de TWRP corrige les partitions boot_a et boot_b pour installer TWRP.
Fait amusant: le moteur de mise à jour Android qui gère les mises à jour transparentes est essentiellement extrait directement de Chrome OS. Seulement récemment Les chaînes contenant "Chrome OS" ont-elles été supprimées du journal de update_engine pour éviter toute confusion pour quiconque vérifie logcat.
Mon smartphone Android prend-il en charge les partitions A/B pour des mises à jour transparentes ?
Pendant que nous conserver une liste de tous les appareils qui le soutiennent, vous pouvez également facilement vérifier vous-même.
Comment les mises à jour transparentes affectent-elles le développement personnalisé?
Perception des utilisateurs des partitions A/B
Considérées comme un obstacle au développement de logiciels personnalisés par de nombreux utilisateurs, les mises à jour transparentes sont en réalité une aubaine pour les développeurs. La raison pour laquelle les appareils A/B sont perçus comme ayant un faible support de développement tient au prix des premiers appareils A/B. Après tout, les appareils Google Pixel ont été parmi les premiers à prendre en charge des mises à jour transparentes et, comparés aux smartphones Nexus d'antan, ils étaient relativement chers. De plus, grâce à la myriade d'améliorations apportées par Google au système d'exploitation Android, qui a créé des ROM personnalisées et modifications moins populaires sur les appareils Google, les smartphones Google Pixel n'ont pas décollé sur nos forums aussi bien que les Nexus smartphones. Une combinaison de facteurs externes a entraîné une diminution du développement personnalisé sur les smartphones Google Pixel, bien que la plupart des utilisateurs aient plutôt choisi de blâmer la prise en charge des partitions A/B. Comparez la disponibilité du développement personnalisé sur des appareils comme le Google Pixel avec des appareils comme le Xiaomi Mi A1 sur nos forums.
De plus, le manque de compréhension de la façon dont les partitions A/B ont modifié la façon dont les utilisateurs doivent installer des ROM, des noyaux, des récupérations et des modifications personnalisés ont rendu la prise en charge des partitions A/B impopulaire. La récupération se trouvant désormais à l'intérieur de l'image de démarrage, le fait de flasher des modifications dans le mauvais ordre, telles que Magisk ou Xposed, peut provoquer des conflits et conduire à une boucle de démarrage. L'ordre dans lequel vous flashez ces mods peut être important, bien que dans le cas de ROM personnalisées, vous ne devriez pas avoir à vous soucier de l'emplacement vers lequel vous flashez. Contrairement à la croyance populaire, le script d'installation de la plupart des ROM personnalisées ne flashe pas sur les deux emplacements. Vous n’avez généralement pas à vous en soucier car vous ne devriez pas avoir besoin d’échanger les emplacements manuellement.
Comment les développeurs visualisent les partitions A/B
Lors de la création d'une ROM, les développeurs peuvent utiliser les deux partitions pour tester des versions distinctes. Si cela ne fonctionne pas, ils peuvent simplement revenir à la partition de travail et reconstruire leur ROM. Les développeurs peuvent également tester les régressions en installant simplement une mise à jour, en changeant de partition active et en comparant les deux sans avoir à effacer les données. Voici comment l'équipe LineageOS considère la prise en charge des partitions A/B :
"De nombreux membres de la communauté Android ont critiqué A/B comme étant "difficile à prendre en charge" et "peu convivial pour les développeurs", alors qu'en fait, il est correctement mis en œuvre. plus facile à soutenir et tout aussi convivial pour les développeurs." - jrizzoli, Journal des modifications de LineageOS 19
La difficulté initiale du support A/B pour les développeurs est venue de la modification de leurs outils existants pour prendre en charge ces appareils. Le développeur de Magisk, topjohnwu, a ajouté le support officiel du Google Pixel un an après sa création. sorti - non pas parce que c'était difficile, mais plutôt parce qu'il lui a fallu un an pour obtenir l'appareil. travailler sur. Prise en charge de TWRP est venu assez vite sur les appareils A/B après que le développeur principal, Dees_Troy, s'y soit essayé. LignéeOS 15.1 prend désormais en charge Appareils A/B après que les volontaires aient trouvé le temps de corriger leur script addon.d.
Comment mettre à jour un périphérique A/B doté d'une récupération personnalisée, d'un noyau ou d'autres mods
ROM personnalisées
Faire clignoter les mises à jour sur un appareil doté d'une ROM personnalisée signifie que vous devrez également vous méfier de l'emplacement sur lequel vous flashez, n'est-ce pas? Pas assez. TWRP gérera en fait une grande partie de cela pour vous, et il utilise par défaut l'emplacement inactif pour flasher une ROM personnalisée. Si votre emplacement actif est A et que vous flashez une ROM personnalisée, vous flashez en fait sur l'emplacement B. Lorsque vous redémarrez, l'emplacement actif est désormais B. Les développeurs peuvent modifier le script d'installation et flasher sur les deux emplacements pour faciliter la tâche de l'utilisateur final, bien que la plupart des scripts d'installation de ROM personnalisés ne flashent actuellement que sur un seul emplacement. Enfin, les ROM personnalisées peuvent implémenter un programme de mise à jour A/B dans leur ROM afin que les utilisateurs n'aient même pas besoin de s'en soucier. Mises à jour clignotantes manuellement: la dernière version de LineageOS 15.1 comprend un outil Lineage Updater et un membre senior XDA États-Unis-RedDragon fait un programme de mise à jour A/B générique que d'autres développeurs peuvent utiliser.
ROM d'origine
Mais n'est-ce pas problématique si votre appareil exécute la ROM d'origine avec diverses modifications et que vous souhaitez installer une mise à jour sans perdre tous ces mods? Cela peut être le cas si vous ne connaissez pas les bonnes étapes pour installer une mise à jour. Sur le OnePlus 6, par exemple, vous ne pouvez pas flasher un OTA incrémentiel sur votre appareil modifié, car l'OTA incrémentiel tentera de corriger votre image de démarrage modifiée. Ainsi, vous vous retrouverez probablement avec une boucle de démarrage, et c'est pourquoi vous devez flasher la mise à jour complète de la ROM pour écraser complètement votre image de démarrage modifiée. Voici les étapes générales à suivre pour installer une mise à jour OxygenOS sur votre OnePlus 6 tout en conservant TWRP, Magisk et éventuellement un noyau personnalisé.
- Téléchargé le dernier ROM complète fermeture éclair
- Flasher le zip complet de la ROM lors de la récupération
- (Facultatif) Noyau personnalisé Flash
- Installateur Flash TWRP
- Redémarrez directement vers la récupération
- Magisk Flash
Sur les appareils Google Pixel, vous pouvez flasher l'image d'usine sans effacer les données, puis démarrez TWRP, installez TWRP via le script d'installation, puis installez Magisk.
Extraction d'une mise à jour pour flasher des images de partition individuelles
Les fichiers de mise à jour pour de nombreux appareils A/B sont un peu différents de ceux des appareils A uniquement. Il ne s'agit plus simplement d'un fichier zip contenant de nombreuses images (à l'exclusion des images d'usine de Google et Razer), mais plutôt d'un fichier payload.bin. Vous pouvez extraire ce fichier et flasher chaque partie manuellement, mais cela nécessite un outil spécial pour ce faire. Si vous souhaitez savoir comment procéder sur le OnePlus 6, le Xiaomi Mi A1 et de nombreux autres appareils A/B, continuez à lire.
Configuration pour extraire payload.bin
- Assurez-vous d'avoir Python 3.6 installée.
- Téléchargez payload_dumper.py et update_metadata_pb2.py ici.
- Extrayez votre zip OTA et placez payload.bin dans le même dossier que ces fichiers.
- Ouvrez PowerShell, l'invite de commande ou le terminal en fonction de votre système d'exploitation.
- Entrez la commande suivante:
python -m pip install protobuf
- Lorsque c'est fini, entrez cette commande:
python payload_dumper.py payload.bin
- Cela commencera à extraire les images du fichier payload.bin dans le dossier actuel dans lequel vous vous trouvez.
Vous pouvez désormais flasher chacune de ces images séparément via fastboot si vous le souhaitez. La section suivante vous montre comment procéder.
Utilisation de Fastboot pour flasher des images sur un appareil prenant en charge les mises à jour transparentes
Il existe un certain nombre de commandes exclusives aux périphériques du système de partition A/B. Vous pouvez modifier votre emplacement actif et flasher sur des emplacements spécifiques. Si vous avez un Project Treble-appareil compatible et je veux apprendre à Images système génériques Flash, vous devriez être familier avec ces commandes. Jetez un œil au tableau ci-dessous.
Commandes de démarrage rapide |
Commande |
---|---|
Obtenir l'emplacement actif actuel |
fastboot getvar tout | grep "current-slot" Si vous êtes sur un PC Windows, la commande "grep" ne fonctionnera pas. |
Définir un autre emplacement comme actif |
fastboot set_active autre |
Définir l'emplacement spécifié comme actif |
fastboot set_active $ORfastboot --set-active=_$slotoù $ est a ou b |
Image Flash sur la partition spécifiée dans l'emplacement actuel |
partition flash fastboot partition.img |
Image Flash sur la partition spécifiée dans l'emplacement spécifié |
partition flash fastboot_a partition.imgpartition flash fastboot_b partition.img |
(Remarque: sur les appareils A/B, vous pouvez soit spécifier une partition dans un emplacement particulier sur laquelle flasher, soit omettre le suffixe de l'emplacement et elle clignotera sur l'emplacement actif actuel. Par exemple, vous pouvez remplacer « partition » dans la commande flash par « system », « system_a » ou « system_b ».)
Un mot sur Project Treble et les mises à jour transparentes
Une idée fausse courante est que la prise en charge de Project Treble et la prise en charge de la partition A/B sont liées l'une à l'autre, mais ce n'est pas réellement le cas. Avoir l’un n’implique pas l’autre. Le Motorola Moto Z2 Force utilise un schéma de partitionnement A/B mais ne prend pas en charge Treble. D'un autre côté, le Honor 9 Lite prend en charge Project Treble, mais il s'agit d'un appareil uniquement A.
Foire aux questions/Résumé
-
Quels sont les avantages du partitionnement A/B ?
- Le partitionnement A/B vous permet de mettre à jour votre smartphone Android tout en l'utilisant, en redémarrant simplement lorsque vous êtes prêt à démarrer dans la nouvelle version. Il agit également comme une protection contre les briques: si la mise à jour échoue, vous reviendrez à l'installation fonctionnelle.
-
Le partitionnement A/B entrave-t-il le développement ?
- Même s’il a fallu un peu de temps aux développeurs pour s’adapter, la réponse est quasiment non. En fait, cela peut aider les développeurs car ils peuvent effectuer un double démarrage de leur ROM personnalisée avec l'ancienne version et une nouvelle version de test pour vérifier les régressions.
-
Comment les partitions A/B affectent-elles les mods tels que les noyaux personnalisés, Magisk ou Xposed ?
- Vous devez être prudent lors de leur installation, mais il n’y a actuellement aucun problème. Magisk prend officiellement en charge les appareils avec des mises à jour transparentes, et tant que vous flashez les éléments dans le bon ordre, vous ne devriez avoir aucun problème. Assurez-vous de flasher le noyau personnalisé avant de flasher vos autres mods, et vous devriez être prêt à partir.
-
Puis-je flasher deux ROM différentes sur chaque partition et double démarrage ?
- En théorie, oui. Des problèmes surviennent cependant à cause de la partition de données partagée, ce n'est donc pas recommandé.
-
Le fait d'avoir un schéma de partition A/B signifie-t-il que j'ai réduit le stockage ?
- Non! Google affirme que les appareils prenant en charge les mises à jour transparentes ne sacrifient que quelques centaines de mégaoctets de stockage pour les prendre en charge. Les avantages dépassent ce coût.
-
Mon appareil prend en charge les partitions A/B, cela signifie-t-il que je peux utiliser une image système générique Project Treble ?
- Pas nécessairement. Le support Project Treble et A/B n’est pas lié. Le Motorola Moto Z2 Force ne prend pas en charge Project Treble, mais il prend en charge le schéma de partition A/B.
-
Mon appareil prend en charge Project Treble, cela signifie-t-il que j'ai un schéma de partition A/B ?
- Ce n'est pas toujours le cas. Le Honor 9 Lite en est un excellent exemple car il prend en charge Project Treble mais ne dispose pas de schéma de partition A/B.
-
Pourquoi dois-je d'abord démarrer TWRP avec fastboot, puis le flasher ?
- Cela est dû au fonctionnement de Fastboot et au fait que la partition de récupération n'existe plus. La récupération est placée à l'intérieur de la partition de démarrage, nous devons donc modifier à la fois boot_a et boot_b. Vous ne pouvez pas patcher une partition dans Fastboot, seulement flasher dessus. Vous pouvez, en théorie, créer une image de démarrage pré-patchée, puis la flasher à la place.
-
Y a-t-il des dangers avec les partitions A/B? Comment la protection contre la restauration affecte-t-elle les choses ?
- Google a fait de son mieux pour que cela ne pose pas de problème, mais dans le cas du Motorola Moto Z2 Force, il y a eu des cas connus où un appareil a réactivé l'ancien emplacement après la mise à niveau vers Android Oréo. Cela signifiait que la protection contre la restauration était activée et que les propriétaires d'appareils ne pouvaient sauver leur smartphone qu'avec la récupération EDL. Google indique que la protection contre la restauration n'intervient qu'après le premier démarrage, de sorte que l'emplacement doit être pleinement fonctionnel après une mise à jour avant que vous ne puissiez plus rétrograder.