Présentation des tests A/B virtuels

Android dispose de deux mécanismes de mise à jour: les mises à jour A/B (sans interruption) et les mises à jour non A/B. Pour réduire la complexité du code et améliorer le processus de mise à jour, dans Android 11, deux mécanismes sont unifiés via des tests A/B virtuels pour offrir des mises à jour fluides des appareils avec un coût de stockage réduit. Android 12 propose la compression virtuelle A/B pour compresser les partitions créées à partir d'instantanés. Sur Android 11 et Android 12, les éléments suivants appliquer:

  • Les mises à jour A/B virtuelles sont fluides, tout comme les mises à jour A/B. Mises à jour A/B virtuelles réduire la durée pendant laquelle un appareil est hors connexion et inutilisable.
  • Les mises à jour A/B virtuelles peuvent faire l'objet d'un rollback. Si le nouvel OS ne démarre pas, d'appareils revient automatiquement à la version précédente.
  • Les mises à jour A/B virtuelles utilisent un minimum d'espace supplémentaire, car elles ne dupliquent que les et les partitions utilisées par le bootloader. Les autres partitions pouvant être mises à jour sont instantanésted.

Contexte et terminologie

Cette section définit la terminologie et décrit la technologie sous-jacente des tests A/B virtuels.

Outil de mappage de l'appareil

Device-mapper est une couche de blocs virtuels Linux souvent utilisée dans Android. Avec partitions dynamiques, des partitions telles que /system est une pile d'appareils multicouches:

  • En bas de la pile se trouve la partition super physique (par exemple, /dev/block/by-name/super).
  • Au milieu se trouve un appareil dm-linear, spécifiant les blocs dans le à partir de la partition donnée. Cela s'affiche sous la forme /dev/block/mapper/system_[a|b] sur un appareil A/B, ou /dev/block/mapper/system sur un appareil non-A/B.
  • En haut se trouve un appareil dm-verity, créé pour les partitions validées. Cet appareil vérifie que les blocages sur l'appareil dm-linear sont signés correctement. Il s'affiche sous la forme /dev/block/mapper/system-verity et correspond à la source du point d'installation /system.

La figure 1 montre à quoi ressemble la pile sous le point d'installation /system.

Empiler des partitions en dessous système

Figure 1 : Pile sous le point d'installation /system

dm-instantané

L'A/B virtuelle s'appuie sur dm-snapshot, un module de mappage d'appareils pour créer un instantané l'état d'un périphérique de stockage. Lorsque vous utilisez dm-snapshot, quatre appareils sont présents dans lire:

  • L'appareil de base est celui qui crée des instantanés. Sur cette page, le tag l'appareil est toujours une partition dynamique, telle que le système ou le fournisseur.
  • L'appareil copy-on-write (COW), qui permet de consigner les modifications apportées à l'appareil de base. Il Il peut s'agir de n'importe quelle taille, mais celle-ci doit être suffisamment grande pour pouvoir s'adapter à toutes les modifications de base.
  • L'appareil snapshot est créé à l'aide de la cible snapshot. Écrit dans le d'instantanés sont écrits sur le périphérique COW. Lit à partir de l'instantané l'appareil de base ou l'appareil COW, selon si les données consultées ont été modifiées par l'instantané.
  • L'appareil d'origine est créé à l'aide de la cible snapshot-origin. Lit jusqu'à l’appareil d’origine lit directement à partir de l’appareil de base. Écrit dans l'origine appareil écrit directement sur le périphérique de base, mais les données d'origine sont sauvegardées en écrivant sur l'appareil COW.

Mappage d'appareils pour dm-snapshot

Figure 2. Mappage d'appareil pour dm-snapshot

Instantanés compressés

Sous Android 12 et versions ultérieures, car les exigences d'espace sur la partition /data peut être élevée, vous pouvez activer des instantanés compressés dans votre pour répondre aux exigences d'espace plus élevées de la partition /data.

Les instantanés virtuels compressés A/B sont basés sur les composants suivants. disponibles sous Android 12 ou version ultérieure:

  • dm-user, un module de noyau semblable à FUSE qui permet un espace utilisateur pour implémenter des appareils de stockage en mode bloc.
  • snapuserd, un daemon d'espace utilisateur permettant d'implémenter un nouvel instantané .

Ces composants permettent la compression. Les autres modifications nécessaires apportées à mettre en œuvre les fonctionnalités d'instantanés compressés sont présentées dans les sections suivantes: Format COW pour les instantanés compressés dm-user et Snapuserd.

Format COW pour les instantanés compressés

