OTA pour les appareils A/B sans partitions dynamiques

Android 10 prend en charge 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 en direct (OTA).

Cette page décrit 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 sont mis à niveau vers Android 10.

Arrière-plan

Lors d'une mise à jour d'un périphérique A/B pour prendre en charge les partitions dynamiques, la table de partition GUID (GPT) sur le périphérique est préservée, il n'y a donc pas super partition sur le périphérique. Les métadonnées sont stockées dans system_a et system_b , mais cela peut être personnalisé en modifiant BOARD_SUPER_PARTITION_METADATA_DEVICE .

Dans chacun des périphériques bloc, il existe deux emplacements de métadonnées. Un seul emplacement de métadonnées dans chaque périphérique bloc 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 en cours de mise à jour n'a pas d'importance.

Dans cette page, les emplacements de métadonnées sont appelés Metadata S (source) et Metadata T (cible). De même, les partitions sont appelées system_s , vendor_t , etc.

Pour plus d'informations sur les configurations du système de build , voir Mise à niveau des appareils .

Pour plus d'informations sur la manière dont les partitions appartiennent aux groupes de mise à jour , consultez Modifications de la configuration de la carte pour les nouveaux périphériques.

Voici un exemple de métadonnées sur un appareil :

  • system_a de périphérique de bloc physique_a
    • Métadonnées 0
      • Groupe foo_a
        • system_a de partition logique (dynamique)_a
        • Partition logique (dynamique) product_services_a
        • Autres partitions mises à jour par Foo
      • bar_a de groupe_a
        • Partition logique (dynamique) vendor_a
        • Partition logique (dynamique) product_a
        • Autres partitions mises à jour par Bar
    • Métadonnées 1 (non utilisées)
  • Dispositif de bloc 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
      • Barre de groupe_b
        • Partition logique (dynamique) vendor_b
        • Partition logique (dynamique) product_b
        • Autres partitions mises à jour par Bar

Vous pouvez utiliser l'outil lpdump sous system/extras/partition_tools pour vider les métadonnées sur votre appareil. Par exemple:

lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b

Rénover une mise à jour

Sur les appareils exécutant Android 9 et versions antérieures, le client OTA sur l'appareil ne prend pas en charge 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 qui contient le contenu de toutes les partitions dynamiques, puis divise l'image en plusieurs images correspondant aux tailles des périphériques de bloc physiques 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 que d'appliquer les images aux partitions logiques (dynamiques).

Étant donné que le client OTA ne sait pas comment mapper les partitions dynamiques, toutes les étapes post-installation sont automatiquement désactivées pour ces partitions lorsque le package de mise à jour est généré. Voir Configuration de la post-installation pour plus de détails.

Le flux de mise à jour est le même que sous 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

Futures mises à jour après la mise à niveau

Après la mise à jour de mise à niveau, le client OTA est mis à jour pour fonctionner avec des partitions dynamiques. Les extensions des partitions sources ne s'étendent jamais sur les partitions physiques cibles.

Flux de mise à jour à l'aide d'un package de mise à jour régulière

  1. Initialisez les métadonnées de la super partition.
    1. Construisez de nouvelles métadonnées M à partir des métadonnées S (métadonnées sources). Par exemple, si les métadonnées S utilisent [ system_s , vendor_s , product_s ] comme périphériques de bloc, alors les nouvelles métadonnées M utilisent [ system_t , vendor_t , product_t ] comme périphériques de bloc. Tous les groupes et partitions sont supprimés dans M.
    2. Ajoutez des groupes cibles et des partitions en fonction du champ dynamic_partition_metadata dans le manifeste de mise à jour. La taille de chaque partition peut être trouvée dans new_partition_info .
    3. Écrivez M dans les métadonnées T.
    4. Mappez les partitions ajoutées sur le mappeur de périphériques comme étant accessibles en écriture.
  2. Appliquez la mise à jour sur les appareils bloqués.
    1. Si nécessaire, mappez les partitions sources sur le mappeur de périphériques en lecture seule. Ceci est nécessaire pour le chargement latéral, car les partitions sources ne sont pas mappées avant la mise à jour.
    2. Appliquez une mise à jour complète ou delta à tous les périphériques bloqués sur l'emplacement cible.
    3. Montez les partitions pour exécuter le script de post-installation, puis démontez les partitions.
  3. Supprimez le mappage des partitions cibles.

Flux de mise à jour à l’aide d’un package de mise à jour de mise à niveau

Si le package de mise à jour de mise à niveau est appliqué sur un périphérique qui active déjà les partitions dynamiques, le client OTA applique directement le fichier super.img divisé sur les périphériques en mode bloc. Le flux de mise à jour est similaire à une mise à jour de mise à niveau. Voir Mise à niveau d'une mise à jour pour plus de détails.

Par exemple, supposons ce qui suit :

  • L'emplacement A est l'emplacement actif.
  • system_a contient les métadonnées actives à l'emplacement 0.
  • system_a , vendor_a et product_a sont utilisés comme périphériques de bloc.

Lorsque le client OTA reçoit un package de mise à jour de mise à niveau, il applique super_system.img sur system_b physique_b , super_vendor.img sur vendor_b physique_b et super_product.img sur product_b physique_b . Le périphérique de bloc physique system_b contient les métadonnées correctes pour mapper les systèmes logiques system_b , vendor_b et product_b au moment du démarrage.

Générer des packages de mise à jour

OTA incrémentielle

Lors de la génération d'OTA incrémentielles pour les appareils de mise à niveau, les mises à jour dépendent du fait que la version de base définit ou non PRODUCT_USE_DYNAMIC_PARTITIONS et PRODUCT_RETROFIT_DYNAMIC_PARTITIONS .

  • Si la version de base ne définit pas les variables, il s'agit d'une mise à jour de mise à niveau. Le package de mise à jour contient le fichier super.img divisé et désactive l'étape de post-installation.
  • Si la version de base définit les variables, cela équivaut à une mise à jour typique 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 de mise à niveau.

  • $(PRODUCT)-ota-retrofit-$(TAG).zip contient toujours split super.img et désactive l'étape post-installation pour la mise à jour de mise à niveau.
    • Il est généré avec un argument supplémentaire --retrofit_dynamic_partitions au script ota_from_target_files .
    • Il peut être appliqué à toutes les versions.
  • $(PRODUCT)-ota-$(TAG).zip contient des images logiques pour les futures mises à jour.
    • Appliquez ceci uniquement aux builds avec les partitions dynamiques activées. Voir les détails ci-dessous sur l’application de cela.

Rejeter la mise à jour sans mise à niveau sur les anciennes versions

Appliquez le package OTA complet standard uniquement aux versions avec des partitions dynamiques activées. Si le serveur OTA est mal configuré et transmet ces packages aux appareils exécutant Android 9 ou une 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 mise à niveau et un package OTA complet standard, de sorte que le client ne rejettera 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. Par 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.