Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Urządzenia z Androidem zawierają kilka partycji, czyli określonych sekcji pamięci, które są używane do przechowywania konkretnych części oprogramowania urządzenia. Każda partycja zawiera obraz partycji (plik IMG) lub migawkę całego oprogramowania dla tej partycji. Rysunek 1 przedstawia układ podstawowych partycji na urządzeniu:
Rysunek 1. Układ podstawowych partycji.
Partycje są podzielone na 3 kategorie:
Partycje systemowe to partycje, które są aktualizowane podczas aktualizacji systemu operacyjnego i innych funkcji. Partycje system, boot i init_boot to podstawowe partycje systemowe.
Partycje dostawcy zawierają kod specyficzny dla urządzenia i sprzętu, który po początkowym wydaniu może nigdy nie zostać zaktualizowany. Partycje vendor, vendor_boot i odm to podstawowe partycje dostawcy.
Partycje, których nie można aktualizować to partycje, których zawartość nie jest aktualizowana lub jest aktualizowana danymi użytkownika.
Kod w partycjach systemowych i dostawcy może wchodzić w interakcje za pomocą stabilnego interfejsu zwanego interfejsem dostawcy (VINTF).
Partycje systemowe
Poniżej znajdziesz listę wszystkich partycji systemowych i ich zastosowań:
boot partycji. Ta partycja zawiera ogólny obraz jądra (GKI).
Ta partycja zawiera też ogólny dysk RAM w urządzeniach z Androidem 12 i starszym. Więcej informacji o ogólnym dysku RAM znajdziesz w sekcji Zawartość ogólnego obrazu dysku RAM.
partycja init_boot (Android 13 lub nowszy). Ta partycja zawiera ogólny dysk RAM. W Androidzie 11 i 12 ogólny dysk RAM znajduje się w partycji boot.
system partycji. Ta partycja zawiera obraz systemu używany w przypadku produktów OEM.
system_ext partycji. Ta partycja zawiera zasoby systemowe i własne moduły systemowe, które rozszerzają wspólny obraz systemu w partycji system.
system_dlkm partycji. Ta partycja zawiera moduły GKI. Więcej informacji o tej partycji znajdziesz w artykule Implementowanie partycji modułu GKI.
product partycji. Ta partycja może zawierać moduły specyficzne dla produktu, które nie są powiązane z żadnymi innymi partycjami.
pvmfw partycji. Ta partycja przechowuje chronione oprogramowanie sprzętowe maszyny wirtualnej (pvmfw), które jest pierwszym kodem uruchamianym na chronionych maszynach wirtualnych. Więcej informacji znajdziesz w artykule Oprogramowanie układowe chronionej maszyny wirtualnej.
generic_bootloader partycji. Ta partycja zawiera ogólny program rozruchowy.
Partycje dostawcy
Poniżej znajdziesz listę wszystkich partycji dostawców i ich zastosowań:
vendor_boot partycji. Ta partycja zawiera kod rozruchowy specyficzny dla dostawcy. Więcej informacji znajdziesz w artykule Partycje rozruchowe dostawcy.
recovery partycji. Ta partycja zawiera obraz przywracania, który jest uruchamiany podczas procesu aktualizacji bezprzewodowej (OTA). Urządzenia obsługujące bezproblemowe aktualizacje mogą przechowywać obrazy odzyskiwania jako dysk RAM zawarty w obrazie boot lub init_boot. Więcej informacji o automatycznych aktualizacjach znajdziesz w artykule Aktualizacje A/B (automatyczne).
misc partycji. Ta partycja jest używana przez partycję odzyskiwania i ma rozmiar co najmniej 4 KB.
vbmeta partycji. Ta partycja zawiera informacje o zweryfikowanym rozruchu
dla wszystkich partycji. Te informacje potwierdzają, że obrazy zainstalowane w każdej partycji są zaufane. Więcej informacji o weryfikacji podczas uruchamiania znajdziesz w artykule Weryfikacja podczas uruchamiania.
vendor partycji. Ta partycja zawiera wszystkie pliki binarne, które są specyficzne dla dostawcy i nie są wystarczająco ogólne, aby można je było rozpowszechniać w ramach AOSP.
vendor_dlkm partycji. Ta partycja zawiera moduły jądra dostawcy. Dzięki przechowywaniu modułów jądra dostawcy na tej partycji zamiast na partycji vendor możesz aktualizować moduły jądra bez aktualizowania partycji vendor. Więcej informacji znajdziesz w artykule Partycje DKLM dostawcy i producenta ODM.
odm partycji. Ta partycja zawiera dostosowania producenta oryginalnego sprzętu (ODM) do pakietów obsługi płyty (BSP) dostawcy układu SOC.
Takie dostosowania umożliwiają producentom ODM zastępowanie lub dostosowywanie komponentów SoC oraz wdrażanie modułów jądra dla komponentów specyficznych dla płyty, demonów i funkcji specyficznych dla ODM w warstwach abstrakcji sprzętu (HAL). Ta partycja jest opcjonalna. Zwykle ta partycja zawiera dostosowania, dzięki czemu urządzenia mogą używać jednego obrazu dostawcy w przypadku wielu wersji sprzętowych. Więcej informacji znajdziesz w artykule Partycje ODM.
odm_dlkm partycji. Ta partycja jest przeznaczona do przechowywania modułów jądra ODM. Przechowywanie modułów jądra ODM w tej partycji zamiast w partycji odm umożliwia aktualizowanie modułów jądra ODM bez aktualizowania partycji odm. Więcej informacji znajdziesz w artykule Partycje DKLM dostawcy i producenta ODM.
radio partycji. Ta partycja zawiera obraz radia i jest potrzebna tylko w przypadku urządzeń, które mają radio z oprogramowaniem przeznaczonym do radia na osobnej partycji.
Partycje, których nie można aktualizować
Poniżej znajdziesz listę wszystkich partycji, których nie można aktualizować, i ich zastosowania:
cache partycji. Ta partycja zawiera dane tymczasowe i jest opcjonalna, jeśli urządzenie korzysta z bezproblemowych aktualizacji. Ta partycja nie musi być zapisywalna z poziomu programu rozruchowego, ale musi być usuwalna. Rozmiar partycji zależy od typu urządzenia i dostępności miejsca na userdata. Zwykle wystarczy 50–100 MB.
userdata partycji. Ta partycja zawiera zainstalowane przez użytkownika aplikacje i dane, w tym dane dostosowywania.
metadata partycji. Jeśli urządzenie korzysta z szyfrowania metadanych, ta partycja zawiera klucz szyfrowania metadanych. Rozmiar tej partycji wynosi co najmniej 16 MB, nie jest ona zaszyfrowana, a jej dane nie są zapisywane w postaci migawek. Ta partycja jest usuwana, gdy urządzenie jest przywracane do ustawień fabrycznych.
Reguły i rekomendacje dotyczące aktualizacji partycji
Zalecamy aktualizowanie wszystkich partycji systemowych jako całości i wszystkich partycji dostawcy jako kolejnej całości. Aktualizując zestaw partycji jako całość, możesz sprawdzić, czy interfejsy między obrazami w każdej partycji pozostają stabilne.
Niezależnie od tego, jak zaktualizujesz partycje, musisz zaktualizować te partycje ze względu na silnie powiązane zależności i brak stabilnych interfejsów API:
Partycje boot i system_dlkm
partycje init_boot, system, system_ext i product;
Partycje dynamiczne
Urządzenia z Androidem 11 i nowszym mogą obsługiwać partycje dynamiczne, czyli system partycjonowania przestrzeni użytkownika w Androidzie, który umożliwia tworzenie, zmianę rozmiaru i usuwanie partycji podczas aktualizacji bezprzewodowych (OTA). Więcej informacji znajdziesz w artykule Partycje dynamiczne.
Wersje produktu Soong
System kompilacji Soong używa wariantów obrazów do dzielenia zależności kompilacji. Moduły natywne (/build/soong/cc) mogą zmieniać moduły procesów systemowych na wariant podstawowy, a moduły procesów dostawcy na wariant dostawcy. Moduł w jednym wariancie obrazu nie może łączyć się z innymi modułami w innym wariancie obrazu.
W Androidzie 12 lub nowszym moduł systemowyvendor_available: true tworzy wariant dostawcy oprócz wariantu podstawowego. Aby utworzyć wersję produktu, musisz zdefiniować atrybut product_available: true. Niektóre biblioteki VNDK bez product_available: true nie są dostępne dla modułów produktu.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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."]]
