I dispositivi Android includono diverse partizioni che svolgono diverse funzioni nel processo di avvio.
Partizioni standard
partizione
boot
. Questa partizione contiene un'immagine del kernel e viene creata utilizzandomkbootimg
. È possibile utilizzare una partizione virtuale per eseguire il flashing di entrambe le immagini direttamente senza eseguire il flashing di una nuova partizione di avvio. Questa partizione contiene anche il ramdisk generico nei dispositivi lanciati prima di Android 13.nocciolo. La partizione virtuale
kernel
sovrascrive il kernel (zImage
,zImage-dtb
,Image.gz-dtb
) scrivendo la nuova immagine del kernel sulla vecchia immagine del kernel. Se il kernel di sviluppo fornito è incompatibile, potrebbe essere necessario aggiornare la partizionevendor
,system
odtb
(se presente) con i moduli del kernel associati.ramdisk. La partizione
ramdisk
virtuale sovrascrive il ramdisk scrivendo la nuova immagine ramdisk sulla vecchia immagine ramdisk.
L'operazione di sovrascrittura determina la posizione iniziale dell'immagine esistente in eMMC e copia la nuova immagine in quella posizione. La nuova immagine (kernel o ramdisk) potrebbe essere più grande di quella esistente; per fare spazio, il bootloader può spostare i dati seguendo l'immagine o abbandonare l'operazione in caso di errore.
partizione
init_boot
. Questa partizione contiene il ramdisk generico per i dispositivi che si avviano con Android 13 e versioni successive.partizione
system
. Questa partizione contiene il framework Android.partizione
odm
. Questa partizione contiene le personalizzazioni del produttore del progetto originale (ODM) ai pacchetti di supporto della scheda del fornitore (BSP) System-on-Chip (SoC). Tali personalizzazioni consentono agli ODM di sostituire o personalizzare i componenti SoC e implementare moduli kernel per componenti specifici della scheda, demoni e funzionalità specifiche dell'ODM sugli HAL (Hardware Abstraction Layer). Questa partizione è facoltativa; in genere, viene utilizzato per contenere personalizzazioni in modo che i dispositivi possano utilizzare un'immagine di un singolo fornitore per più SKU hardware. Per i dettagli, vedere Partizioni ODM .partizione
odm_dlkm
. Questa partizione è dedicata alla memorizzazione dei moduli del kernel ODM. La memorizzazione dei moduli del kernel ODM nella partizioneodm_dlkm
(in contrapposizione alla partizioneodm
) rende possibile aggiornare i moduli del kernel ODM senza aggiornare la partizioneodm
.partizione
recovery
. Questa partizione memorizza l'immagine di ripristino, che viene avviata durante il processo OTA. I dispositivi che supportano aggiornamenti continui possono archiviare le immagini di ripristino come un ramdisk contenuto nell'immagineboot
oinit_boot
(anziché un'immagine separata).partizione
cache
. Questa partizione archivia dati temporanei ed è facoltativa se un dispositivo utilizza aggiornamenti continui. Non è necessario che la partizione della cache sia scrivibile dal bootloader, ma deve essere cancellabile. La dimensione della partizione dipende dal tipo di dispositivo e dalla disponibilità di spazio suiuserdata
; in genere sono sufficienti 50 MB–100 MB.partizione
misc
. Questa partizione viene utilizzata dalla partizione di ripristino ed è di 4 KB o superiore.partizione
userdata
. Questa partizione contiene app e dati installati dall'utente, inclusi i dati di personalizzazione.partizione
metadata
. Questa partizione viene utilizzata per archiviare la chiave di crittografia dei metadati quando il dispositivo utilizza la crittografia dei metadati . La dimensione è pari o superiore a 16 MB. Non è crittografato e i suoi dati non vengono catturati. Viene cancellato quando il dispositivo viene ripristinato alle impostazioni di fabbrica. L'utilizzo di questa partizione è strettamente limitato.partizione
vendor
. Questa partizione contiene qualsiasi file binario non distribuibile su AOSP. Se il dispositivo non contiene informazioni proprietarie, puoi omettere questa partizione.partizione
vendor_dlkm
. Questa partizione è dedicata alla memorizzazione dei moduli del kernel del fornitore. Memorizzare i moduli del kernel del fornitore nella partizionevendor_dlkm
(al contrario della partizionevendor
) rende possibile aggiornare i moduli del kernel senza aggiornare la partizionevendor
.partizione
radio
. Questa partizione contiene l'immagine radio ed è necessaria solo per i dispositivi che includono una radio con software specifico per la radio in una partizione dedicata.tos
partizione. Questa partizione memorizza l'immagine binaria del sistema operativo Trusty e viene utilizzata solo se il dispositivo include Trusty. Per i dettagli, vedere Partizioni TOS .partizione
pvmfw
. Questa partizione memorizza il firmware della macchina virtuale protetta (pvmfw), che è il primo codice eseguito nelle VM protette. Per ulteriori dettagli, vedere Firmware della macchina virtuale protetta .
Partizioni dinamiche
I dispositivi con Android 11 e versioni successive possono supportare le partizioni dinamiche, che sono un sistema di partizionamento dello spazio utente per Android che consente di creare, ridimensionare o distruggere partizioni durante gli aggiornamenti over-the-air (OTA). Per i dettagli, vedere Partizioni dinamiche .
Designazione delle partizioni critiche
Se il dispositivo richiede partizioni o dati specifici per l'esecuzione, è necessario designare tali partizioni/dati come completamente protetti o come re-flashable, ovvero ricostruibili, forniti o estraibili utilizzando un comando fastboot oem
. Ciò include dati come impostazioni di fabbrica specifiche per dispositivo, numeri di serie, dati di calibrazione e altro ancora.
Cambiamenti in Android 11
Android 11 include numerose modifiche alle partizioni, comprese restrizioni sul collegamento alle librerie e nuove varianti di immagini Soong.
Figura 1. Layout della partizione in Android 11
Immagine del sistema unico (SSI). Una nuova immagine concettuale che contiene le immagini
system
esystem_ext
. Quando queste partizioni sono comuni per un insieme di dispositivi di destinazione, tali dispositivi possono condividere SSI e saltare la creazione delle immaginisystem
esystem_ext
.partizione
system_ext
. Una nuova partizione che può utilizzare le risorsesystem
e può includere moduli di sistema che:Estendi i moduli di sistema AOSP nella partizione
system
. Si consiglia di eseguire l'upstream di tali moduli su AOSP in modo che possano essere installati successivamente nella partizionesystem
.Bundle di moduli OEM o specifici del SoC. Si consiglia di separare tali moduli in modo che possano essere installati nella partizione del
product
ovendor
.
partizione
system
. Immagine di sistema comune utilizzata per i prodotti OEM. Consigliamo di spostare i moduli proprietari fuori dalla partizionesystem
, eseguendo l'upstream su AOSP o spostandoli nella partizionesystem_ext
.partizione
product
. Questa partizione ora può utilizzare le interfacce consentite per installare moduli specifici del prodotto che non sono forniti in bundle con altre partizioni.
VNDK cambia
Il Vendor Native Development Kit (VNDK) è un insieme di librerie installate nella partizione system
e progettate esclusivamente per consentire ai fornitori di implementare i propri HAL.
In Android 10 e versioni precedenti, la partizione
vendor
può collegarsi alle librerie VNDK nella partizionesystem
, ma non può collegarsi ad altre librerie nella partizionesystem
. I moduli nativi nella partizioneproduct
possono collegarsi a qualsiasi libreria nella partizionesystem
.In Android 11 e versioni successive, le partizioni
product
evendor
possono collegarsi alle librerie VNDK nella partizionesystem
, ma non possono collegarsi ad altre librerie nella partizionesystem
.
Presto varianti di prodotto
Il sistema di build Soong utilizza varianti di immagine per dividere le dipendenze di build. I moduli nativi ( /build/soong/cc
) possono trasformare i moduli del processo di sistema nella variante principale e i moduli del processo del fornitore nella variante del fornitore; un modulo in una variante dell'immagine non può collegarsi ad altri moduli in una variante dell'immagine diversa.
In Android 10 o versioni precedenti, un modulo di sistema crea automaticamente varianti core. Può anche creare varianti del fornitore definendo
vendor_available: true
nei suoi fileAndroid.bp
; ciò consente ai moduli del fornitore di collegarsi ai moduli di sistema. Le librerie VNDK, che sono varianti del fornitore delle libreriesystem
, possono anche creare varianti del fornitore per i moduli del fornitore definendovendor_available: true
nei relativi fileAndroid.bp
(vedere esempio ).In Android 11, un modulo di sistema può anche creare una variante di prodotto (oltre alle varianti core e fornitore) definendo
vendor_available: true
.In Android 12 o versioni successive, un modulo di sistema con
vendor_available: true
crea una variante del fornitore oltre alla variante principale. Per creare una variante di prodotto,product_available: true
deve essere definito. Alcune librerie VNDK senzaproduct_available: true
non sono disponibili per i moduli del prodotto.