À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Mise à jour OTA pour les appareils A/B sans partitions dynamiques

Android 10 est compatible avec les partitions dynamiques, un système de partitionnement de l'espace utilisateur qui permet de créer, redimensionner et supprimer des partitions lors des mises à jour OTA (Over-The-Air).

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 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) sur 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.

Chacun des périphériques de bloc comporte deux emplacements de métadonnées. Un seul emplacement de métadonnées est utilisé dans chaque périphérique de bloc. Par exemple, les métadonnées 0 à system_a et les métadonnées 1 à system_b correspondent respectivement aux partitions des emplacements A et B. Au moment de l'exécution, l'emplacement mis à jour n'a pas d'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 appelées system_s, vendor_t, etc.

Pour en savoir plus sur les configurations du système de compilation, consultez Mettre à niveau des appareils.

Pour en savoir plus sur l'appartenance des partitions aux groupes de mise à jour, consultez Modifications de la configuration de la carte pour les nouveaux appareils.

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

Périphérique de bloc 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
  - Groupe bar_a
    - Partition logique (dynamique) vendor_a
    - Partition logique (dynamique) product_a
    - Autres partitions mises à jour par Bard
- Métadonnées 1 (non utilisées)
Périphérique 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
  - Groupe bar_b
    - Partition logique (dynamique) vendor_b
    - Partition logique (dynamique) product_b
    - Autres partitions mises à jour par Bard

Vous pouvez utiliser l'outil lpdump sous system/extras/partition_tools pour vider 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

Adapter une mise à jour

Sur les appareils exécutant Android 9 ou une 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éé pour 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 blocs 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 qu'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é. Pour en savoir plus, consultez Configurer après l'installation.

Le flux de mise à jour est le même que dans 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 de 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 la partition super.
1. Construisez de nouvelles métadonnées M à partir des métadonnées sources S. Par exemple, si les métadonnées S utilisent [system_s, vendor_s, product_s] comme périphériques de bloc, 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 fichier manifeste de mise à jour. La taille de chaque partition est indiquée dans new_partition_info.
3. Écrire M dans les métadonnées T.
4. Mappez les partitions ajoutées sur le mappeur de périphériques en tant qu'écriture.
Appliquez la mise à jour sur les périphériques de bloc.
1. Si nécessaire, mappez les partitions sources sur le mappeur de périphériques en lecture seule. Cela est nécessaire pour le transfert latéral, car les partitions sources ne sont pas mappées avant la mise à jour.
2. Appliquez une mise à jour complète ou différentielle à tous les périphériques de bloc dans l'emplacement cible.
3. Montez les partitions pour exécuter le script post-installation, puis démontez-les.
Dissociez les partitions cibles.

Flux de mise à jour à l'aide d'un package de mise à jour Retrofit

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 le fichier super.img fractionné directement sur les périphériques de bloc. Le flux de mise à jour est semblable à une mise à jour de rétrocompatibilité. Pour en savoir plus, consultez Adapter une mise à jour.

Par exemple, supposons ce qui suit :

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

Lorsque le client OTA reçoit un package de mise à jour de mise à niveau, 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 périphérique de bloc physique system_b contient les métadonnées correctes pour mapper les system_b, vendor_b et product_b logiques au moment du démarrage.

Générer des packages de mise à jour

OTA incrémentiel

Lorsque vous générez des mises à jour OTA incrémentielles pour les appareils de post-équipement, les mises à jour dépendent de la définition ou non de PRODUCT_USE_DYNAMIC_PARTITIONS et PRODUCT_RETROFIT_DYNAMIC_PARTITIONS par la version de base.

Si la compilation de base ne définit pas les variables, il s'agit d'une mise à jour de réadaptation. 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 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 complet

Deux packages OTA complets sont générés pour les appareils de mise à niveau.

$(PRODUCT)-ota-retrofit-$(TAG).zip contient toujours super.img fractionné et désactive l'étape post-installation pour la mise à jour de rétrofit.
- Il est généré avec un argument supplémentaire --retrofit_dynamic_partitions pour le script ota_from_target_files.
- Il peut être appliqué à toutes les compilations.
$(PRODUCT)-ota-$(TAG).zip contient des images logiques pour les futures mises à jour.
- Appliquez cette option uniquement aux builds pour lesquels les partitions dynamiques sont activées. Pour en savoir plus sur l'application de cette règle, consultez les informations ci-dessous.

Refuser la mise à jour non rétrocompatible sur les anciens builds

Appliquez le package OTA complet standard uniquement aux builds pour lesquels les partitions dynamiques sont activées. Si le serveur OTA est mal configuré 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 mise à niveau et un package OTA complet normal. Il n'est donc pas en mesure de refuser 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 en tant qu'étape post-installation et rejette la mise à jour.