Implementare patch A/B virtuali

Scegli le seguenti patch per risolvere i seguenti problemi noti.

Controllare correttamente lo spazio allocabile durante il sideload

Il sideload di un pacchetto OTA completo su un dispositivo A/B virtuale che dispone di una super partizione con una dimensione inferiore a *2 * sum(dimensione dei gruppi di aggiornamento)* potrebbe non riuscire con quanto segue nel registro di ripristino /tmp/recovery.log :

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

Ecco un esempio del registro:

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

Se riscontri questo problema, seleziona CL 1399393 , ricostruisci ed esegui il flashing della partizione di avvio o di ripristino se il dispositivo non utilizza il ripristino come avvio.

Risolto errore di segmentazione durante l'unione

Dopo aver applicato un aggiornamento OTA, durante il processo di unione VAB, una chiamata a update_engine_client --cancel causa l'arresto anomalo di CleanupPreviousUpdateAction . Esiste anche un potenziale errore del puntatore selvaggio quando markSlotSuccessful arriva in ritardo.

Il problema è stato risolto aggiungendo la funzione StopActionInternal . CleanupPreviousUpdateAction annulla le attività in sospeso durante la distruzione. Mantiene una variabile che tiene traccia dell'ID dell'attività in sospeso nel ciclo di messaggi. Alla distruzione, l'attività in sospeso viene annullata per evitare segfault.

Assicurati che le seguenti modifiche siano presenti nell'albero dei sorgenti di Android 11 per correggere gli arresti anomali SIGSEGV in update_engine durante l'unione:

  • CL 1439792 (un prerequisito per CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : annulla le attività in sospeso durante la distruzione)
  • CL 1663460 (corregge il potenziale errore del puntatore selvaggio quando markSlotSuccessful arriva in ritardo)

Correzione del cambio di slot errato di VAB, post aggiornamento OTA

In Android 11 e versioni successive, la mancata sincronizzazione di un interruttore di slot in un dispositivo dopo un aggiornamento OTA può mettere il dispositivo in uno stato inutilizzabile. Se l'implementazione del cambio di slot dell'HAL IBootControl esegue scritture, è necessario eliminare tali scritture immediatamente. Se le scritture non vengono cancellate e il dispositivo si riavvia dopo l'avvio dell'unione, ma prima che l'hardware possa cancellare la scrittura dello switch di slot, il dispositivo potrebbe tornare allo slot precedente e non riuscire ad avviarsi.

Per una soluzione di codice di esempio, visualizzare questo CL: CL 1535570 .

Impedisce l'unione prematura di update_engine

Quando un dispositivo si avvia (Android 11 e versioni successive) e l'avvio viene completato, update_engine chiama ScheduleWaitMarkBootSuccessful() e WaitForMergeOrSchedule() . Questo avvia il processo di fusione. Tuttavia, il dispositivo si riavvia nel vecchio slot. Poiché l'unione è già iniziata, il dispositivo non si avvia e diventa inutilizzabile.

Aggiungi le seguenti modifiche al tuo albero di origine. Tieni presente che CL 1664859 è facoltativo.

  • CL 1439792 (un prerequisito per CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : annulla le attività in sospeso durante la distruzione)
  • CL 1663460 (corregge il potenziale errore del puntatore selvaggio quando markSlotSuccessful arriva in ritardo)
  • CL 1664859 (facoltativo: aggiungi unittest per CleanupPreviousUpdateAction )

Previeni la perdita o il danneggiamento dei dati a causa di metadati saltati

In Android 11 e versioni successive, se un dispositivo di archiviazione dispone di una cache di write-back volatile, in determinate condizioni i metadati di un'unione completata vengono saltati, con conseguente perdita o danneggiamento dei dati.

Condizioni:

  1. Dopo aver terminato un'operazione di unione di un set di eccezioni, è stato richiamato merge_callback() .
  2. I metadati sono stati aggiornati nel dispositivo COW che tiene traccia del completamento dell'unione. (Questo aggiornamento al dispositivo COW viene scaricato in modo pulito.)

Risultato: il sistema si è bloccato a causa del mancato svuotamento della cache del dispositivo di archiviazione della recente unione.

Per implementare una risoluzione, vedere quanto segue:

Assicurati che la configurazione dm-verity sia corretta

In Android 11 e versioni successive, i dispositivi possono essere configurati inavvertitamente con le seguenti opzioni dm-verity:

  • CONFIG_DM_VERITY_AVB=y nel kernel
  • Il bootloader configurato per utilizzare qualsiasi modalità verity, (come AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE ), senza AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Con questa configurazione del dispositivo, qualsiasi errore di verità causa il danneggiamento della partizione vbmeta e rende inutilizzabili i dispositivi non A/B. Allo stesso modo, se è iniziata una fusione, anche i dispositivi A/B potrebbero diventare inutilizzabili. Utilizzare solo la modalità di verità AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

  1. Imposta CONFIG_DM_VERITY_AVB=n nel kernel
  2. Configurare i dispositivi per utilizzare invece la modalità AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Per ulteriori informazioni e come pratica, fare riferimento alla documentazione di verity: Gestione degli errori dm-verity .

Salta il lavoro di verità in risposta a un errore I/O durante l'arresto di emergenza del sistema

In Android 11 e versioni successive, se viene richiesto un arresto di emergenza del sistema (come nel caso di un arresto termico), un dispositivo dm può essere attivo mentre il dispositivo a blocchi non può più elaborare le richieste I/O. In questo stato, gli errori di I/O gestiti dalle nuove richieste di I/O dm o da quelle già in corso possono portare a uno stato di corruzione della verità, che rappresenta un errore di valutazione.

Per ignorare il lavoro di Verity in risposta a un errore I/O durante l'arresto del sistema, utilizzare quanto segue:

CL 1847875 (Ignora il lavoro di verifica in risposta a un errore I/O durante l'arresto)

Assicurati che DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED sia disattivato

I dispositivi Android Go che eseguono il kernel 4.19 o versioni precedenti potrebbero avere DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y nella configurazione del kernel. Questa impostazione non è compatibile con Virtual A/B ed è nota per causare rari problemi di corruzione della pagina quando entrambe sono abilitate insieme.

Per i kernel 4.19 e precedenti, disabilitalo impostando CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n nella configurazione del kernel.

Per i kernel 5.4 e successivi, il codice è stato rimosso e l'opzione di configurazione non è disponibile.

Conferma che il file unito sia configurato correttamente

Se stai creando immagini di sistema e immagini del fornitore separatamente, quindi utilizzando merge_target_files per unirle, le configurazioni A/B virtuali potrebbero essere eliminate erroneamente durante il processo di unione. Per verificare che le configurazioni A/B virtuali siano corrette nel file di destinazione unito, applicare le seguenti patch: CL 2084183 (unire coppie chiave/val identiche nelle informazioni sulla partizione dinamica)

Aggiorna i componenti necessari

A partire da Android 13, snapuserd è stato spostato dal ramdisk del fornitore al ramdisk generico. Se il tuo dispositivo sta eseguendo l'aggiornamento ad Android 13, è possibile che sia il ramdisk del fornitore che il ramdisk generico contengano una copia di snapuserd . In questa situazione, Virtual A/B richiede la copia di sistema di snapuserd . Per garantire che sia presente la copia corretta di snapuserd , applicare CL 2031243 (copia snapuserd su first_stage_ramdisk).