SDV segue l'approccio Android standard degli aggiornamenti di sistema A/B (continui). La documentazione di AOSP si applica principalmente agli SDV. Questa pagina descrive in dettaglio l'utilizzo specifico per gli SDV e i percorsi corretti noti per la creazione e l'applicazione dei pacchetti di aggiornamento.
L'SDV è configurato per utilizzare aggiornamenti A/B non virtuali. Per configurare e attivare gli aggiornamenti A/B per una partizione /oem_ab personalizzata da un bundle di servizi, consulta Aggiornamenti delle partizioni AB OEM.
Implementa l'HAL di controllo dell'avvio
L'immagine SDV Core per Cuttlefish (sdv_core_cf) fornisce un'implementazione standard dell'HAL di controllo di avvio basata su hardware/interfaces/boot/aidl/default/. Altri bootloader devono implementare l'HAL per supportare gli aggiornamenti A/B.
Per maggiori dettagli, consulta la sezione Implementa l'HAL di controllo dell'avvio della documentazione di AOSP. Puoi utilizzare bootctl incluso nelle immagini SDV di debug (eng
e userdebug) per testare l'implementazione.
Genera un pacchetto OTA
Per scoprire di più, consulta Crea pacchetti OTA. Le istruzioni riportate in questa pagina seguono la documentazione di AOSP con piccole deviazioni.
Aggiornamento completo
Dalla radice del repository:
source build/envsetup.sh && lunch sdv_core_cf-aosp_current-userdebug
mkdir dist_output
m dist DIST_DIR=dist_output
Questi comandi generano file di destinazione nella directory dist_output. Per le build locali di sdv_core_cf, questo è normalmente sdv_core_cf-target_files-$USER.zip.
Per produrre un pacchetto OTA, devi utilizzare ota_from_target_files. A differenza di
AOSP, il pacchetto non viene creato come parte di m dist.
m ota_from_target_files
ota_from_target_files \
dist_output/sdv_core_cf-target_files-$USER.zip \
ota_update.zip
Aggiornamento incrementale
Stessa chiamata ota_from_target_files di 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
Installa un pacchetto OTA
Gli aggiornamenti vengono installati utilizzando il servizio update_engine. Le build SDV di debug includono update_engine_client, che può essere utilizzato per eseguire il debug e testare il processo di aggiornamento.
Per installare un pacchetto OTA, esegui:
system/update_engine/scripts/update_device.py ota_update.zip
Se l'aggiornamento è installato correttamente (lo stato finale è
UPDATE_STATUS_UPDATED_NEED_REBOOT e il risultato è ErrorCode::kSuccess),
l'aggiornamento verrà attivato al riavvio successivo.
Controllo delle versioni
Per gli aggiornamenti di sistema, SDV utilizza i metadati del pacchetto OTA di Android per determinare se un pacchetto OTA soddisfa i requisiti e può essere installato.
Anche per APEX, SDV segue i concetti di Android relativi all'aggiornabilità. Pertanto, un APEX può essere aggiornato quando non è un APEX di bootstrap. L'APEX di bootstrap deve essere aggiornato tramite gli aggiornamenti di sistema e:
- La versione dichiarata è superiore alla versione preinstallata ed entrambe sono maggiori o uguali a 1.
oppure
- La versione dichiarata è un APEX non preinstallato e la versione è superiore a quella presente nella lista bloccata, se elencata.
In genere, l'SDV viene distribuito su più sistemi di una rete. Pertanto, devi assicurarti che gli aggiornamenti apportati a un singolo sistema vengano eseguiti correttamente. Tuttavia, questa attenzione non garantisce che tutti i sistemi possano comunicare correttamente.
È altrettanto fondamentale aggiornare la rete complessiva, il che richiede che gli aggiornamenti dei bundle di servizi vengano distribuiti su tutte le macchine contemporaneamente o che non contengano modifiche che provocano un errore. Ad esempio, modifiche incompatibili all'interfaccia.
Sebbene SDV non fornisca strumenti per rilevare modifiche incompatibili, le nostre linee guida descrivono come riconciliare le modifiche apportate alle interfacce, nonché le best practice necessarie per eseguire il deployment delle modifiche.
Inoltre, SDV supporta i meccanismi di rollback per gli aggiornamenti di sistema e APEX. Se il sistema entra involontariamente in uno stato non soddisfacente, possiamo recuperare l'ultimo stato soddisfacente noto.