Pour implémenter des tests A/B virtuels sur un nouvel appareil ou pour adapter un appareil déjà lancé, vous devez doit modifier le code spécifique à l'appareil.
Indicateurs de compilation
Les appareils qui utilisent des tests A/B virtuels doivent être configurés en tant que tests A/B appareil et doivent être lancés avec dynamique partitions.
Configurez les appareils lancés avec une fonctionnalité A/B virtuelle pour qu'ils héritent de la configuration configuration de base de l'appareil:
$(call inherit-product, \
$(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)
Les appareils lancés avec des tests A/B virtuels
n'ont besoin que de moitié moins de cartes pour
BOARD_SUPER_PARTITION_SIZE
, car les emplacements B ne sont plus en super. En d'autres termes,
La valeur de BOARD_SUPER_PARTITION_SIZE
doit être supérieure ou égale à
somme(taille des groupes de mise à jour) + frais généraux, qui, à leur tour, doivent être supérieurs
ou égal à somme(taille des partitions) + surcharge.
Pour Android 13 ou version ultérieure, pour activer la compression avec des tests A/B virtuels, héritent de la configuration de base suivante:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
$(SRC_TARGET_DIR)/product/virtual_ab_ota/android_t_baseline.mk)
Cela permet d'obtenir des instantanés de l'espace utilisateur avec des tests A/B virtuels tout en utilisant un nœud sans opération
de compression. Vous pouvez ensuite configurer la méthode de compression sur l'une des
méthodes compatibles, gz
, zstd
et lz4
.
PRODUCT_VIRTUAL_AB_COMPRESSION_METHOD := lz4
Pour Android 12, pour activer les instantanés compressés avec Virtual A/B, héritez de la configuration de base suivante:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
$(SRC_TARGET_DIR)/product/virtual_ab_ota/compression.mk)
Compression XOR
Pour les appareils passant à Android 13 ou version ultérieure, le
La fonctionnalité de compression XOR n'est pas
est activée par défaut. Pour activer la compression XOR, ajoutez le code suivant au fichier
.mk
.
PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.compression.xor.enabled=true
La compression XOR est activée par défaut pour les appareils qui héritent
android_t_baseline.mk
Fusion d'espaces utilisateur
Pour les appareils passant à Android 13 ou version ultérieure, le
processus de fusion des espaces utilisateur comme décrit dans Device-mapper
la superposition de couches n'est pas activée
par défaut. Pour activer la fusion de l'espace utilisateur, ajoutez la ligne suivante au fichier .mk
de l'appareil
:
PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.userspace.snapshots.enabled=true
La fusion des espaces utilisateur est activée par défaut sur les appareils lancés avec 13 et ultérieure.
Contrôle du démarrage HAL
Le contrôle de démarrage CARL fournit une interface permettant aux clients OTA de contrôler les emplacements de démarrage. Tests A/B virtuels nécessite une mise à niveau mineure du HAL de contrôle de démarrage, car des API supplémentaires sont nécessaires pour garantir que le bootloader est protégé pendant le flash ou le rétablissement de la configuration d'usine. Voir IBootControl.hal et types.hal pour obtenir la dernière version de la définition HAL.
// hardware/interfaces/boot/1.1/types.hal
enum MergeStatus : uint8_t {
NONE, UNKNOWN, SNAPSHOTTED, MERGING, CANCELLED };
// hardware/interfaces/boot/1.1/IBootControl.hal
package android.hardware.boot@1.1;
interface IBootControl extends @1.0::IBootControl {
setSnapshotMergeStatus(MergeStatus status)
generates (bool success);
getSnapshotMergeStatus()
generates (MergeStatus status);
}
// Recommended implementation
Return<bool> BootControl::setSnapshotMergeStatus(MergeStatus v) {
// Write value to persistent storage
// e.g. misc partition (using libbootloader_message)
// bootloader rejects wipe when status is SNAPSHOTTED
// or MERGING
}
Modifications fstab
L'intégrité de la partition de métadonnées
est essentielle au processus de démarrage,
en particulier juste après l'application
d'une mise à jour OTA. Ainsi, la partition
de métadonnées doit
vérifier avant que first_stage_init
ne l'installe. Pour ce faire, ajoutez le paramètre
check
fs_mgr à l'entrée de /metadata
. Vous trouverez ci-dessous
Exemple:
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount,check
Exigences du noyau
Pour activer la création d'instantanés, définissez CONFIG_DM_SNAPSHOT
sur true
.
Pour les appareils utilisant F2FS, incluez l'indicateur f2fs: export FS_NOCOW_FL vers user du correctif du noyau pour corriger l'épinglage de fichiers. Incluez les éléments f2fs: support alignés épinglés fichier du noyau.
L'A/B virtuelle repose sur des fonctionnalités ajoutées dans la version 4.3 du noyau: le overflow
bit d'état dans les cibles snapshot
et snapshot-merge
. Lancement pour tous les appareils
équipés d'Android 9 ou version ultérieure doivent déjà disposer de la version 4.4 ou ultérieure du noyau.
Pour activer les instantanés compressés, la version de noyau minimale compatible est 4.19.
Définissez CONFIG_DM_USER=m
ou CONFIG_DM_USER=y
. Si vous utilisez l'ancien (un module),
le module doit être chargé dans le ramdisk de première étape. Pour ce faire, vous pouvez
en ajoutant la ligne suivante au Makefile de l'appareil:
BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko
Retrofit sur les appareils passant à Android 11
Lors de la mise à niveau vers Android 11, les appareils lancés avec des partitions dynamiques peuvent des tests A/B virtuels si vous le souhaitez. Le processus de mise à jour est essentiellement le même que pour appareils lancés avec des tests A/B virtuels, à quelques différences mineures:
Emplacement des fichiers COW : pour les appareils de lancement, le client OTA utilise tout l'espace vide disponible dans la super-partition avant d'utiliser l'espace dans
/data
Pour les appareils rétrofit, il y a toujours suffisamment de place dans le afin que le fichier COW ne soit jamais créé sur/data
.Indicateurs de fonctionnalités lors de la compilation : pour les appareils qui adaptent les tests A/B virtuels,
PRODUCT_VIRTUAL_AB_OTA
etPRODUCT_VIRTUAL_AB_OTA_RETROFIT
sont tous les deux définis àtrue
, comme indiqué ci-dessous:(call inherit-product, \
(SRC_TARGET_DIR)/product/virtual_ab_ota_retrofit.mk)
Taille de la partition supérieure : les appareils équipés d'un A/B virtuel peuvent réduire
BOARD_SUPER_PARTITION_SIZE
en deux, car les emplacements B ne se trouvent pas dans le partition. Les appareils qui modernisent les tests A/B virtuels conservent l'ancienne super partition taille, doncBOARD_SUPER_PARTITION_SIZE
est supérieur ou égal à 2 * sum(taille des groupes de mise à jour) + sur site, qui à son tour est supérieur ou égal à 2 * somme(taille des partitions) + frais généraux.
Modifications apportées au bootloader
Lors de l'étape de fusion d'une mise à jour, /data
contient la seule instance entière de
OS Android. Une fois la migration lancée, les éléments system
, vendor
et
Les partitions product
sont incomplètes jusqu'à ce que la copie soit terminée. Si l'appareil est
rétablir la configuration d'usine au cours de ce processus, soit par le biais d'une restauration
des paramètres de l'appareil, l'appareil serait impossible à démarrer.
Avant d'effacer /data
, terminez la fusion lors de la récupération ou du rollback, en fonction
l'état de l'appareil:
- Si la nouvelle compilation a bien démarré auparavant, terminez la migration.
- Sinon, effectuez un rollback vers l'ancien emplacement:
<ph type="x-smartling-placeholder">
- </ph>
- Pour les partitions dynamiques, revenez à l'état précédent.
- Pour les partitions statiques, définissez l'emplacement actif sur l'ancien emplacement.
Le bootloader et fastbootd
peuvent effacer la partition /data
si le
l'appareil est déverrouillé. Bien que fastbootd
puisse forcer la migration à se terminer, le
le bootloader. Le bootloader ne sait pas si une fusion est effectuée ou non
la progression, ou quels blocs dans /data
constituent les partitions du système d'exploitation. Les appareils doivent
empêcher l'utilisateur de rendre l'appareil inutilisable à son insu (maçonnage) en
en procédant comme suit:
- Implémenter le HAL de contrôle de démarrage pour que le bootloader puisse lire l'ensemble de valeurs
par la méthode
setSnapshotMergeStatus()
. - Si l'état de fusion est
MERGING
ou si l'état de fusion estSNAPSHOTTED
et que celui-ci remplace celui que vous venez de mettre à jour, une demande d'effacementuserdata
,metadata
ou la partition stockant l'état de fusion doit être rejetés dans le bootloader. - Implémentez la commande
fastboot snapshot-update cancel
pour que les utilisateurs puissent au bootloader qu'ils veulent contourner ce mécanisme de protection. - Modification des outils ou des scripts de clignotement personnalisés pour émettre
fastboot snapshot-update cancel
lors du flashage de l'ensemble de l'appareil. Vous pouvez le faire sans risque, car flasher l'ensemble de l'appareil supprime l'OTA. Les outils peuvent détecter cette commande au moment de l'exécution en implémentantfastboot getvar snapshot-update-status
. Ce permet de différencier les conditions d'erreur.
Exemple
struct VirtualAbState {
uint8_t StructVersion;
uint8_t MergeStatus;
uint8_t SourceSlot;
};
bool ShouldPreventUserdataWipe() {
VirtualAbState state;
if (!ReadVirtualAbState(&state)) ...
return state.MergeStatus == MergeStatus::MERGING ||
(state.MergeStatus == MergeStatus::SNAPSHOTTED &&
state.SourceSlot != CurrentSlot()));
}
Modifications apportées à l'outil de démarrage rapide
Android 11 apporte les modifications suivantes au fastboot protocole:
getvar snapshot-update-status
: renvoie la valeur que la commande de contrôle HAL communiqué au bootloader: <ph type="x-smartling-placeholder">- </ph>
- Si l'état est
MERGING
, le bootloader doit renvoyermerging
. - Si l'état est
SNAPSHOTTED
, le bootloader doit renvoyersnapshotted
. - Sinon, le bootloader doit renvoyer
none
.
- Si l'état est
snapshot-update merge
: termine une opération de fusion, en démarrant vers restauration/fastbootd si nécessaire. Cette commande n'est valide que sisnapshot-update-status
estmerging
, et n'est compatible qu'avec fastbootd.snapshot-update cancel
: définit l'état de fusion du HAL de la commande de démarrage surCANCELLED
Cette commande n'est pas valide lorsque l'appareil est verrouillé.erase
ouwipe
:erase
ouwipe
demetadata
,userdata
, ou une partition contenant l'état de fusion du HAL du contrôle de démarrage doit vérifier l'état de fusion de l'instantané. Si l'état estMERGING
ouSNAPSHOTTED
, l'appareil doit annuler l'opération.set_active
: commandeset_active
qui modifie l'emplacement actif doit vérifier l'état de la fusion de l'instantané. Si l'état estMERGING
, l'appareil doit annuler l'opération. L'emplacement peut être modifié en toute sécuritéSNAPSHOTTED
.
Ces modifications sont conçues pour éviter
de rendre accidentellement un appareil impossible à démarrer,
mais ils peuvent perturber les outils automatisés. Lorsque les commandes sont utilisées
permettant de flasher toutes les partitions, comme l'exécution de fastboot flashall
,
il est recommandé d'utiliser le flux suivant:
- Requête
getvar snapshot-update-status
. - Si la valeur est
merging
ousnapshotted
, émettezsnapshot-update cancel
. - Suivez les étapes de clignotement.
Réduire les besoins de stockage
Appareils qui ne disposent pas d'un espace de stockage A/B complet alloué en mode Super et qui attendent
d'utiliser /data
si nécessaire, nous vous recommandons vivement d'utiliser le mappage de blocs
. L'outil de mappage de blocs assure la cohérence de l'allocation de blocs entre les compilations.
ce qui réduit les écritures inutiles sur l'instantané. Reportez-vous à la section Réduire
Taille OTA.
Méthodes de compression OTA
Les packages OTA peuvent être ajustés pour différentes métriques de performances. Avantages d'Android
plusieurs méthodes de compression compatibles (gz
, lz4
, zstd
et none
) qui
doivent faire des compromis entre le temps d'installation, l'utilisation de l'espace de stockage COW, le temps de démarrage et l'instantané.
lors de la fusion. L'option activée par défaut pour les abdos virtuels avec compression est la
gz compression method
Remarque: performances relatives entre les méthodes de compression
dépend de la vitesse du processeur et du débit de stockage, qui peut varier en fonction
sur l'appareil. PostInstall est désactivé dans tous les packages OTA générés ci-dessous.
ralentit légèrement le démarrage. La taille totale de la partition dynamique d'un
ota full sans compression est de 4,81 Go).
OTA supplémentaire sur le Pixel 6 Pro
Temps d'installation sans phase post-installation | Utilisation de l'espace de travail (COW) | Après le démarrage OTA | Heure de fusion de l'instantané | |
---|---|---|---|---|
GZ | 24 min | 1,18 Go | 40,2 s | 45,5 s |
LZ4 | 13 min | 1,49 Go | 37,4 s | 37,1 s |
none | 13 min | 2,90 Go | 37,6 s | 40,7 s |
OTA complète sur le Pixel 6 Pro
Temps d'installation sans phase post-installation | Utilisation de l'espace de COW | Après le démarrage OTA | Heure de fusion de l'instantané | |
---|---|---|---|---|
GZ | 23 min | 2,79 Go | 24,9 s | 41,7 s |
LZ4 | 12 min | 3,46 Go | 20 s | 25,3 s |
none | 10 min | 4,85 Go | 20,6 s | 29,8 s |