Panoramica

I dispositivi Android includono diverse partizioni che svolgono funzioni diverse nel processo di avvio.

Partizioni standard

  • boot. Questa partizione contiene un'immagine del kernel e viene creata utilizzando mkbootimg. Puoi usare una partizione virtuale per eseguire il flashing di qualsiasi immagine senza eseguire il flashing. Questa partizione contiene anche il ramdisk generico nei dispositivi lanciati prima di Android 13.

    • del kernel. 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 non è compatibile, potresti dover 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 del ramdisk sopra quella precedente.

    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 dopo l'immagine o abbandonare l'operazione con un errore.

  • init_boot. Questa partizione contiene il ramdisk generico per i dispositivi lanciati con Android 13 e versioni successive.

  • system partizione. Questa partizione contiene il framework Android.

  • odm. Questa partizione contiene le personalizzazioni del produttore di design originale (ODM) ai pacchetti di supporto della scheda (BSP) del fornitore di system-on-chip (SoC). Queste personalizzazioni consentono agli ODM di sostituire o personalizzare i componenti SoC e di implementare moduli del kernel per componenti, demoni e funzionalità specifici della scheda sugli HAL (Hardware Abstraction Layer). Questa partizione è facoltativa; in genere, viene utilizzata per contenere personalizzazioni in modo che i dispositivi possano utilizzare un'unica immagine del fornitore per più SKU hardware. Per maggiori dettagli, vedi Partizioni ODM.

  • odm_dlkm. Questa partizione è dedicata allo stoccaggio dei moduli del kernel ODM. La memorizzazione dei moduli del kernel ODM nella partizione odm_dlkm (anziché nella partizione odm) consente di aggiornare i moduli del kernel ODM senza aggiornare la partizione odm.

  • recovery. Questa partizione memorizza l'immagine di ripristino, che viene avviata durante il processo OTA. I dispositivi che supportano gli aggiornamenti senza interruzioni possono archiviare le immagini di ripristino come una ramdisk contenuta nell'immagine boot o init_boot (anziché come un'immagine distinta).

  • cache. Questa partizione memorizza dati temporanei ed è facoltativa se un dispositivo utilizza gli aggiornamenti senza interruzioni. La partizione cache non deve essere riscrivibile dal bootloader, ma deve essere cancellabile. La dimensione della partizione dipende dal tipo di dispositivo e dalla disponibilità di spazio su userdata. In genere, sono sufficienti 50-100 MB.

  • misc. Questa partizione viene utilizzata dalla partizione di ripristino ed è obbligatoriamente di almeno 4 KB.

  • userdata partizione. Questa partizione contiene le app e i dati installati dall'utente, inclusi i dati di personalizzazione.

  • metadata. Questa partizione viene utilizzata per archiviare la chiave di crittografia dei metadati quando il dispositivo utilizza la crittografia dei metadati. Le dimensioni sono almeno 16 MB. Non è criptato e non viene eseguito lo snapshot dei dati. L'impostazione viene resettata al ripristino dei dati di fabbrica del dispositivo. L'utilizzo di questa partizione è rigorosamente limitato.

  • vendor partizione. Questa partizione contiene tutti i file binari non distribuibili in AOSP. Se il dispositivo non contiene informazioni proprietarie, puoi omettere questa partizione.

  • vendor_dlkm. Questa partizione è dedicata allo stoccaggio dei moduli del kernel del fornitore. L'archiviazione dei moduli kernel del fornitore nella partizione vendor_dlkm (e non nella partizione vendor) consente di aggiornare i moduli del kernel senza aggiornare la partizione vendor.

  • radio partizione. Questa partizione contiene l'immagine della radio ed è necessaria solo per i dispositivi che includono una radio con software specifico per la radio in una partizione dedicata.

  • tos. Questa partizione memorizza l'immagine binaria del sistema operativo Trusty e viene utilizzata solo se il dispositivo include Trusty. Per maggiori dettagli, vedi Termini di servizio partizioni.

  • pvmfw. Questa partizione memorizza il firmware della VM protetta (pvmfw), che è il primo codice eseguito nelle VM protette. Per ulteriori dettagli, consulta Firmware delle VM protette.

Partizioni dinamiche

I dispositivi con Android 11 e versioni successive possono supportare le partizioni dinamiche, ovvero un sistema di partizione dello spazio utente per Android che consente di creare, ridimensionare o eliminare le partizioni durante gli aggiornamenti over-the-air (OTA). Per maggiori dettagli, vedi Partizioni dinamiche.

Designare partizioni critiche

Se il dispositivo richiede partizioni o dati specifici per l'esecuzione, devi designare tali partizioni o dati come completamente protetti o come riproducibili, ossia ricreabili, forniti o estraibili mediante un comando fastboot oem. Sono inclusi dati quali impostazioni di fabbrica specifiche per dispositivo, numeri di serie, dati di calibrazione e altro ancora.

Modifiche in Android 11

Android 11 include numerose modifiche alle partizioni, tra cui limitazioni al collegamento alle librerie e nuove varianti di immagini Soong.

Layout di partizione Android

Figura 1. Layout delle partizioni in Android 11

  • Immagine del sistema singola (SSI). Una nuova immagine concettuale contenente le immagini system e system_ext. Quando queste partizioni sono comuni per un insieme di dispositivi di destinazione, questi dispositivi possono condividere l'SSI e saltare la creazione delle immagini system e system_ext.

  • system_ext. Una nuova partizione che può utilizzare system risorse e può includere moduli di sistema che:

    • Estendi i moduli di sistema AOSP nella partizione system. Ti consigliamo di eseguire l'upstreaming di questi moduli in AOSP in modo che possano essere installati nella partizione system in un secondo momento.

    • Raggruppa moduli specifici per OEM o SoC. Consigliamo di separare questi moduli in modo che possano essere installati nella partizione product o vendor.

  • system. Immagine di sistema comune utilizzata per i prodotti OEM. Ti consigliamo di spostare i moduli proprietari dalla partizione system, inviandoli in upstream ad AOSP o spostandoli nella partizione system_ext.

  • product partizione. Ora questa partizione può utilizzare le interfacce consentite per installare moduli specifici per prodotto che non sono inclusi in altre partizioni.

Modifiche al VNDK

Il Vendor Native Development Kit (VNDK) è un insieme di librerie installate nella partizione system e progettate esclusivamente per consentire ai fornitori di implementare le proprie 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.

Varianti di prodotto Soong

Il sistema di compilazione Soong utilizza le varianti dell'immagine per suddividere le dipendenze di compilazione. I moduli nativi (/build/soong/cc) possono mutare i moduli di processo di sistema nella variante di base e i moduli di 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 principali. Può anche creare varianti del fornitore definendo vendor_available: true nei suoi Android.bp file; in questo modo, i moduli del fornitore possono 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 file Android.bp (vedi esempio).

  • In Android 11, un modulo di sistema può anche creare una variante di prodotto (oltre alle varianti di base e del 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 di prodotto.