Android 10 est compatible avec les partitions dynamiques, un système de partitionnement de l'espace utilisateur qui peut créer, redimensionner et détruire des partitions lors des mises à jour OTA (Over-the-Air).
Cette page explique comment les clients OTA redimensionnent les partitions dynamiques lors d'une mise à jour pour les appareils A/B lancés sans prise en charge des partitions dynamiques, et comment les clients OTA passent à Android 10.
Arrière-plan
Lors de la mise à jour d'un appareil A/B pour prendre en charge les partitions dynamiques, la table de partition GUID (GPT) de l'appareil est conservée. Il n'y a donc pas de partition super
sur l'appareil. Les métadonnées sont stockées dans system_a
et system_b
, mais vous pouvez les personnaliser en modifiant BOARD_SUPER_PARTITION_METADATA_DEVICE
.
Chaque appareil de bloc comporte deux emplacements de métadonnées. Un seul emplacement de métadonnées de chaque appareil de traitement par blocs est utilisé. Par exemple, les métadonnées 0 sur system_a
et les métadonnées 1 sur system_b
correspondent respectivement aux partitions des emplacements A et B. Au moment de l'exécution, l'emplacement mis à jour n'a aucune importance.
Sur cette page, les emplacements de métadonnées sont appelés "Métadonnées S" (source) et "Métadonnées T" (cible). De même, les partitions sont désignées par system_s
, vendor_t
, etc.
Pour en savoir plus sur les configurations du système de compilation, consultez la section Mettre à niveau des appareils.
Pour en savoir plus sur l'appartenance des partitions aux groupes de mises à jour, consultez Modifications de la configuration de la carte pour les nouveaux appareils.
Voici un exemple de métadonnées sur un appareil:
- Appareil de blocage physique
system_a
- Métadonnées 0
- Groupe
foo_a
- Partition logique (dynamique)
system_a
- Partition logique (dynamique)
product_services_a
- Autres partitions mises à jour par Foo
- Partition logique (dynamique)
- Groupe
bar_a
- Partition logique (dynamique)
vendor_a
- Partition logique (dynamique)
product_a
- Autres partitions mises à jour par Bar
- Partition logique (dynamique)
- Groupe
- Métadonnées 1 (non utilisées)
- Métadonnées 0
- Appareil de blocage physique
system_b
- Métadonnées 0 (non utilisées)
- Métadonnées 1
- Groupe foo_b
- Partition logique (dynamique)
system_b
- Partition logique (dynamique)
product_services_b
- Autres partitions mises à jour par Foo
- Partition logique (dynamique)
- Groupe bar_b
- Partition logique (dynamique)
vendor_b
- Partition logique (dynamique)
product_b
- Autres partitions mises à jour par Bar
- Partition logique (dynamique)
- Groupe foo_b
Vous pouvez utiliser l'outil lpdump
sous system/extras/partition_tools
pour extraire les métadonnées sur votre appareil. Exemple :
lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b
Retrofiter une mise à jour
Sur les appareils équipés d'Android 9 ou version antérieure, le client OTA de l'appareil n'est pas compatible avec le mappage des partitions dynamiques avant la mise à jour. Un ensemble supplémentaire de correctifs est créé afin que le mappage puisse être appliqué directement aux partitions physiques existantes.
Le générateur OTA crée le fichier super.img
final contenant le contenu de toutes les partitions dynamiques, puis divise l'image en plusieurs images correspondant aux tailles des appareils de bloc physique correspondant au système, au fournisseur, etc. Ces images sont nommées super_system.img
, super_vendor.img
, etc.
Le client OTA applique ces images aux partitions physiques plutôt qu'aux partitions logiques (dynamiques).
Étant donné que le client OTA ne sait pas cartographier les partitions dynamiques, toutes les étapes post-installation sont automatiquement désactivées pour ces partitions lors de la génération du package de mise à jour. Pour en savoir plus, consultez la section Configurer la post-installation.
Le parcours de mise à jour est le même qu'avec Android 9.
Avant la mise à jour:
ro.boot.dynamic_partitions= ro.boot.dynamic_partitions_retrofit=
Après la mise à jour:
ro.boot.dynamic_partitions=true ro.boot.dynamic_partitions_retrofit=true
Mises à jour futures après la mise à niveau
Après la mise à jour rétrofit, le client OTA est mis à jour pour fonctionner avec les partitions dynamiques. Les étendues des partitions sources ne s'étendent jamais sur les partitions physiques cibles.
Flux de mise à jour à l'aide d'un package de mise à jour standard
- Initialisez les métadonnées de partition
super
.-
Créer des métadonnées M à partir des métadonnées S (métadonnées source)
Par exemple, si les métadonnées S utilisent [
system_s
,vendor_s
,product_s
] comme appareils de blocage, les nouvelles métadonnées M utilisent [system_t
,vendor_t
,product_t
] comme appareils de blocage. Tous les groupes et partitions sont supprimés dans M. -
Ajoutez des groupes et des partitions cibles en fonction du champ
dynamic_partition_metadata
dans le fichier manifeste de mise à jour. La taille de chaque partition se trouve dansnew_partition_info
. - Écrivez M pour les métadonnées T.
- Mappez les partitions ajoutées sur le mappeur d'appareils en tant que partitions en écriture.
-
Créer des métadonnées M à partir des métadonnées S (métadonnées source)
Par exemple, si les métadonnées S utilisent [
- Appliquez la mise à jour sur les appareils de blocage.
- Si nécessaire, mappez les partitions sources sur le mappeur d'appareil en lecture seule. Cela est nécessaire pour le téléchargement parallèle, car les partitions sources ne sont pas mappées avant la mise à jour.
- Appliquez une mise à jour complète ou delta à tous les appareils de blocage à l'emplacement cible.
- Montez les partitions pour exécuter le script post-installation, puis démontez-les.
- Annulez le mappage des partitions cibles.
Flux de mise à jour à l'aide d'un package de mise à jour de rétrofit
Si le package de mise à jour de rétrofit est appliqué sur un appareil qui active déjà les partitions dynamiques, le client OTA applique directement le fichier super.img
fractionné sur les appareils de bloc. Le flux de mise à jour est semblable à une mise à jour rétrofit. Pour en savoir plus, consultez la section Mettre à niveau une mise à jour.
Par exemple, supposons les éléments suivants:
- L'emplacement A est l'emplacement actif.
-
system_a
contient les métadonnées actives à l'emplacement 0. -
system_a
,vendor_a
etproduct_a
sont utilisés comme dispositifs de blocage.
Lorsque le client OTA reçoit un package de mise à jour de rétrofit, il applique super_system.img
sur system_b
physique, super_vendor.img
sur vendor_b
physique et super_product.img
sur product_b
physique.
Le dispositif de bloc physique system_b
contient les métadonnées appropriées pour mapper les system_b
, vendor_b
et product_b
logiques au démarrage.
Générer des packages de mise à jour
OTA supplémentaire
Lors de la génération d'OTA incrémentaux pour les appareils rétrofités, les mises à jour dépendent de la définition ou non de PRODUCT_USE_DYNAMIC_PARTITIONS
et PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
dans le build de base.
-
Si la compilation de base ne définit pas les variables, il s'agit d'une mise à jour du réajustement. Le package de mise à jour contient le fichier
super.img
fractionné et désactive l'étape post-installation. - Si la compilation de base définit les variables, cela revient à une mise à jour classique avec des partitions dynamiques. Le package de mise à jour contient les images des partitions logiques (dynamiques). L'étape post-installation peut être activée.
OTA complète
Deux packages OTA complets sont générés pour les appareils rétrofités.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
contient toujours lasuper.img
fractionnée et désactive l'étape post-installation pour la mise à niveau de rétrofit.-
Il est généré avec un argument
--retrofit_dynamic_partitions
supplémentaire au scriptota_from_target_files
. - Il peut être appliqué à toutes les compilations.
-
Il est généré avec un argument
-
$(PRODUCT)-ota-$(TAG).zip
contient des images logiques pour les futures mises à jour.- N'appliquez cela qu'aux compilations avec les partitions dynamiques activées. Pour en savoir plus, consultez les informations ci-dessous.
Refuser la mise à jour non rétrofit sur les anciennes versions
Appliquez le package OTA complet standard uniquement aux builds avec des partitions dynamiques activées. Si le serveur OTA n'est pas configuré correctement et envoie ces packages aux appareils équipés d'Android 9 ou version antérieure, les appareils ne démarrent pas. Le client OTA sur Android 9 et versions antérieures ne peut pas faire la différence entre un package OTA de rétrofit et un package OTA complet standard. Le client ne rejette donc pas le package complet.
Pour empêcher l'appareil d'accepter le package OTA complet, vous pouvez exiger une étape post-installation pour vérifier la configuration existante de l'appareil. Exemple :
device/device_name/dynamic_partitions/check_dynamic_partitions
#!/system/bin/sh DP_PROPERTY_NAME="ro.boot.dynamic_partitions" DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit" DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME}) DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME}) if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then echo "Error: applied non-retrofit update on build without dynamic" \ "partitions." echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}" echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}" exit 1 fi
device/device_name/dynamic_partitions/Android.mk
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE:= check_dynamic_partitions LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := EXECUTABLES LOCAL_SRC_FILES := check_dynamic_partitions LOCAL_PRODUCT_MODULE := true include $(BUILD_PREBUILT)
device/device_name/device.mk
PRODUCT_PACKAGES += check_dynamic_partitions # OPTIONAL=false so that the error in check_dynamic_partitions will be # propagated to OTA client. AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_product=true \ POSTINSTALL_PATH_product=bin/check_dynamic_partitions \ FILESYSTEM_TYPE_product=ext4 \ POSTINSTALL_OPTIONAL_product=false \
Lorsque le package OTA standard est appliqué sur un appareil sans partitions dynamiques activées, le client OTA exécute check_dynamic_partitions
comme étape post-installation et rejette la mise à jour.