Scegli le patch che ti interessano per risolvere i seguenti problemi noti.
Controllare correttamente lo spazio allocato durante il sideload
Esegui il sideload di un pacchetto OTA completo su un dispositivo A/B virtuale dotato di una
con una dimensione inferiore a *2 * sum(dimensione dei gruppi di aggiornamento)* potrebbe non riuscire
con quanto segue nel log di recupero /tmp/recovery.log
:
The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...
Ecco un esempio di log:
[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, scegli CL 1399393, ricreare e usare il flash la partizione di avvio o di ripristino se il dispositivo non utilizza il ripristino avvio.
Correggere l'errore di segfault 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 di puntatore generico quando markSlotSuccessful
arriva in ritardo.
Il problema è stato risolto aggiungendo la funzione StopActionInternal
.
CleanupPreviousUpdateAction
annulla le attività in sospeso al momento dell'eliminazione. Mantiene un
che monitora l'ID dell'attività in sospeso nel loop di messaggi. Al termine dell'operazione destroy, l'attività in attesa viene annullata per evitare un errore di segmento.
Per correggere gli arresti anomali di SIGSEGV
in update_engine
durante l'unione, assicurati che le seguenti modifiche siano presenti nella struttura di origine di Android 11:
- CL 1439792 (prerequisito per CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction
: annulla attività in sospeso al momento dell'eliminazione) - RP 1663460 (correzione del potenziale errore del cursore generico quando
markSlotSuccessful
arriva in ritardo)
Impedisci l'unione prematura di update_engine
Quando un dispositivo si avvia (Android 11 e versioni successive) e l'avvio è completato, update_engine
chiama ScheduleWaitMarkBootSuccessful()
e WaitForMergeOrSchedule()
. Questa operazione avvia il processo di unione. Tuttavia, il dispositivo si riavvia nello slot precedente. Poiché l'unione è già iniziata, il dispositivo non riesce
si avvia e diventa inutilizzabile.
Aggiungi le seguenti modifiche alla struttura di origine. Tieni presente che il CL 1664859 è facoltativo.
- CL 1439792 (prerequisito per CL 1439372)
- RP 1439372
(
CleanupPreviousUpdateAction
: annulla le attività in attesa al momento dell'eliminazione) - RP 1663460 (correzione del potenziale errore del cursore generico quando
markSlotSuccessful
arriva in ritardo) - CL 1664859 (facoltativo:
aggiungi
unittest
perCleanupPreviousUpdateAction
)
Assicurati che la configurazione della verifica DM sia corretta
In Android 11 e versioni successive, i dispositivi possono essere inavvertitamente configurati con seguenti opzioni dm-verity:
CONFIG_DM_VERITY_AVB=y
nel kernel- Il bootloader configurato per l'utilizzo di qualsiasi modalità di verifica, ad esempio
AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE
), senzaAVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
.
Con questa configurazione del dispositivo, qualsiasi errore di verifica fa sì che la partizione vbmeta
si danneggiano e rendono inutilizzabili i dispositivi non A/B. Analogamente, se un'unione
potrebbe essere subito inutilizzabile anche i dispositivi A/B. Utilizza solo la modalità di verifica AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
.
- Imposta
CONFIG_DM_VERITY_AVB=n
nel kernel. - Configura i dispositivi per l'utilizzo
modalità
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
.
Per ulteriori informazioni, consulta la documentazione sulla verifica: Gestione di dm-verity Errori.
Verificare che il file unito sia configurato correttamente
Se stai creando immagini di sistema e immagini dei fornitori separatamente, utilizza
merge_target_files
per unirli, le configurazioni A/B virtuali potrebbero essere
eliminati in modo errato durante il processo di unione. Per verificare che A/B virtuale
siano corrette nel file di destinazione unito, applica quanto segue
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 sul tuo dispositivo è in corso l'upgrade ad Android 13, è possibile che sia il ramdisk del fornitore sia il ramdisk generico contengano una copia di snapuserd
. In questa situazione, Virtual A/B richiede la copia di sistema di snapuserd
. Per garantire che
la copia corretta di snapuserd
sia presente, applica CL
2031243
(copia snapuserd
in first_stage_ramdisk).