27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Android cihazlarda, cihaz yazılımının belirli bölümlerini içeren depolama alanının birkaç bölümü veya belirli kısımları bulunur. Her bölüm, bölüm resmi (IMG dosyası) veya bölümdeki tüm yazılımların anlık görüntüsünü içerir. Şekil 1'de bir cihazdaki temel bölümlerin düzeni gösterilmektedir:
1.şekil Çekirdek bölümlerin düzeni.
Bölümler üç kategoride sınıflandırılır:
Sistem bölümleri, işletim sistemi ve diğer özellikler güncellenirken güncellenen bölümlerdir. system, boot ve init_boot temel sistem bölümleridir.
Satıcı bölümleri, ilk yayınlandıktan sonra hiçbir zaman güncellenmeyebilecek cihaza ve donanıma özgü kod içerir. vendor, vendor_boot ve odm
bölümleri temel satıcı bölümleridir.
Güncellenemeyen bölümler, içerikleri güncellenmeyen veya kullanıcı verileriyle güncellenen bölümlerdir.
Sistem ve tedarikçi bölümlerindeki kodlar, tedarikçi arayüzü (VINTF) adı verilen sabit bir arayüzü kullanarak etkileşime geçebilir.
Sistem bölümleri
Aşağıda, tüm sistem bölümleri ve bunların kullanım alanları listelenmiştir:
boot bölümü. Bu bölümde Genel Çekirdek Görüntüsü (GKI) bulunur.
Bu bölüm, Android 12 ve önceki sürümlerde başlatılan cihazlardaki genel ramdisk'i de içerir. Genel ramdisk hakkında daha fazla bilgi için Genel ramdisk görüntü içerikleri başlıklı makaleyi inceleyin.
init_boot bölümü (Android 13 ve sonraki sürümler). Bu bölüm genel bir ramdisk içeriyor. Android 11 ve 12'de genel ramdisk, boot bölümündedir.
system bölümü. Bu bölüm, OEM ürünlerinde kullanılan sistem görüntüsünü içerir.
system_ext bölümü. Bu bölüm, sistem kaynaklarını ve system bölümündeki ortak sistem görüntüsünü genişleten tescilli sistem modüllerini içerir.
system_dlkm bölümü. Bu bölüm GKI modüllerini içerir. Bu bölüm hakkında daha fazla bilgi için GKI modül bölümü uygulama başlıklı makaleyi inceleyin.
product bölümü. Bu bölüm, başka bölümlerle birlikte paketlenmemiş ürüne özel modüller içerebilir.
pvmfw bölümü. Bu bölüm, korumalı sanal makinelerde çalışan ilk kod olan Protected Virtual Machine Firmware'i (pvmfw) depolar. Daha fazla bilgi için Protected Virtual Machine Firmware (Korumalı Sanal Makine Donanım Yazılımı) başlıklı makaleyi inceleyin.
generic_bootloader bölümü. Bu bölüm, genel önyükleyiciyi içerir.
Tedarikçi bölümleri
Aşağıda, tüm satıcı bölümleri ve bunların kullanım alanları listelenmiştir:
vendor_boot bölümü. Bu bölüm, satıcıya özgü önyükleme kodu içerir. Daha fazla bilgi için Sağlayıcı önyükleme bölümleri başlıklı makaleyi inceleyin.
recovery bölümü. Bu bölüm, kablosuz (OTA) güncelleme işlemi sırasında başlatılan kurtarma görüntüsünü depolar. Sorunsuz güncellemeleri destekleyen cihazlar, kurtarma görüntülerini boot veya init_boot görüntüsünde bulunan bir ramdisk olarak depolayabilir. Sorunsuz güncellemeler hakkında daha fazla bilgi için A/B (sorunsuz) güncellemeler başlıklı makaleyi inceleyin.
misc bölümü. Bu bölüm, kurtarma bölümü tarafından kullanılır ve 4 KB veya daha büyüktür.
vbmeta bölümü. Bu bölüm, tüm bölümlerin Doğrulanmış Önyükleme bilgilerini içerir. Bu bilgiler, her bölüme yüklenen görüntülerin güvenilir olduğunu doğrular. Doğrulanmış Başlatma hakkında daha fazla bilgi için Doğrulanmış Başlatma başlıklı makaleyi inceleyin.
vendor bölümü. Bu bölüm, tedarikçiye özel olan ve AOSP'ye dağıtılacak kadar genel olmayan tüm ikili dosyaları içerir.
vendor_dlkm bölümü. Bu bölümde, satıcı çekirdek modülleri yer alır. Tedarikçi çekirdek modüllerini vendor bölümü yerine bu bölümde depolayarak vendor bölümünü güncellemeden çekirdek modüllerini güncelleyebilirsiniz. Daha fazla bilgi için Tedarikçi ve ODM DKLM bölümleri konusuna bakın.
odm bölümü. Bu bölüm, çip üzerinde sistem (SoC) satıcısı kart destek paketlerinde (BSP'ler) özgün tasarım üreticisi (ODM) özelleştirmelerini içerir.
Bu tür özelleştirmeler, ODM'lerin SoC bileşenlerini değiştirmesine veya özelleştirmesine ve donanım soyutlama katmanlarında (HAL'ler) kart özel bileşenleri, arka plan programları ve ODM'ye özel özellikler için çekirdek modüllerini uygulamasına olanak tanır. Bu bölüm isteğe bağlıdır. Bu bölüm genellikle özelleştirmeleri içermek için kullanılır. Böylece cihazlar, birden fazla donanım SKU'su için tek bir satıcı resmi kullanabilir. Daha fazla bilgi için ODM bölümleri başlıklı makaleyi inceleyin.
odm_dlkm bölümü. Bu bölüm, ODM çekirdek modüllerini depolamaya ayrılmıştır. ODM çekirdek modüllerini odm bölümü yerine bu bölümde depolayarak odm bölümünü güncellemeden ODM çekirdek modüllerini güncelleyebilirsiniz. Daha fazla bilgi için Tedarikçi ve ODM DKLM bölümleri konusuna bakın.
radio bölümü. Bu bölüm, radyo görüntüsünü içerir ve yalnızca özel bir bölümde radyoya özel yazılım içeren radyo bulunan cihazlar için gereklidir.
Güncellenemeyen bölümler
Aşağıda, güncellenemeyen tüm bölümler ve kullanımları listelenmiştir:
cache bölümü. Bu bölüm geçici veriler içerir ve cihazınızda sorunsuz güncellemeler kullanılıyorsa isteğe bağlıdır. Bu bölümün bootloader'dan yazılabilir olması gerekmez ancak silinebilir olması gerekir. Bölüm boyutu, cihaz türüne ve userdata'daki alanın kullanılabilirliğine bağlıdır. Genellikle 50-100 MB yeterlidir.
userdata bölümü. Bu bölümde, kullanıcı tarafından yüklenen uygulamalar ve özelleştirme verileri de dahil olmak üzere veriler bulunur.
metadata bölümü. Cihazınızda meta veri şifreleme kullanılıyorsa bu bölüm meta veri şifreleme anahtarını içerir. Bu bölümün boyutu 16 MB veya daha büyüktür, şifrelenmemiştir ve verilerinin anlık görüntüsü alınmamıştır. Bu bölüm, cihaz fabrika ayarlarına sıfırlandığında silinir.
Bölüm güncelleme kuralları ve önerileri
Tüm sistem bölümlerini bir bütün olarak, tüm satıcı bölümlerini ise başka bir bütün olarak güncellemenizi öneririz. Bölüm grubunu bir bütün olarak güncelleyerek her bölümdeki resimler arasındaki arayüzlerin sabit kaldığını doğrulamak için test yapabilirsiniz.
Bölümlerinizi nasıl güncellediğinizden bağımsız olarak, sıkıca bağlı bağımlılıklar ve kararlı API'lerin olmaması nedeniyle aşağıdaki bölümlerin güncellenmesi gerekir:
boot ve system_dlkm bölümleri
init_boot, system, system_ext ve product bölümleri
Dinamik bölümler
Android 11 ve sonraki sürümlerin yüklü olduğu cihazlar, kablosuz (OTA) güncellemeleri sırasında bölümleri oluşturmanıza, yeniden boyutlandırmanıza veya yok etmenize olanak tanıyan, Android için bir kullanıcı alanı bölümleme sistemi olan dinamik bölümleri destekleyebilir. Daha fazla bilgi için Dinamik bölümler başlıklı makaleyi inceleyin.
Soong ürün varyantları
Soong derleme sistemi, derleme bağımlılıklarını bölmek için görüntü varyantlarını kullanır. Yerel modüller (/build/soong/cc), sistem süreci modüllerini temel varyanta, satıcı süreci modüllerini ise satıcı varyantına dönüştürebilir. Bir resim varyantındaki modül, farklı bir resim varyantındaki diğer modüllere bağlanamaz.
Android 12 veya sonraki sürümlerde, vendor_available: true içeren bir sistem modülü, temel varyanta ek olarak bir satıcı varyantı oluşturur. Ürün varyantı oluşturmak için product_available: true tanımlanmalıdır. product_available: true içermeyen bazı VNDK kitaplıkları, ürün modüllerinde kullanılamaz.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
