A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Os dispositivos Android contêm várias partições ou seções específicas de espaço de armazenamento
usadas para conter partes específicas do software do dispositivo. Cada partição contém uma imagem de partição (um arquivo IMG) ou um snapshot de todo o software da partição. A Figura 1 mostra o layout das partições principais em um dispositivo:
Figura 1. Layout das partições principais.
As partições são classificadas em três categorias:
As partições do sistema são atualizadas quando o SO
e outros recursos são atualizados. As partições system, boot e init_boot são do sistema principal.
As partições do fornecedor contêm código específico do dispositivo e do hardware que talvez
nunca seja atualizado após o lançamento inicial. As partições vendor, vendor_boot e odm
são partições principais do fornecedor.
Partições não atualizáveis são aquelas cujo conteúdo não é atualizado ou é atualizado com dados do usuário.
O código nas partições do sistema e do fornecedor pode interagir usando uma interface estável
chamada interface do fornecedor (VINTF).
Partições do sistema
Confira a seguir uma lista de todas as partições do sistema e o uso delas:
Partição boot. Essa partição contém uma imagem genérica do kernel (GKI, na sigla em inglês).
Essa partição também contém o ramdisk genérico em dispositivos lançados no
Android 12 e versões anteriores. Para mais informações sobre ramdisk genérico, consulte
Conteúdo da imagem de ramdisk genérico.
Partição init_boot (Android 13 e versões mais recentes). Essa partição contém um ramdisk genérico. No Android 11 e 12, o ramdisk genérico está na
partição boot.
Partição system. Essa partição contém a imagem do sistema usada
para produtos OEM.
Partição system_ext. Essa partição contém recursos do sistema e módulos proprietários que estendem a imagem comum do sistema na partição system.
Partição product. Essa partição pode conter módulos específicos do produto
que não estão agrupados com nenhuma outra partição.
Partição pvmfw. Essa partição armazena o firmware da máquina virtual protegida (pvmfw), que é o primeiro código executado em VMs protegidas. Para mais
informações, consulte Firmware de máquina virtual protegida.
Partição generic_bootloader. Essa partição contém o carregador de inicialização genérico.
Partições do fornecedor
Confira a seguir uma lista de todas as partições do fornecedor e o uso delas:
Partição vendor_boot. Essa partição contém código de inicialização
específico do fornecedor. Para mais informações, consulte Partições de inicialização do fornecedor.
Partição recovery. Essa partição armazena a imagem de recuperação, que é
inicializada durante o processo de atualização over-the-air (OTA). Os dispositivos que oferecem suporte a
atualizações sem interrupção podem armazenar as imagens de recuperação como um ramdisk contido na
imagem boot ou init_boot. Para mais informações sobre atualizações sem interrupção,
consulte Atualizações A/B (sem interrupção).
Partição misc. Essa partição é usada pela partição de recuperação e tem 4 KB ou mais.
Partição vbmeta. Essa partição contém as informações de inicialização verificada
para todas as partições. Essas informações verificam se as imagens instaladas
em cada partição são confiáveis. Para mais informações sobre a
Inicialização verificada, consulte
Inicialização verificada.
Partição vendor. Essa partição contém qualquer binário específico do fornecedor e não genérico o suficiente para distribuição ao AOSP.
Partição vendor_dlkm. Essa partição contém módulos do kernel do fornecedor. Ao armazenar módulos de kernel do fornecedor nessa partição em vez da vendor, é possível atualizar os módulos de kernel sem atualizar a partição vendor. Para mais informações, consulte
Partições DKLM de fornecedores e ODMs.
Partição odm. Essa partição contém personalizações do fabricante de projeto original
(ODM)
para pacotes de suporte de placa (BSPs) do fornecedor do system on a chip (SoC).
Essas personalizações permitem que os ODMs substituam ou personalizem componentes do SoC e implementem módulos de kernel para componentes específicos da placa, daemons e recursos específicos do ODM em camadas de abstração de hardware (HALs). Essa partição é
opcional. Normalmente, essa partição é usada para conter personalizações para que
dispositivos possam
usar uma única imagem de fornecedor para vários SKUs de hardware. Para mais informações, consulte Partições da ODM.
Partição odm_dlkm. Essa partição é dedicada ao armazenamento de módulos do kernel
do ODM. Ao armazenar módulos do kernel ODM nessa partição, em vez da partição odm, é possível atualizar os módulos do kernel ODM sem atualizar a partição odm. Para mais informações, consulte
Partições DKLM de fornecedores e ODMs.
Partição radio. Essa partição contém a imagem de rádio e é necessária
apenas para dispositivos que incluem um rádio com software específico em uma
partição dedicada.
Partições não atualizáveis
Confira a seguir uma lista de todas as partições não atualizáveis e o uso delas:
Partição cache. Essa partição contém dados temporários e é opcional
se o dispositivo usa atualizações sem interrupção. Ela não precisa ser gravável pelo carregador de inicialização, mas precisa ser apagável. O tamanho da partição depende do tipo de dispositivo e da disponibilidade de espaço em userdata. Normalmente, 50 a 100 MB são suficientes.
Partição userdata. Essa partição contém apps e dados instalados pelo usuário, incluindo dados de personalização.
Partição metadata. Se o dispositivo usar criptografia de metadados,
essa partição vai conter a chave de criptografia de metadados. O tamanho dessa partição é de 16 MB ou maior, ela não está criptografada e os dados não foram capturados em um snapshot. Essa partição é apagada quando o dispositivo é redefinido para a configuração original.
Regras e recomendações de atualização de partição
Recomendamos atualizar todas as partições do sistema como um todo e todas as partições do fornecedor como outro todo. Ao atualizar o conjunto de partições como um todo, você pode testar para verificar se as interfaces entre as imagens em cada partição permanecem estáveis.
Independente de como você atualiza as partições, as seguintes precisam ser atualizadas devido a dependências fortemente acopladas e falta de APIs estáveis:
As partições boot e system_dlkm
as partições init_boot, system, system_ext e product
Partições dinâmicas
Dispositivos com Android 11 e versões mais recentes podem oferecer suporte a
partições dinâmicas, que são um sistema de particionamento no espaço do usuário para Android que
permite criar, redimensionar ou destruir partições durante atualizações
pelo ar (OTA). Para mais informações, consulte Partições dinâmicas.
Variantes de produto do Soong
O sistema de build Soong usa variantes de imagem para dividir
dependências de build. Os módulos nativos (/build/soong/cc) podem mudar os módulos de processo do sistema para a variante principal e os módulos de processo do fornecedor para a variante do fornecedor. Um módulo em uma variante de imagem não pode ser vinculado a outros módulos em uma variante de imagem diferente.
No Android 12 ou mais recente, um módulo do sistema com
vendor_available: true cria uma variante do fornecedor além da variante
principal. Para criar uma variante de produto, o product_available: true precisa ser definido. Algumas bibliotecas VNDK sem product_available: true não estão disponíveis para módulos de produtos.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-27 UTC."],[],[],null,["# Partitions overview\n\nAndroid devices contain several *partitions* or specific sections of storage\nspace used to contain specific parts of the device's software. Each partition\ncontains a *partition image* (an IMG file) or snapshot of all the software for\nthe partition. Figure 1 shows the layout of core partitions on a device:\n\n**Figure 1.** Layout of core partitions.\n\nPartitions are classified in three categories:\n\n- *System partitions* are partitions that are updated when updating the OS\n and other features. The `system`, `boot`, and `init_boot` are core system\n partitions.\n\n- *Vendor partitions* contain device and hardware-specific code that might\n never be updated after initial release. The `vendor`, `vendor_boot`, and `odm`\n partitions are core vendor partitions.\n\n- *Nonupdatable partitions* are partitions whose contents are either not updated\n or updated with user data.\n\nCode in system and vendor partitions can interact using a stable interface\ncalled the *vendor interface (VINTF)*.\n| **Note:** The separation of system partitions from vendor partitions was part of an Android 11 effort called *Project Treble*. With this architecture, you can update a device's operating system and apps without updating any of hardware-specific code.\n\n### System partitions\n\nFollowing is a list of all system partitions and their use:\n\n- **`boot` partition.** This partition contains a Generic Kernel Image (GKI).\n This partition also contains the generic ramdisk in devices launched in\n Android 12 and lower. For further information on generic ramdisk, see\n [Generic ramdisk image contents](/docs/core/architecture/partitions/generic-boot#generic-boot-ramdisk-image-contents).\n\n- **`init_boot` partition (Android 13 and higher).** This partition contains a\n generic ramdisk. In Android 11 and 12, the generic ramdisk is in the\n `boot` partition.\n\n- **`system` partition.** This partition contains the system image used\n for OEM products.\n\n- **`system_ext` partition.** This partition contains system resources and\n proprietary system modules that extend the common system image in the `system`\n partition.\n\n | **Note:** *Single system image (SSI)* refers to a file, such as a zip file that contains the images of the `system` and `system_ext` partitions and reuses those images across a set of target devices. For further information on SSI, see [Android shared system image](/docs/core/architecture/partitions/shared-system-image).\n- **`system_dlkm` partition.** This partition contains GKI modules. For further\n information on this partition, see [Implement a GKI module partition](/docs/core/architecture/partitions/gki-partitions).\n\n- **`product` partition.** This partition can contain product-specific modules\n that aren't bundled with any other partitions.\n\n | **Note:** The [*Vendor Native Development Kit (VNDK)*](/docs/core/architecture/vndk) is a set of libraries installed in the `system` partition and designed exclusively for vendors to implement their HALs. The `product` and `vendor` partitions can link to VNDK libraries in the `system` partition, but can't link to other libraries in the `system` partition.\n- **`pvmfw` partition.** This partition stores the Protected Virtual Machine\n Firmware (pvmfw) which is the first code that runs in protected VMs. For more\n information, see [Protected Virtual Machine Firmware](https://android.googlesource.com/platform/packages/modules/Virtualization/+/refs/heads/android16-release/guest/pvmfw/README.md).\n\n- **`generic_bootloader` partition.** This partition contains the generic bootloader.\n\n### Vendor partitions\n\nFollowing is a list of all vendor partitions and their use:\n\n- **`vendor_boot` partition.** This partition contains vendor-specific boot\n code. For more information, see [Vendor boot partitions](/docs/core/architecture/partitions/vendor-boot-partitions).\n\n- **`recovery` partition.** This partition stores the recovery image, which is\n booted during the over-the-air (OTA) update process. Devices that support\n seamless updates can store the recovery images as a ramdisk contained in the\n `boot` or `init_boot` image. For more information on seamless updates,\n see [A/B (seamless) updates](/docs/core/ota/ab).\n\n- **`misc` partition.** This partition is used by the recovery partition and is\n 4 KB or larger.\n\n- **`vbmeta` partition.** This partition contains the Verified Boot information\n for all of the partitions. This information verifies that the images installed\n in each partition is trusted. For further information on\n Verified Boot, see\n [Verified Boot](/docs/security/features/verifiedboot).\n\n- **`vendor` partition.** This partition contains any binary that is vendor\n specific and not generic enough to distribute to AOSP.\n\n | **Note:** The [*Vendor Native Development Kit (VNDK)*](/docs/core/architecture/vndk) is a set of libraries installed in the `system` partition and designed exclusively for vendors to implement their HALs. The `product` and `vendor` partitions can link to VNDK libraries in the `system` partition, but can't link to other libraries in the `system` partition.\n- **`vendor_dlkm` partition.** This partition contains vendor\n kernel modules. By storing vendor kernel modules in this partition\n instead of the `vendor` partition, you can update kernel\n modules without updating the `vendor` partition. For more information, see\n [Vendor and ODM DKLM partitions](/docs/core/architecture/partitions/vendor-odm-dlkm-partition).\n\n- **`odm` partition.** This partition contains original design manufacturer\n (ODM)\n customizations to system-on-chip (SoC) vendor board-support packages (BSPs).\n Such customizations enable ODMs to replace or customize SoC components, and\n implement kernel modules for board-specific components, daemons, and\n ODM-specific features on hardware abstraction layers (HALs). This partition is\n optional. Typically this partition is used to contain customizations so that\n devices can\n use a single vendor image for multiple hardware SKUs. For more information,\n see [ODM partitions](/docs/core/architecture/bootloader/partitions/odm-partitions).\n\n- **`odm_dlkm` partition.** This partition is dedicated to storing ODM kernel\n modules. By storing ODM kernel modules in the this partition, instead of\n the `odm` partition, you can update ODM kernel modules without updating the\n `odm` partition. For more information, see\n [Vendor and ODM DKLM partitions](/docs/core/architecture/partitions/vendor-odm-dlkm-partition).\n\n- **`radio` partition.** This partition contains the radio image and is needed\n only for devices that include a radio with radio-specific software in a\n dedicated partition.\n\n| **Note:** Devices that support seamless updates need two partitions, referred to as *slots* (slot A and slot B) for the `boot`, `system`, `vendor`, and `radio` partitions. For further information, see [Partition selection (slots)](/docs/core/ota/ab#slots).\n\n### Nonupdatable partitions\n\nFollowing is a list of all nonupdatable partitions and their use:\n\n- **`cache` partition.** This partition contains temporary data and is optional\n if your device uses seamless updates. This partition doesn't need to be\n writable from the bootloader, but needs to be erasable. The partition\n size depends on the device type and the availability of space on `userdata`;\n typically, 50 to 100 MB is sufficient.\n\n- **`userdata` partition.** This partition contains user-installed apps and\n data, including customization data.\n\n- **`metadata` partition.** If your device uses [metadata encryption](/docs/security/features/encryption/metadata),\n this partition contains the metadata encryption key. The size of this\n partition is 16 MB or larger, it isn't encrypted, and its data isn't\n snapshotted. This partition is erased when the device is factory reset.\n\nPartition update rules and recommendations\n------------------------------------------\n\nWe recommend updating all system partitions as a whole\nand all vendor partitions as another whole. By updating the set of partitions as\na whole, you can test to verify the interfaces between images in each partition\nremain stable.\n\nRegardless of how you update your partitions, the following partitions must\nbe updated due to tightly coupled dependencies and lack of stable APIs:\n\n- The `boot` and `system_dlkm` partitions\n- the `init_boot`, `system`, `system_ext`, and `product` partitions\n\n| **Note:** If all interfaces between the `product` partition and other system partitions have stable ABIs, you can update the `product` partition independently. For furthe information, see [Maintain ABIs between partitions](/docs/core/architecture/partitions/product-partitions#maintaining-abis).\n\nDynamic partitions\n------------------\n\nDevices running Android 11 and higher can support\ndynamic partitions, which are a userspace partitioning system for Android that\nlets you create, resize, or destroy partitions during over-the-air (OTA)\nupdates. For more information, see [Dynamic partitions](/docs/core/ota/dynamic_partitions).\n\n### Soong product variants\n\nThe [Soong](/docs/setup/build) build system uses image variants to split\nbuild dependencies. Native modules (`/build/soong/cc`) can mutate system\nprocess modules to the core variant and vendor process modules to the\nvendor variant; a module in one image variant can't link to other modules in\na different image variant.\n\nIn Android 12 or higher, a system module with\n`vendor_available: true` creates a vendor variant in addition to the core\nvariant. To create a product variant, `product_available: true` must be\ndefined. Some VNDK libraries without `product_available: true` aren't\navailable to product modules."]]
