Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Устройства Android содержат несколько разделов или отдельных областей дискового пространства, используемых для хранения определённых частей программного обеспечения устройства. Каждый раздел содержит образ раздела (файл IMG) или снимок всего программного обеспечения для этого раздела. На рисунке 1 показана структура основных разделов на устройстве:
Рисунок 1. Схема расположения основных разделов.
Разделы подразделяются на три категории:
Системные разделы — это разделы, которые обновляются при обновлении ОС и других компонентов. system , boot и init_boot являются основными системными разделами.
Разделы поставщика содержат код, специфичный для устройств и оборудования, который может никогда не обновляться после первоначального выпуска. Разделы vendor , vendor_boot и odm являются основными разделами поставщика.
Необновляемые разделы — это разделы, содержимое которых либо не обновляется, либо обновляется пользовательскими данными.
Код в системных разделах и разделах поставщика может взаимодействовать с помощью стабильного интерфейса, называемого интерфейсом поставщика (VINTF) .
Системные разделы
Ниже приведен список всех системных разделов и их использование:
boot раздел. Этот раздел содержит образ ядра Generic Kernel Image (GKI). Этот раздел также содержит универсальный RAM-диск на устройствах с Android 12 и более ранними версиями. Подробнее о универсальном RAM-диске см. в разделе «Содержимое образа универсального RAM-диска» .
Раздел init_boot (Android 13 и выше). Этот раздел содержит универсальный RAM-диск. В Android 11 и 12 универсальный RAM-диск находится в boot разделе.
system раздел. Этот раздел содержит образ системы, используемый для OEM-продуктов.
Раздел system_ext . Этот раздел содержит системные ресурсы и фирменные системные модули, расширяющие общий образ системы в system разделе.
Раздел product . Этот раздел может содержать модули, специфичные для продукта, которые не объединены с другими разделами.
Раздел pvmfw . В этом разделе хранится прошивка защищённой виртуальной машины (pvmfw), которая является первым кодом, запускаемым в защищённых виртуальных машинах. Подробнее см. в разделе «Прошивка защищённой виртуальной машины» .
Раздел generic_bootloader . Этот раздел содержит универсальный загрузчик.
Разделы поставщика
Ниже приведен список всех разделов поставщиков и их использование:
Раздел vendor_boot . Этот раздел содержит загрузочный код, специфичный для производителя. Подробнее см. в разделе Загрузочные разделы производителя .
Раздел recovery . В этом разделе хранится образ восстановления, который загружается во время беспроводного обновления (OTA). Устройства, поддерживающие бесшовное обновление, могут хранить образы восстановления в виде RAM-диска, содержащегося в образе boot или init_boot . Подробнее о бесшовных обновлениях см. в разделе A/B (бесшовные) обновления .
Раздел misc . Этот раздел используется разделом восстановления и имеет размер 4 КБ или больше.
Раздел vbmeta . Этот раздел содержит информацию о проверенной загрузке для всех разделов. Эта информация подтверждает, что образы, установленные в каждом разделе, являются доверенными. Подробнее о проверенной загрузке см. в разделе «Проверенная загрузка» .
Раздел vendor . Этот раздел содержит все двоичные файлы, специфичные для конкретного поставщика и недостаточно универсальные для распространения через AOSP.
Раздел vendor_dlkm . Этот раздел содержит модули ядра поставщика. Разместив модули ядра поставщика в этом разделе, а не в разделе vendor , вы сможете обновлять модули ядра без обновления раздела vendor . Подробнее см. в разделе Разделы DKLM поставщика и ODM .
Раздел odm . Этот раздел содержит настройки, выполненные производителем оригинального дизайна (ODM) для пакетов поддержки плат (BSP) поставщика систем на кристалле (SoC). Такие настройки позволяют ODM заменять или настраивать компоненты SoC, а также реализовывать модули ядра для компонентов, специфичных для конкретной платы, демонов и функций, специфичных для ODM, на уровнях аппаратной абстракции (HAL). Этот раздел необязателен. Обычно он используется для хранения настроек, позволяющих устройствам использовать один образ поставщика для нескольких аппаратных SKU. Подробнее см. в разделе ODM .
Раздел odm_dlkm . Этот раздел предназначен для хранения модулей ядра ODM. Разместив модули ядра ODM в этом разделе, а не в разделе odm , вы можете обновлять модули ядра ODM, не обновляя раздел odm . Подробнее см. в разделе «Разделы Vendor и ODM DKLM» .
Раздел radio . Этот раздел содержит образ радио и необходим только для устройств, в которых радио с программным обеспечением для радио находится в специальном разделе.
Необновляемые разделы
Ниже приведен список всех необновляемых разделов и их использование:
Раздел cache . Этот раздел содержит временные данные и необязателен, если ваше устройство использует бесперебойные обновления. Этот раздел не обязательно должен быть доступен для записи из загрузчика, но должен быть стираемым. Размер раздела зависит от типа устройства и наличия свободного места под userdata ; обычно достаточно 50–100 МБ.
Раздел userdata . Этот раздел содержит установленные пользователем приложения и данные, включая данные настроек.
Раздел metadata . Если ваше устройство использует шифрование метаданных , этот раздел содержит ключ шифрования метаданных. Размер этого раздела составляет 16 МБ или больше, он не зашифрован, и его данные не сохраняются в моментальном снимке. Этот раздел стирается при сбросе настроек устройства до заводских.
Правила и рекомендации по обновлению разделов
Мы рекомендуем обновить все системные разделы как единое целое, а также все разделы поставщика как единое целое. Обновив набор разделов как единое целое, вы сможете проверить стабильность интерфейсов между образами в каждом разделе.
Независимо от способа обновления разделов, следующие разделы необходимо обновить из-за тесно связанных зависимостей и отсутствия стабильных API:
Разделы boot и system_dlkm
разделы init_boot , system , system_ext и product
Динамические разделы
Устройства под управлением Android 11 и более поздних версий поддерживают динамические разделы — систему разбиения пользовательского пространства Android, позволяющую создавать, изменять размер и удалять разделы во время беспроводных обновлений (OTA). Подробнее см. в разделе Динамические разделы .
Варианты продукта Soon
Система сборки Soong использует варианты образов для разделения зависимостей сборки. Нативные модули ( /build/soong/cc ) могут преобразовывать модули системных процессов в вариант ядра, а модули процессов поставщика — в вариант поставщика; модуль в одном варианте образа не может быть связан с другими модулями в другом варианте образа.
В Android 12 и более поздних версиях системный модуль с vendor_available: true создаёт вариант поставщика в дополнение к основному варианту. Для создания варианта продукта необходимо определить параметр product_available: true . Некоторые библиотеки VNDK без product_available: true недоступны для модулей продукта.
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-29 UTC.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2025-07-29 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."]]
