Panoramica

I dispositivi Android includono diverse partizioni che svolgono funzioni diverse di avvio della chat.

Partizioni standard

  • boot partizione. Questa partizione contiene un'immagine kernel e viene creata utilizzando mkbootimg. Puoi utilizzare una partizione virtuale per eseguire il flashing di entrambe le immagini senza dover eseguire il flashing di una nuova partizione di avvio. Questa partizione contiene anche il ramdisk generico nei dispositivi avviati prima Android 13.

    • del kernel. La partizione virtuale kernel sovrascrive il kernel (zImage, zImage-dtb, Image.gz-dtb) scrivendo la nuova immagine kernel sulla vecchia l'immagine kernel. Se il kernel di sviluppo fornito non è compatibile, potresti devi aggiornare la partizione vendor, system o dtb (se presente) con e i moduli kernel associati.

    • ramdisk. La partizione virtuale ramdisk 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 quello esistente; per fare spazio, il bootloader può spostare i dati che seguono l'immagine o abbandonare l'operazione con un errore.

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

  • system partizione. Questa partizione contiene il framework Android.

  • odm partizione. Questa partizione contiene un produttore di design originale (ODM) personalizzazioni ai pacchetti di supporto board (BSP) del fornitore system-on-chip (SoC). Tali personalizzazioni consentono agli ODM di sostituire o personalizzare i componenti SoC. implementare moduli kernel per componenti, daemon e Funzionalità specifiche per ODM negli HAL (Hardware Astrazione Livelli). Questa partizione è facoltativo; di solito viene utilizzato per contenere le personalizzazioni in modo che i dispositivi Utilizzare un'unica immagine del fornitore per più SKU hardware. Per maggiori dettagli, vedi ODM Partizioni.

  • odm_dlkm partizione. Questa partizione è dedicata all'archiviazione del kernel ODM moduli. Archiviazione dei moduli kernel ODM nella partizione odm_dlkm (anziché i moduli di kernel ODM) alla partizione odm) consente di aggiornare i moduli kernel ODM senza aggiornare la partizione odm.

  • recovery partizione. Questa partizione archivia l'immagine di ripristino, avviato durante la procedura OTA. Dispositivi che supportano senza interruzioni aggiornamenti, puoi archiviare le immagini di ripristino come ramdisk contenuto nell'immagine boot o init_boot (anziché un file immagine).

  • cache partizione. Questa partizione archivia dati temporanei ed è facoltativa se un dispositivo utilizza aggiornamenti continui. La partizione cache non deve essere necessariamente accessibile in scrittura dal bootloader, ma deve essere cancellabile. La partizione le dimensioni dipendono dal tipo di dispositivo e dalla disponibilità di spazio su userdata. in genere, sono sufficienti 50 MB-100 MB.

  • misc partizione. Questa partizione è utilizzata dalla partizione di ripristino 4 kB o superiore.

  • userdata partizione. Questa partizione contiene app installate dall'utente e compresi quelli di personalizzazione.

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

  • vendor partizione. Questa partizione contiene qualsiasi programma binario non distribuibile ad AOSP. Se il dispositivo non contiene informazioni proprietarie, puoi omettere questa partizione.

  • vendor_dlkm partizione. Questa partizione è dedicata all'archiviazione e i moduli kernel. Archiviazione dei moduli kernel del fornitore nella partizione vendor_dlkm (a differenza della partizione vendor) rende possibile l'aggiornamento del kernel moduli senza aggiornare la partizione vendor.

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

  • tos partizione. Questa partizione archivia l'immagine binaria del sistema operativo Trusty e viene utilizzato solo se il dispositivo include Trusty. Per maggiori dettagli, consulta i TdS Partizioni.

  • pvmfw partizione. Questa partizione archivia la macchina virtuale protetta Firmware (pvmfw), il primo codice eseguito nelle VM protette. Consulta Firmware macchina virtuale protetta per ulteriori dettagli.

Partizioni dinamiche

I dispositivi con Android 11 e versioni successive supportano partizioni dinamiche, che sono un sistema di partizionamento dello spazio utente per Android consente di creare, ridimensionare o distruggere le partizioni durante la configurazione OTA (over-the-air) aggiornamenti. Per maggiori dettagli, consulta partizioni di memoria.

Specifica le partizioni critiche

Se il dispositivo richiede partizioni o dati specifici per l'esecuzione, devi specificare tali partizioni o dati come completamente protetti o riproducibili, nel senso che possono essere ricreati, forniti o estraibili con un comando fastboot oem. Sono inclusi dati quali impostazioni di fabbrica, numeri di serie, dati di calibrazione e altro.

Modifiche in Android 11

Android 11 include numerose modifiche alle partizioni, incluse le limitazioni relative al collegamento alle raccolte e alle nuove varianti delle immagini di Presto.

Layout di partizione Android

Figura 1. Layout di partizione in Android 11

  • SSI (Single System Image). Una nuova immagine concettuale che contiene system e system_ext immagini. Quando queste partizioni sono comuni per un insieme dei dispositivi target, questi possono condividere l'SSI e saltare la creazione system e system_ext immagini.

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

    • Estendi i moduli di sistema AOSP nella partizione system. I nostri suggerimenti eseguire l'upstream di questi moduli ad AOSP in modo che possano essere installati nell'system la partizione in un secondo momento.

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

  • system partizione. Immagine di sistema comune per i prodotti OEM. Me consiglia di spostare i moduli proprietari dalla partizione system eseguendone l'upstream in AOSP o spostandole nella partizione system_ext.

  • product partizione. Questa partizione ora può utilizzare le interfacce consentite installare moduli specifici dei prodotti che non sono integrati con altri partizioni di Compute Engine.

Modifiche VNDK

Il Vendor Native Development Kit (VNDK) è un insieme di librerie installato nella partizione system e progettato solo per i fornitori che vogliono implementare i propri HAL.

  • In Android 10 e versioni precedenti, la partizione vendor può collegarsi alle librerie VNDK in la partizione system, ma non può collegarsi ad altre librerie nel system della partizione di testo. I moduli nativi nella partizione product possono collegarsi a qualsiasi libreria nella partizione system.

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

Varianti del prodotto soong

Il sistema di compilazione di Soong utilizza le varianti dell'immagine per suddividere e creare dipendenze. I moduli nativi (/build/soong/cc) possono modificare il sistema i moduli di processo alla variante principale e ai moduli di processo del fornitore variante del fornitore; un modulo in una variante dell'immagine non può essere collegato 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; Ciò consente ai moduli del fornitore di collegarsi a moduli di sistema. Anche le librerie VNDK, che sono varianti del fornitore delle librerie system, possono crea varianti del fornitore per i moduli del fornitore definendo vendor_available: true nei suoi Android.bp file (vedi esempio).

  • In Android 11, un modulo di sistema può anche crea una variante di prodotto (oltre alle varianti di base e del fornitore) che definisce vendor_available: true.

  • In Android 12 o versioni successive, un modulo di sistema con vendor_available: true crea una variante del fornitore oltre a quella principale e la variante corrispondente. Per creare una variante di prodotto, product_available: true deve essere definito. Alcune librerie VNDK senza product_available: true non lo sono disponibili per i moduli del prodotto.