Mises à jour du système A/B

SDV suit l'approche Android standard des mises à jour système A/B (sans interruption). La documentation AOSP s'applique principalement à SDV. Cette page décrit l'utilisation spécifique à SDV et les chemins d'accès connus pour créer et appliquer des packages de mise à jour.

Pour le moment, SDV est configuré pour utiliser des mises à jour A/B non virtuelles.

Implémenter le HAL de contrôle du démarrage

L'image SDV Core pour Cuttlefish (sdv_core_cf) fournit une implémentation standard du HAL de contrôle du démarrage basée sur hardware/interfaces/boot/aidl/default/. Les autres chargeurs de démarrage doivent implémenter le HAL pour prendre en charge les mises à jour A/B.

Pour en savoir plus, consultez la section Implémenter le HAL de contrôle du démarrage de la documentation AOSP. Vous pouvez utiliser bootctl inclus dans les images SDV de débogage (eng et userdebug) pour tester l'implémentation.

Générer un package OTA

Pour en savoir plus, consultez Créer des packages OTA. Les instructions de cette page suivent la documentation AOSP avec quelques différences mineures.

Mise à jour complète

À partir de la racine du dépôt :

source build/envsetup.sh && lunch sdv_core_cf-trunk_staging-userdebug
mkdir dist_output
m dist DIST_DIR=dist_output

Ces commandes génèrent des fichiers cibles dans le répertoire dist_output. Pour les builds locaux de sdv_core_cf, il s'agit normalement de sdv_core_cf-target_files-$USER.zip.

Pour générer un package OTA, vous devez utiliser ota_from_target_files. Contrairement à AOSP, le package n'est pas créé dans le cadre de m dist.

m ota_from_target_files
ota_from_target_files \
  dist_output/sdv_core_cf-target_files-$USER.zip \
  ota_update.zip

Mise à jour incrémentielle

Même ota_from_target_files invocation que dans AOSP :

ota_from_target_files \
  -i PREVIOUS-sdv_core_cf-target_files.zip \
  dist_new/sdv_core_cf-target_files-$USER.zip \
  incremental_ota_update.zip

Installer un package OTA

Les mises à jour sont installées à l'aide du service update_engine. Les builds SDV de débogage incluent update_engine_client, qui peut être utilisé pour déboguer et tester le processus de mise à jour.

Pour installer un package OTA, exécutez :

system/update_engine/scripts/update_device.py ota_update.zip

Si la mise à jour est correctement installée (l'état final est UPDATE_STATUS_UPDATED_NEED_REBOOT et le résultat est ErrorCode::kSuccess), elle sera activée lors du prochain redémarrage.

Gestion des versions

Pour les mises à jour système, SDV utilise les métadonnées du package OTA d'Android pour déterminer si un package OTA répond aux exigences et peut être installé.

Pour APEX, SDV suit également les concepts d'Android concernant la mise à jour. Par conséquent, un APEX peut être mis à jour lorsqu'il ne s'agit pas d'un APEX d'amorçage. Les APEX d'amorçage doivent être mis à jour via des mises à jour système, et soit :

  • La version déclarée version est supérieure à la version préinstallée, et les deux sont supérieures ou égales à 1,

ou

  • La version déclarée est un APEX non préinstallé et la version est supérieure à celle de la liste de refus, si elle y figure.

SDV est généralement déployé sur plusieurs systèmes d'un réseau. Vous devez donc vous assurer que les mises à jour apportées à un seul système sont correctement exécutées. Toutefois, cette précaution ne garantit pas que tous les systèmes peuvent communiquer correctement.

Il est tout aussi essentiel de mettre à jour l'ensemble du réseau, ce qui nécessite que les mises à jour des bundles de services soient déployées sur toutes les machines en même temps ou qu'elles ne contiennent aucune modification destructive. Par exemple, des modifications incompatibles de l'interface.

Bien que SDV ne fournisse pas d'outil pour détecter les modifications incompatibles, nos consignes décrivent comment réconcilier les modifications apportées aux interfaces, ainsi que les bonnes pratiques nécessaires pour déployer les modifications.

De plus, SDV prend en charge les mécanismes de rollback pour les mises à jour système et APEX. Si le système passe involontairement à un état insatisfaisant, nous pouvons récupérer le dernier état satisfaisant connu.