קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
מכשירי Android מכילים כמה מחיצות או קטעים ספציפיים של נפח האחסון, שמשמשים לאחסון חלקים ספציפיים של תוכנת המכשיר. כל מחיצה מכילה קובץ אימג' של מחיצה (קובץ IMG) או קובץ snapshot של כל התוכנות במחיצה. תרשים 1 מציג את הפריסה של מחיצות הליבה במכשיר:
איור 1. הפריסה של המחיצות הליבה.
המחיצות מחולקות לשלוש קטגוריות:
מחיצות מערכת הן מחיצות שמתעדכנות כשמעדכנים את מערכת ההפעלה ותכונות אחרות. system, boot ו-init_boot הם מחיצות ליבה של המערכת.
מחיצות של ספקים מכילות קוד ספציפי למכשיר ולחומרה, שיכול להיות שלא יתעדכן אף פעם אחרי ההשקה הראשונית. המחיצות vendor, vendor_boot ו-odm הן מחיצות ליבה של ספקים.
מחיצות שלא ניתן לעדכן הן מחיצות שהתוכן שלהן לא מתעדכן או מתעדכן בנתוני משתמשים.
קוד במחיצות של מערכת ושל ספק יכול לקיים אינטראקציה באמצעות ממשק יציב שנקרא ממשק הספק (VINTF).
מחיצות מערכת
בהמשך מופיעה רשימה של כל המחיצות במערכת והשימוש שלהן:
מחיצה boot. המחיצה הזו מכילה קובץ Generic Kernel Image (GKI).
המחיצה הזו מכילה גם את ה-ramdisk הגנרי במכשירים שהושקו עם Android 12 וגרסאות קודמות. מידע נוסף על דיסק RAM גנרי זמין במאמר תוכן של קובץ אימג' של דיסק RAM גנרי.
מחיצה init_boot (Android מגרסה 13 ואילך). המחיצה הזו מכילה דיסק RAM כללי. ב-Android 11 וב-Android 12, ה-ramdisk הגנרי נמצא במחיצה boot.
מחיצה system המחיצה הזו מכילה את קובץ האימג' של המערכת שמשמש למוצרים של יצרני ציוד מקורי.
מחיצה system_ext. המחיצה הזו מכילה משאבי מערכת ומודולים ייעודיים למערכת שמרחיבים את קובץ האימג' המשותף של המערכת במחיצה system.
מחיצה system_dlkm המחיצה הזו מכילה מודולים של GKI. למידע נוסף על המחיצה הזו, ראו הטמעת מחיצה של מודול GKI.
מחיצה product. המחיצה הזו יכולה להכיל מודולים ספציפיים למוצרים שלא נכללים בחבילות של מחיצות אחרות.
מחיצה pvmfw. במחיצה הזו מאוחסן הקושחה של המכונה הווירטואלית המוגנת (pvmfw), שהוא הקוד הראשון שפועל במכונות וירטואליות מוגנות. למידע נוסף, ראו קושחה מוגנת של מכונות וירטואליות.
מחיצה generic_bootloader. המחיצה הזו מכילה את מנהל האתחול הגנרי.
מחיצות של ספקים
בהמשך מופיעה רשימה של כל המחיצות של הספקים והשימוש שלהן:
מחיצה vendor_boot. המחיצה הזו מכילה קוד אתחול ספציפי לספק. מידע נוסף זמין במאמר מחיצות אתחול של ספקים.
מחיצה recovery. במחיצה הזו מאוחסנת קובץ האימג' לשחזור, שמופעל במהלך תהליך העדכון האווירי (OTA). במכשירים שתומכים בעדכונים חלקים, אפשר לאחסן את קובצי האימג' לשחזור כ-ramdisk שמכיל את קובץ האימג' boot או init_boot. למידע נוסף על עדכונים ללא הפרעה, ראו עדכוני A/B (ללא הפרעה).
מחיצה vbmeta. המחיצה הזו מכילה את המידע של Verified Boot לכל המחיצות. המידע הזה מאמת שהתמונות שמותקנות בכל מחיצה מהימנות. למידע נוסף על אתחול מאומת, ראו אתחול מאומת.
מחיצה vendor המחיצה הזו מכילה כל קובץ בינארי שספציפי לספק ולא כללי מספיק כדי להפיץ אותו ל-AOSP.
מחיצה vendor_dlkm. המחיצה הזו מכילה מודולים של ליבה של ספקים. אחסון מודולי הליבה של הספק במחיצה הזו במקום במחיצה vendor מאפשר לעדכן את מודולי הליבה בלי לעדכן את המחיצה vendor. למידע נוסף, ראו מחיצות DKLM של ספקים ו-ODM.
מחיצה odm המחיצה הזו מכילה התאמות של יצרן העיצוב המקורי (ODM) לחבילות התמיכה של לוחות של ספקי מערכת על שבב (SoC).
התאמות אישיות כאלה מאפשרות ליצרני ציוד מקורי להחליף או להתאים אישית רכיבי SoC, ולהטמיע מודולים של ליבה לרכיבים ספציפיים ללוח, לדיימונים ולתכונות ספציפיות ליצרן ציוד מקורי בשכבות הפשטה של החומרה (HAL). המחיצה הזו היא אופציונלית. בדרך כלל, המחיצה הזו משמשת לצורך אחסון של התאמות אישיות, כדי שאפשר יהיה להשתמש בתמונת ספק אחת במספר מק"טים של חומרה. למידע נוסף, ראו מחיצות ODM.
מחיצה odm_dlkm. המחיצה הזו מיועדת לאחסון מודולים של ליבה של ODM. אחסון מודולי הליבה של ODM במחיצה הזו, במקום במחיצה odm, מאפשר לעדכן מודולי ליבה של ODM בלי לעדכן את המחיצה odm. למידע נוסף, ראו מחיצות DKLM של ספקים ו-ODM.
מחיצה radio. המחיצה הזו מכילה את קובץ האימג' של הרדיו, והיא נדרשת רק במכשירים שכוללים רדיו עם תוכנה ספציפית לרדיו במחיצה ייעודית.
מחיצות שלא ניתן לעדכן
בהמשך מופיעה רשימה של כל המחיצות שלא ניתן לעדכן ואת השימוש שלהן:
מחיצה cache המחיצה הזו מכילה נתונים זמניים והיא אופציונלית אם במכשיר שלכם מופעלים עדכונים חלקים. אין צורך שאפשר יהיה לכתוב במחיצה הזו מ-bootloader, אבל צריך שאפשר יהיה למחוק אותה. גודל המחיצה תלוי בסוג המכשיר ובנפח האחסון הזמין ב-userdata. בדרך כלל, מספיקים 50 עד 100MB.
מחיצה userdata המחיצה הזו מכילה אפליקציות ונתונים שהמשתמשים התקינו, כולל נתוני התאמה אישית.
מחיצה metadata. אם במכשיר שלכם מופעלת הצפנת מטא-נתונים, המחיצה הזו מכילה את מפתח ההצפנה של המטא-נתונים. הגודל של המחיצה הזו הוא 16MB או יותר, היא לא מוצפנת ולא נוצרות לה קובצי snapshot. המחיצה הזו נמחקת כשהמכשיר מאופס להגדרות המקוריות.
כללים והמלצות לעדכון מחיצות
מומלץ לעדכן את כל המחיצות של המערכת כמכלול ואת כל המחיצות של הספקים כמכלול נפרד. עדכון של קבוצת המחיצות כמכלול מאפשר לבדוק אם הממשקים בין התמונות בכל מחיצה נשארים יציבים.
לא משנה איך מעדכנים את המחיצות, צריך לעדכן את המחיצות הבאות בגלל יחסי תלות הדוקים וחוסר בממשקי API יציבים:
המחיצות boot ו-system_dlkm
המחיצות init_boot, system, system_ext ו-product
מחיצות דינמיות
במכשירים עם Android מגרסה 11 ואילך יש תמיכה במחיצות דינמיות. מחיצות דינמיות הן מערכת מחיצות של מרחב משתמש ב-Android שמאפשרת ליצור מחיצות, לשנות את הגודל שלהן או למחוק אותן במהלך עדכונים אוויריים (OTA). מידע נוסף זמין במאמר מחיצות דינמיות.
מחיצה misc. מחיצת האתחול משמשת את מחיצת השחזור, והיא צריכה להיות בגודל 4KB או יותר.
מחיצה tos. המחיצה הזו מכילה את התמונה הבינארית של Trusty OS, והיא משמשת רק אם המכשיר כולל את Trusty. מידע נוסף זמין במאמר מחיצות של Trusty OS (TOS).
וריאציות של מוצרים ב-Soong
מערכת ה-build של Soong משתמשת בוריאנטים של קובצי אימג' כדי לפצל את יחסי התלות ב-build. מודולים מקומיים (/build/soong/cc) יכולים לשנות מודולים של תהליך מערכת לווריאנט הליבה ומודולים של תהליך ספק לווריאנט הספק. מודול בווריאנט אחד של קובץ אימג' לא יכול לקשר למודולים אחרים בווריאנט אחר של קובץ אימג'.
ב-Android מגרסה 12 ואילך, מודול מערכת עם vendor_available: true יוצר וריאנט של ספק בנוסף לווריאנט הליבה. כדי ליצור וריאציה של מוצר, צריך להגדיר את product_available: true. חלק מספריות VNDK ללא product_available: true לא זמינות למודול המוצר.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-08-29 (שעון UTC).
[null,null,["עדכון אחרון: 2025-08-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."]]