Sous Android 12 et versions ultérieures, les instantanés compressés utilisent un COW. Semblable au format intégré du noyau utilisé pour les fichiers non compressés instantanés, le format COW des instantanés compressés comporte des sections alternées de métadonnées et de données. Les métadonnées du format d'origine sont autorisées uniquement pour remplace opérations: remplacez le bloc X dans l'image de base par le contenu du bloc Y dans l'instantané. Le format des instantanés compressés COW est plus expressif et prend en charge les opérations suivantes:

  • Texte: le bloc X de l'appareil de base doit être remplacé par le bloc Y dans l'appareil de base.
  • Remplacer: le bloc X de l'appareil de base doit être remplacé par le contenu du bloc Y dans l'instantané. Chacun de ces blocs est compressé au format GZ.
  • Zéro: le bloc X de l'appareil de base doit être remplacé par des zéros.
  • XOR: l'appareil COW stocke des octets compressés XOR entre les blocs X et bloc Y. (disponible sur Android 13 ou version ultérieure).

Les mises à jour OTA complètes ne comprennent que des opérations remplace et zéro. Incrémental Les mises à jour OTA peuvent également comporter des opérations de copie.

dm-user sous Android 12

Le module de noyau dm-user permet à userspace d'implémenter un bloc de mappage d'appareil. appareils. Une entrée de table dm-user crée un appareil divers sous /dev/dm-user/<control-name> Un processus userspace peut interroger l'appareil de recevoir les requêtes de lecture et d’écriture du noyau. Chaque demande est associée à afin que l'espace utilisateur puisse être rempli (pour une lecture) ou propager (pour une écriture).

Le module de noyau dm-user fournit au noyau une nouvelle interface visible par l'utilisateur qui ne fait pas partie du code base kernel.org en amont. D'ici là, Google se réserve le droit de modifier l'interface dm-user dans Android.

Snapuserd

Le composant d'espace utilisateur snapuserd de dm-user implémente Virtual A/B. la compression.

Dans la version non compressée de Virtual A/B (Android 11 et versions antérieures, ou sous Android 12 sans l'option d'instantané compressé), l'appareil COW est un fichier brut. Lorsque la compression est activée, la fonction COW en tant qu'appareil dm-user, qui est connecté à une instance du daemon snapuserd.

Le noyau n’utilise pas le nouveau format COW. Ainsi, le composant snapuserd convertit les requêtes entre le format Android COW et la couche intégrée du noyau format:

Le composant Snapuserd transfère les requêtes entre le format Android COW et le noyau intégré format

Figure 3. Organigramme de Snapuserd en tant que traducteur entre Android et Kernel Formats COW

Ces opérations de traduction et de décompression n'ont jamais lieu sur le disque. snapuserd intercepte les lectures et les écritures COW qui ont lieu dans le noyau, et les implémente à l'aide du format Android COW.

Compression XOR

Pour les appareils équipés d'Android 13 ou version ultérieure, La fonctionnalité de compression XOR, activée par défaut, active l'espace utilisateur pour stocker des octets compressés XOR entre les anciens et les nouveaux blocs. Quand ? seuls quelques octets d'un bloc sont modifiés lors d'une mise à jour A/B virtuelle, la fonction XOR le schéma de stockage par compression utilise moins d'espace que le schéma de stockage par défaut car les instantanés ne stockent pas la totalité des 4 000 octets. Cette réduction de la taille des instantanés est possible, car les données XOR contiennent de nombreux zéros et sont plus faciles à compresser pour bloquer des données. Sur les appareils Pixel, la compression XOR réduit la taille d'instantané de 25% à 40%.

Pour les appareils passant à Android 13 ou version ultérieure, XOR la compression doit être activée. Pour en savoir plus, consultez la section OUX la compression.

Processus virtuels de compression A/B

Cette section fournit des informations détaillées sur le processus de compression A/B virtuelle utilisé dans Android 13 et Android 12.

Lire les métadonnées (Android 12)

Les métadonnées sont créées par un daemon snapuserd. Les métadonnées sont principalement Mappage de deux ID, de 8 octets chacun, représentant les secteurs à fusionner. Dans dm-snapshot, elle s'appelle disk_exception.

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Une exception de disque est utilisée lorsqu'un ancien fragment de données est remplacé par un nouveau.

Un daemon snapuserd lit le fichier COW interne via la bibliothèque COW et construit les métadonnées de chacune des opérations COW présentes dans le fichier COW.

Les lectures de métadonnées sont lancées à partir de dm-snapshot dans le noyau lorsque l'appareil dm- snapshot est créé.

La figure ci-dessous présente un diagramme séquentiel du chemin d'E/S pour les métadonnées de construction.

Schéma séquentiel, chemin d&#39;E/S pour les métadonnées travaux

Figure 4. Flux séquentiel pour le chemin d'E/S dans la construction des métadonnées

