SDV suit l'approche Android standard des mises à jour du système A/B (transparentes). La documentation AOSP s'applique principalement à SDV. Cette page détaille l'utilisation spécifique aux SDV et les chemins d'accès connus pour créer et appliquer des packages de mise à jour.
SDV est configuré pour utiliser des mises à jour A/B non virtuelles. Pour configurer et déclencher des mises à jour A/B pour une partition /oem_ab personnalisée à partir d'un bundle de services, consultez Mises à jour de partition AB OEM.
Implémenter la HAL de contrôle de démarrage
L'image SDV Core pour Cuttlefish (sdv_core_cf) fournit une implémentation standard de la HAL de contrôle de démarrage basée sur hardware/interfaces/boot/aidl/default/. Les autres bootloaders doivent implémenter la HAL pour prendre en charge les mises à jour A/B.
Pour en savoir plus, consultez la section Implémenter la HAL de contrôle de 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 de l'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-aosp_current-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 généralement de sdv_core_cf-target_files-$USER.zip.
Pour produire un package OTA, vous devez utiliser ota_from_target_files. Contrairement à l'AOSP, le package n'est pas compilé 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 appel ota_from_target_files 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 la commande suivante :
system/update_engine/scripts/update_device.py ota_update.zip
Si la mise à jour est installée correctement (l'état final est UPDATE_STATUS_UPDATED_NEED_REBOOT et le résultat est ErrorCode::kSuccess), elle sera activée au prochain redémarrage.
Gestion des versions
Pour les mises à jour du 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 possibilité de mise à jour. Par conséquent, un APEX peut être mis à jour lorsqu'il ne s'agit pas d'un APEX bootstrap. L'APEX d'amorçage doit être mis à jour via les mises à jour du système, et :
- La version déclarée 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 blocage, si elle est listée.
SDV est généralement déployé sur plusieurs systèmes d'un réseau. Par conséquent, vous devez vous assurer que les mises à jour apportées à un seul système sont correctement exécutées. Toutefois, cela ne garantit pas que tous les systèmes puissent communiquer correctement.
Il est tout aussi important 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 pas de modifications destructives. Par exemple, des modifications incompatibles de l'interface.
Bien que SDV ne fournisse pas d'outils pour détecter les modifications incompatibles, nos consignes décrivent comment rapprocher les modifications apportées aux interfaces, ainsi que les bonnes pratiques nécessaires pour déployer les modifications.
De plus, SDV est compatible avec les mécanismes de rollback pour les mises à jour du système et d'APEX. Si le système passe involontairement à un état insatisfaisant, nous pouvons récupérer le dernier état satisfaisant connu.