Panoramica

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 utilizzando mkbootimg . È 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 partizione vendor , system o dtb (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 partizione odm_dlkm (in contrapposizione alla partizione odm ) rende possibile aggiornare i moduli del kernel ODM senza aggiornare la partizione odm .

  • 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'immagine boot o init_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 sui userdata ; 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 partizione vendor_dlkm (al contrario della partizione vendor ) rende possibile aggiornare i moduli del kernel senza aggiornare la partizione vendor .

  • 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.

Layout della partizione Android

Figura 1. Layout della partizione in Android 11

  • Immagine del sistema unico (SSI). Una nuova immagine concettuale che contiene le immagini system e system_ext . Quando queste partizioni sono comuni per un insieme di dispositivi di destinazione, tali dispositivi possono condividere SSI e saltare la creazione delle immagini system e system_ext .

  • partizione system_ext . Una nuova partizione che può utilizzare le risorse system 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 partizione system .

    • Bundle di moduli OEM o specifici del SoC. Si consiglia di separare tali moduli in modo che possano essere installati nella partizione del product o vendor .

  • partizione system . Immagine di sistema comune utilizzata per i prodotti OEM. Consigliamo di spostare i moduli proprietari fuori dalla partizione system , eseguendo l'upstream su AOSP o spostandoli nella partizione system_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 partizione system , ma non può collegarsi ad altre librerie nella partizione system . I moduli nativi nella partizione product possono collegarsi a qualsiasi libreria nella partizione system .

  • In Android 11 e versioni successive, le partizioni product e vendor possono collegarsi alle librerie VNDK nella partizione system , ma non possono collegarsi ad altre librerie nella partizione system .

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 file Android.bp ; ciò consente ai moduli del fornitore di collegarsi ai moduli di sistema. Le librerie VNDK, che sono varianti del fornitore delle librerie system , possono anche creare varianti del fornitore per i moduli del fornitore definendo vendor_available: true nei relativi file Android.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 senza product_available: true non sono disponibili per i moduli del prodotto.