Seleziona i seguenti patch per risolvere i seguenti problemi noti.
Controllare correttamente lo spazio allocabile durante il sideloading
Il caricamento laterale di un pacchetto OTA completo su un dispositivo Virtual A/B con una superpartizione di dimensioni inferiori a *2 * sum(size of update groups) 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 del 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, seleziona CL 1399393, ricompila e flasha la partizione di avvio o la partizione di ripristino se il dispositivo non utilizza il ripristino come avvio.
Correggere l'errore di segmentazione durante l'unione
Dopo l'applicazione di 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 non valido quando markSlotSuccessful
arriva in ritardo.
Il problema è stato risolto aggiungendo la funzione StopActionInternal
.
CleanupPreviousUpdateAction
annulla le attività in attesa di eliminazione. Mantiene una variabile che tiene traccia dell'ID attività dell'attività in attesa nel loop di messaggi. In
destroy, l'attività in attesa viene annullata per evitare errori di segmentazione.
Assicurati che le seguenti modifiche siano nell'albero delle origini di Android 11 per correggere gli arresti anomali di SIGSEGV
in update_engine
durante l'unione:
- CL 1439792 (un prerequisito per la CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction
: cancel pending tasks on destroy) - CL 1663460 (correzione del potenziale errore di puntatore non valido 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 viene completato, vengono chiamati
update_engine
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 si avvia e diventa inutilizzabile.
Aggiungi le seguenti modifiche all'albero delle origini. Tieni presente che CL 1664859 è facoltativo.
- CL 1439792 (un prerequisito per la CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction
: cancel pending tasks on destroy) - CL 1663460 (correzione del potenziale errore di puntatore non valido quando
markSlotSuccessful
arriva in ritardo) - CL 1664859 (facoltativo -
aggiungi
unittest
perCleanupPreviousUpdateAction
)
Assicurati che la configurazione di 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à 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 integrità 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. 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 saperne di più, consulta la documentazione di verifica: Gestione degli errori dm-verity.
Conferma che il file unito sia configurato correttamente
Se crei immagini di sistema e immagini del fornitore separatamente, l'utilizzo di
merge_target_files
per unirle potrebbe comportare l'eliminazione errata delle configurazioni A/B virtuali durante il processo di unione. Per verificare che le configurazioni A/B virtuale
siano corrette nel file di destinazione unito, applica le 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 il tuo dispositivo esegue l'upgrade ad Android 13, è possibile che sia il ramdisk del fornitore sia il ramdisk generico contengano una copia di snapuserd
. In questa
situazione, il test A/B virtuale 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).