A/B-Systemupdates

SDV folgt dem Android-Standardansatz für A/B-Systemupdates (nahtlos). Die AOSP-Dokumentation gilt hauptsächlich für SDV. Auf dieser Seite werden die spezifischen Anwendungsfälle für SDV und bewährte Methoden zum Erstellen und Anwenden von Updatepaketen beschrieben.

Derzeit ist SDV so konfiguriert, dass nicht virtuelle A/B-Updates verwendet werden.

Boot-Control-HAL implementieren

Das SDV Core-Image für Cuttlefish (sdv_core_cf) bietet eine Standard Implementierung der Boot-Control-HAL, die auf hardware/interfaces/boot/aidl/default/ basiert. Andere Bootloader müssen die HAL implementieren, um A/B-Updates zu unterstützen.

Weitere Informationen finden Sie im Abschnitt Implement the boot control HAL der AOSP Dokumentation. Sie können bootctl verwenden, das in den SDV-Debug-Images (eng und userdebug) enthalten ist, um die Implementierung zu testen.

OTA-Paket generieren

Weitere Informationen finden Sie unter OTA-Pakete erstellen. Die Anweisungen auf dieser Seite folgen der AOSP-Dokumentation mit geringfügigen Abweichungen.

Vollständige Aktualisierung

Über das Repository-Stammverzeichnis:

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

Mit diesen Befehlen werden Zieldateien im Verzeichnis dist_output erstellt. Bei lokalen Builds von sdv_core_cf ist dies normalerweise sdv_core_cf-target_files-$USER.zip.

m

Um ein OTA-Paket zu erstellen, müssen Sie ota_from_target_files verwenden. Anders als in AOSP wird das Paket nicht als Teil von m dist erstellt.

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

Inkrementelle Aktualisierung

Gleicher ota_from_target_files Aufruf wie in 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

OTA-Paket installieren

Updates werden mit dem Dienst update_engine installiert. Debug-SDV-Builds enthalten update_engine_client, mit dem der Updateprozess debuggt und getestet werden kann.

So installieren Sie ein OTA-Paket:

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

Wenn das Update korrekt installiert wurde (der endgültige Status ist UPDATE_STATUS_UPDATED_NEED_REBOOT und das Ergebnis ist ErrorCode::kSuccess), wird das Update beim nächsten Neustart aktiviert.

Versionsverwaltung

Für Systemupdates verwendet SDV die OTA-Paketmetadaten von Android, um zu ermitteln, ob ein OTA-Paket die Anforderungen erfüllt und installiert werden kann.

Auch für APEX folgt SDV den Android-Konzepten zur Aktualisierbarkeit. Daher kann ein APEX aktualisiert werden, wenn er kein Bootstrap-APEX ist. Bootstrap-APEX muss über Systemupdates aktualisiert werden und entweder:

  • Die deklarierte Version ist höher als die vorinstallierte Version und beide sind größer oder gleich 1.

oder

  • Die deklarierte Version ist ein nicht vorinstallierter APEX und die Version ist höher als die Version in der Denylist, falls vorhanden.

SDV wird in der Regel auf mehreren Systemen in einem Netzwerk bereitgestellt. Daher müssen Sie dafür sorgen, dass Updates, die an einem einzelnen System vorgenommen werden, korrekt ausgeführt werden. Trotzdem kann nicht garantiert werden, dass alle Systeme ordnungsgemäß kommunizieren können.

Ebenso wichtig ist es, dass Sie das gesamte Netzwerk aktualisieren. Dazu müssen Updates für Dienstpakete entweder gleichzeitig auf allen Computern bereitgestellt werden oder keine Breaking Changes enthalten. Beispiel: Inkompatible Änderungen an der Schnittstelle.

SDV bietet zwar keine Tools zum Erkennen inkompatibler Änderungen, aber in unseren Richtlinien wird beschrieben, wie Sie Änderungen an Schnittstellen abstimmen und wie Sie die Änderungen am besten bereitstellen.

Außerdem unterstützt SDV Rollback-Mechanismen für System- und APEX-Updates. Wenn das System unbeabsichtigt in einen unbefriedigenden Zustand wechselt, können wir den letzten bekannten zufriedenstellenden Zustand wiederherstellen.