Scegli le patch che ti interessano per risolvere i seguenti problemi noti.
Controllare correttamente lo spazio allocato durante il sideload
Il sideload di un pacchetto OTA completo su un dispositivo A/B virtuale con una superpartizione di dimensioni inferiori a *2 * somma(dimensioni dei gruppi di aggiornamento)* potrebbe non riuscire con il seguente messaggio nel log 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 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, ricostruisci e esegui il flashing della partizione di avvio o della partizione di ripristino se il dispositivo non utilizza il recupero come 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 attesa al momento dell'eliminazione. Mantiene una variabile che tiene traccia dell'ID dell'attività in attesa 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)
- 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)
Impedire 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()
. Viene avviato il processo di unione. Tuttavia, il dispositivo si riavvia nello slot precedente. Poiché l'unione è già iniziata, il dispositivo non riesce ad avviarsi e diventa inutilizzabile.
Aggiungi le seguenti modifiche alla struttura di origine. Tieni presente che il CL 1664859 è facoltativo.
- 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) - 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 configurati inavvertitamente con le seguenti opzioni dm-verity:
CONFIG_DM_VERITY_AVB=y
nel kernel- Il bootloader configurato per utilizzare qualsiasi modalità Verity, 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 causa la corruzione della partizione vbmeta e rende inoperabili i dispositivi non A/B. Analogamente, se è stata avviata un'unione, anche i dispositivi A/B potrebbero non essere più operativi. 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 in modo che utilizzino la modalità
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
.
Per ulteriori informazioni, consulta la documentazione di Verity: Gestione degli errori di dm-verity.
Verificare che il file unito sia configurato correttamente
Se stai creando immagini di sistema e immagini dei fornitori separatamente e utilizzi merge_target_files
per unirle, le configurazioni A/B virtuali potrebbero essere eliminate in modo errato durante il processo di unione. Per verificare che le configurazioni A/B virtuali siano corrette nel file di destinazione unito, applica i seguenti patch: CL
2084183
(unisci coppie chiave/valore 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 assicurarti che sia presente la copia corretta di snapuserd
, applica CL
2031243
(copia snapuserd
in first_stage_ramdisk).