Fusion (Android 12)

Une fois le processus de démarrage terminé, le moteur de mise à jour marque l'emplacement comme étant au démarrage. et lance la fusion en remplaçant la cible dm-snapshot par la Objectif : dm-snapshot-merge.

dm-snapshot parcourt les métadonnées et lance une E/S de fusion pour chaque disque une exception. Vous trouverez ci-dessous une présentation générale du chemin d'E/S de fusion.

Chemin d&#39;E/S de fusion

Figure 5. Présentation des chemins d'E/S de fusion

Si l'appareil est redémarré pendant le processus de fusion, la fusion reprend redémarrer, et que la fusion est terminée.

Couches de l'outil Mapper de l'appareil

Pour les appareils équipés d'Android 13 ou version ultérieure, Les processus de fusion d'instantanés et de fusion d'instantanés sont effectués dans le cadre d'une compression virtuelle A/B. par le composant d'espace utilisateur snapuserd. Pour les appareils passant à Android 13 ou version ultérieure, cette fonctionnalité doit être activée. Pour détails, consultez la section Espace utilisateur fusionner.

Vous trouverez ci-dessous la description du processus de compression A/B virtuelle:

  1. Le framework installe la partition /system sur un appareil dm-verity. qui est empilée sur un appareil dm-user. Cela signifie que chaque E/S du système de fichiers racine est acheminé vers dm-user.
  2. dm-user achemine les E/S vers le daemon snapuserd de l'espace utilisateur, qui gère la requête E/S.
  3. Une fois l'opération de fusion terminée, le framework réduit dm-verity sur en haut de dm-linear (system_base) et supprime dm-user.

Compression virtuelle A/B processus

Figure 6. Processus de compression A/B virtuelle

Le processus de fusion des instantanés peut être interrompu. Si l’appareil est redémarré pendant processus de fusion, il reprend après le redémarrage.

Transitions d'initialisation

Lors du démarrage avec des instantanés compressés, l'initialisation de la première étape doit démarrer snapuserd pour installer des partitions. Cela pose un problème: lorsque sepolicy est chargé et appliquées, snapuserd est placé dans le mauvais contexte et ses requêtes de lecture échouer, avec des refus selinux.

Pour résoudre ce problème, snapuserd effectue une transition en parallèle avec init, comme suit:

  1. La première étape init lance snapuserd à partir de ramdisk et enregistre une configuration un descripteur de fichier dans une variable d'environnement.
  2. La première étape, init, bascule le système de fichiers racine sur la partition système. exécute ensuite la copie système de init.
  3. La copie système de init lit la sepolicy combinée dans une chaîne.
  4. Init appelle mlock() sur toutes les pages utilisant ext4. Il désactive ensuite tous tables de mappage de l'appareil pour les appareils d'instantané et arrête snapuserd. Après cela il est interdit de lire les données des partitions, car cela entraîne un interblocage.
  5. Utiliser le descripteur ouvert pour la copie ramdisk de snapuserd, init redémarre le daemon avec le contexte selinux approprié. Tables des outils de mappage des appareils pour les appareils permettant d'utiliser des instantanés sont réactivés.
  6. Init appelle munlockall(). Vous pouvez effectuer à nouveau des E/S sans risque.

Utilisation de l'espace

Le tableau suivant compare l'utilisation de l'espace pour différentes agences de voyages en ligne. en utilisant les tailles d'OS et d'OTA du Pixel.

Impact sur la taille non-A/B A/B Tests A/B virtuels A/B virtuelle (compressé)
Image d'usine d'origine 4,5 Go de grande taille (3,8 Go d'image + 700 Mo réservés)1 9 Go de mémoire super (3,8 GHz + 700 Mo réservés, pour deux emplacements) 4,5 Go de grande taille (3,8 Go d'image + 700 Mo réservés) 4,5 Go de grande taille (3,8 Go d'image + 700 Mo réservés)
Autres partitions statiques /cache Aucune Aucun Aucune
Espace de stockage supplémentaire pendant la mise à jour OTA (espace renvoyé après application de l'OTA) 1,4 Go sur /data 0 3,8 Go2 sur /data 2,1 Go2 sur /data
Espace de stockage total requis pour appliquer la mise à jour OTA 5,9 Go3 (superposition et données) 9 Go (super) 8,3 Go3 (superposition et données) 6,6 Go3 (superposition et données)

1 Indique la mise en page supposée basée sur le mappage de pixels.

2Suppose que la nouvelle image système a la même taille que l'image d'origine.

3 L'espace requis est temporaire jusqu'au redémarrage.

Pour implémenter des tests A/B virtuels ou utiliser des fonctionnalités d'instantanés compressés, consultez Implémenter des tests A/B virtuels