Implementare gli aggiornamenti OTA

Per implementare gli aggiornamenti over-the-air (OTA), il bootloader deve essere in grado di accedere a un disco RAM di ripristino durante l'avvio. Se il dispositivo utilizza un'immagine di ripristino AOSP non modificata, il bootloader legge i primi 32 byte della partizione misc. Se i dati corrispondono a boot-recovery, il bootloader avvia l'immagine recovery. Questo metodo consente a qualsiasi attività di recupero in attesa (ad esempio l'applicazione di un aggiornamento OTA o la rimozione di dati) di continuare fino al completamento.

Per informazioni dettagliate sui contenuti di un blocco in flash utilizzato per le comunicazioni dal recupero e dal bootloader, consulta bootable/recovery/bootloader_message/bootloader_message.h.

Dispositivi con aggiornamenti A/B

Per supportare gli aggiornamenti OTA sui dispositivi che utilizzano gli aggiornamenti A/B, assicurati che il bootloader del dispositivo soddisfi i seguenti criteri.

Criteri generali

• Tutte le partizioni aggiornate tramite un OTA devono essere aggiornabili durante l'avvio del sistema principale (e non aggiornate in modalità di ripristino).

• Per avviare la partizione system, il bootloader passa il seguente valore alla riga di comando del kernel: ro root=/dev/[node] rootwait init=/init.

• È responsabilità del framework Android chiamare markBootSuccessful dall'HAL. Il bootloader non deve mai contrassegnare una partizione come avviata correttamente.

Supporto per l'HAL di controllo dell'avvio

Il bootloader deve supportare l'HAL boot_control come definito in hardware/libhardware/include/hardware/boot_control.h. L'aggiornamento esegue query sull'HAL di controllo dell'avvio, aggiorna lo slot di avvio non in uso, modifica lo slot attivo utilizzando l'HAL e riavvia il sistema operativo aggiornato. Per maggiori dettagli, consulta Implementazione dell'HAL di controllo del boot.

Supporto per gli slot

Il bootloader deve supportare le funzionalità relative a partizioni e slot, tra cui:

• I nomi delle partizioni devono includere un suffisso che identifichi le partizioni appartenente a un determinato slot nel bootloader. Per ogni partizione di questo tipo, esiste una variabile corrispondente has-slot:partition base name con un valore di yes. Gli slot sono denominati in ordine alfabetico come a, b, c e così via, corrispondenti alle partizioni con il suffisso _a, _b, _c e così via. Il bootloader deve informare il sistema operativo dello slot da cui è stato eseguito l'avvio utilizzando la proprietà della riga di comando androidboot.slot_suffix. Questa proprietà viene impostata tramite bootconfig per i dispositivi avviati con Android 12 o versioni successive.

• Il valore slot-retry-count viene reimpostato su un valore positivo (di solito 3), dall'HAL di controllo del boot tramite il callback setActiveBootSlot o tramite il comando fastboot set_active. Quando modifichi una partizione che fa parte di uno slot, il bootloader cancella "avvio riuscito" e reimposta il conteggio dei tentativi per lo slot.

Il bootloader deve anche determinare quale slot caricare. La figura mostra un esempio di processo decisionale.

1. Determina quale slot provare. Non tentare di caricare una scheda contrassegnata come slot-unbootable. Questo slot deve essere coerente con i valori restituiti da fastboot e viene definito slot corrente.

2. Se lo slot corrente non è contrassegnato come slot-successful e contiene un slot-retry-count = 0, contrassegnalo come slot-unbootable. Quindi, seleziona un altro intervallo che non è contrassegnato come unbootable, ma come slot-successful. Questo intervallo è ora selezionato. Se non è disponibile alcuno slot corrente, avvia il recupero o mostra un messaggio di errore significativo all'utente.

3. Seleziona boot.img appropriato e includi il percorso della partizione di sistema corretta sulla riga di comando del kernel.

4. Compila il parametro slot_suffix della riga di comando del kernel.

5. Avvia. Se non è contrassegnato slot-successful, decrementa slot-retry-count.

L'utilità fastboot determina quale partizione eseguire il flashing quando esegui comandi di flashing. Ad esempio, l'esecuzione del comando fastboot flash system system.img esegue prima una query sulla variabile current-slot, quindi concatena il risultato al sistema per generare il nome della partizione da eseguire in modalità flash (system_a, system_b e così via).

Quando imposti lo slot corrente utilizzando il comando fastboot set_active o il comando HAL di controllo del boot setActiveBootSlot, il bootloader deve aggiornare lo slot corrente, cancellare slot-unbootable e slot-successful e reimpostare il conteggio dei tentativi (questo è l'unico modo per cancellare slot-unbootable).

Dispositivi senza aggiornamenti A/B

Per supportare gli aggiornamenti OTA sui dispositivi che non utilizzano gli aggiornamenti A/B (vedi Dispositivi non A/B aggiornabili), assicurati che il bootloader del dispositivo soddisfi i seguenti criteri.

• La partizione recovery deve contenere un'immagine in grado di leggere un'immagine di sistema da qualche partizione supportata (cache, userdata) e di scriverla nella partizione system.

• Il bootloader deve supportare l'avvio direttamente in modalità di ripristino.

• Se sono supportati gli aggiornamenti delle immagini della radio, la partizione recovery dovrebbe anche essere in grado di eseguire il flashing della radio. Questa operazione può essere eseguita in due modi:

  • Il bootloader esegue il flashing della radio. In questo caso, dovrebbe essere possibile riavviare dalla partizione di ripristino al bootloader per completare l'aggiornamento.

  • L'immagine di ripristino fa lampeggiare la radio. Questa funzionalità può essere fornita come utility o libreria binaria.