自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
產品劃分
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android 9 以上版本支援使用 Android 建構系統建構 product 分區。先前，Android 8.x 會強制將 SoC 專屬元件從 system 分割區分離至 vendor 分割區，但不會為從 Android 建構系統建構的 OEM 專屬元件保留空間。Android 9 以上版本提供額外的權限和白名單功能，可套用至不同分區的私人應用程式。
關於產品劃分
許多原始設備製造商 (OEM) 會自訂 AOSP 系統映像檔，以便實作自身功能和電信業者規定。不過，這類自訂設定會導致無法使用單一系統映像檔來處理多個軟體 SKU。每個映像檔都必須不同，才能支援自訂設定，例如不同的語言代碼或電信業者。使用單獨的 product 分區來容納自訂項目，即可為多個軟體 SKU 使用單一系統映像檔。(system 分割區會代管通用程式碼，可在許多軟體 SKU 之間共用)。vendor 區隔會繼續代管 SoC 專屬的 BSP 程式碼，可根據特定 SoC 在多個裝置之間共用。
使用個別分割區有某些缺點，例如管理磁碟空間 (必須保留有限的空間供未來擴充使用)，以及在分割區之間維持穩定的應用程式二進位介面 (ABI)。決定是否使用 product 分割區之前，請先花時間考量您獨特的 AOSP 實作方式和可能的緩解策略 (例如在無線 (OTA) 更新期間重新分割裝置，這不是 Google 而是部分原始設備製造商 (OEM) 執行的操作)。動態分割是這類問題的理想解決方案。
產品劃分和權限
在 Android 9 以上版本中，權限和白名單程序的變更會影響您在「product」分區中授予私人應用程式權限的方式。permissions.xml 檔案必須與 priv-apps 位於相同的分割區。將 permissions.xml 檔案放入 priv-apps 的 system 分割區，並不會將這些權限擴充至 product 分割區中的 priv-apps，即使前者是後者的擴充功能也是如此。如要進一步瞭解權限和白名單程序，請參閱特權權限許可清單。
舊版 /oem 與 /product
我們有兩種 product 區隔屬性，取決於產品介面強制執行。此外，product 分區與舊版 oem 分區不同：
| 分區 |
屬性 |
oem |
- 無法更新；通常會在工廠閃過一次。
- 根據品牌和顏色等微幅變化建立。
oem 區隔內容不同，不代表產品軟體不同。
system 分區不依附於 oem 分區。(只有在找到特定檔案時，才會使用 oem 分區)。- 僅使用
system 分割區的公開 API。
|
product |
- 可更新
- 與系統映像檔配對 (一併更新)
- 依產品或產品家族建構。
- 系統分區可能會依賴
product 分區。
- 可使用非公開 API，因為這些 API 會同時更新。
|
product (強制執行介面) |
- 可更新
- 與系統映像檔分離。
- 依產品或產品家族建構。
system 分區不依附於 product 分區。- 無法使用隱藏的 API，但只會在
system 分割區使用公開和系統 API。
|
基於這些原因，Android 9 會支援 product 分區，同時保留對舊版 oem 分區的支援，以便支援依賴該分區的裝置。為將 product 分區與 system 分區解耦，Android 11 支援強制執行 product 介面。
/產品元件
product 區隔包含下列元件：
- 產品專屬系統屬性 (
/product/build.prop)
- 產品專屬 RRO (
/product/overlay/*.apk)
- 產品專屬應用程式 (
/product/app/*.apk)
- 產品專屬 priv-apps (
/product/priv-app/*.apk)
- 產品專屬程式庫 (
/product/lib/*)
- 產品專屬 Java 程式庫 (
/product/framework/*.jar)
- 產品專屬的 Android 架構系統設定 (
/product/etc/sysconfig/* 和 /product/etc/permissions/*)
- 產品專屬媒體檔案 (
/product/media/audio/*)
- 產品專屬
bootanimation 檔案
沒有 custom_images
您無法使用 custom_images。但不支援下列功能：
- 將模組安裝到特定目標。
custom_images 支援將構件複製到映像檔，但無法將模組安裝到特定區段，因為您無法將目標區段指定為建構規則的一部分。
- Soong 支援。
custom_images 無法使用 Soong 建構系統進行建構。
- OTA 更新支援。
custom_images 用於無法接收 OTA 更新的原廠 ROM 映像檔。
維護分區之間的 ABI
Android 9 中的 product 分區是 system 分區的擴充功能。product 和 system 區隔之間的 ABI 較弱，因此必須同時升級這兩個區隔，且 ABI 應以系統 SDK 為基礎。如果系統 SDK 未涵蓋 product 和 system 之間的所有 API 途徑，OEM 必須在兩個分區之間維護自己的 ABI。
product 和 system 區隔可能會彼此依附。不過，使用通用系統映像檔 (GSI) 的測試必須在沒有 product 分割區的情況下正常運作。
強制執行 product 介面後，product 分區就會與 system 分區解耦。product 分區只會使用 system 分區允許的介面。
product 分區不得透過 vendor 分區上的不穩定介面，產生任何依附元件。禁止 product 和 vendor 區隔之間的直接互動。(這是由 SEpolicy 強制執行。)
實作產品劃分
在實作新產品分區之前，請先查看 AOSP 中的相關產品分區變更。接著，如要設定 product，請加入下列板卡或產品建構標記：
BOARD_USES_PRODUCTIMAGEBOARD_PRODUCTIMAGE_PARTITION_SIZEBOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE/product/build.prop 的 PRODUCT_PRODUCT_PROPERTIES。這些值必須位於 $(call inherit-product path/to/device.mk) 中，如 PRODUCT_PRODUCT_PROPERTIES += product.abc=ok 所示。
在產品分區中安裝模組
請使用下列建構標記，將模組安裝至 product 分區。
Android.bp的product_specific: trueAndroid.mk的LOCAL_PRODUCT_MODULE := true
啟用驗證開機程序
為避免 product 分區遭惡意軟體竄改，請為該分區啟用 Android 驗證啟動 (AVB) (就像為 vendor 和 system 分區啟用這項功能一樣)。如要啟用 AVB，請加入下列建構標記：BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","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-27 (世界標準時間)。"],[],[],null,["# Product partitions\n\nAndroid 9 and higher includes support for building\n`product` partitions using the Android build system. Previously,\nAndroid 8.x enforced the separation of SoC-specific components\nfrom the `system` partition to the `vendor`\npartition without dedicating space for OEM-specific components built from the\nAndroid build system. Android 9 and higher provides additional\n[permissions\nand whitelisting features](#product-partitions-and-permissions) that apply to priv-apps on different partitions.\n\nAbout product partitions\n------------------------\n\n\nMany OEMs customize the AOSP system image to implement their own features,\nas well as carrier requirements. However, such customizations make it\nimpossible to use a single system image for multiple software SKUs. Each\nimage must be different to support the customizations, such as with\ndifferent locales or carriers. Using a\nseparate `product` partition to contain customizations makes it\npossible to use a single system image for multiple software SKUs. (The\n`system` partition hosts generic code that can be shared among\nmany software SKUs). The `vendor` partition continues to host\nSoC-specific BSP code which can be shared among multiple\ndevices based on the given SoC.\n\n\nUsing separate partitions has some disadvantages, such as\nmanaging disk space (a limited amount of space must remain reserved for future\ngrowth) and [maintaining\na stable application binary interface (ABI)](/docs/core/architecture/vndk/abi-stability) between partitions. Before\ndeciding to use `product` partitions, take time to consider your\nunique AOSP implementation and possible mitigation tactics (such as\nrepartitioning a device during an [over-the-air\n(OTA) update](/docs/core/ota), which isn't done by Google but is done by some OEMs).\n[Dynamic partitioning](/docs/core/ota/dynamic_partitions) is\na good solution for this.\n\n### Product partitions and permissions\n\n\nIn Android 9 and higher, a change in the permissions\nand whitelisting process affects how you grant priv-apps permissions on\nyour \\`product\\` partitions. The `permissions.xml` file\nmust reside in the same partition as the priv-apps. Placing a\n`permissions.xml` file in the `system` partition\nfor priv-apps doesn't extend those permissions to priv-apps in the `product`\npartition, even though the former is an extension of the latter.\nFor details on the permissions and whitelisting processes, see\n[Privileged Permission Allowlisting](/docs/core/permissions/perms-allowlist).\n\n### Legacy /oem versus /product\n\n\nWe have two kinds of attributes of the `product` partition depending\non the [product\ninterface enforcement](/docs/core/architecture/bootloader/partitions/product-interfaces). Also, the `product` partition is different\nthan the legacy `oem` partition:\n\n| Partition | Attributes |\n|---------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `oem` | - Not updateable; usually flashed once at the factory. - Built per small variations, such as branding and color. Having different `oem` partition contents doesn't mean the product software is different. - The `system` partition doesn't depend on the `oem` partition. (It uses the `oem` partition only when a specific file is found there). - Only uses public API on the `system` partition. |\n| `product` | - Updateable - Coupled with the system image (they update together) - Built per product or product families. - System partition can depend on `product` partition. - Can use non-public APIs since they are updated simultaneously. |\n| `product` (enforced interfaces) | - Updateable - Decoupled with the system image. - Built per product or product families. - The `system` partition doesn't depend on the `product` partition. - Can't use hidden APIs, but only uses public and system APIs on the `system` partition. |\n\n\nFor these reasons, Android 9 supports the `product` partition while\nretaining support for the legacy `oem` partition, for devices that depend on\nit. To decouple the `product` partition from the `system`\npartition, Android 11 supports\n[enforcing `product`\ninterfaces](/docs/core/architecture/bootloader/partitions/product-interfaces).\n\n### /product components\n\n\nThe `product` partition contains the following components:\n\n- Product-specific system properties (`/product/build.prop`)\n- Product-specific RROs (`/product/overlay/*.apk`)\n- Product-specific apps (`/product/app/*.apk`)\n- Product-specific priv-apps (`/product/priv-app/*.apk`)\n- Product-specific libraries (`/product/lib/*`)\n- Product-specific java libraries (`/product/framework/*.jar`)\n- Product-specific Android Framework system configs (`/product/etc/sysconfig/*` and `/product/etc/permissions/*`)\n- Product-specific media files (`/product/media/audio/*`)\n- Product-specific `bootanimation` files\n\n### No custom_images\n\n\nYou can't use `custom_images`. They lack support for the\nfollowing:\n\n- **Installing modules into a specific target** . `custom_images` support copying artifacts into an image but can't install a module into a specific partition by specifying its target partition as a part of a build rule.\n- **Soong support** . `custom_images` can't be built using the Soong build system.\n- **OTA update support** . `custom_images` are used as factory ROM images that can't receive OTA updates.\n\n### Maintain ABIs between partitions\n\n\nThe `product` partition in Android 9 is an extension of the\n`system` partition. There's a weak ABI between\n`product` and `system` partitions, so both must be\nupgraded at the same time, and the ABI should be system SDK-based. If the\nsystem SDK doesn't cover all API surfaces between `product` and\n`system`, OEMs must maintain their own ABIs between\nthe two partitions.\n\nThe `product` and `system` partitions can have\ndependency on each other. However, tests with the\n[Generic System Image (GSI)](/docs/setup/create/gsi)\nmust work properly without the `product` partition.\n\n\nWhen the `product` interfaces are enforced, the `product`\npartition is decoupled with the `system` partition. The `product`\npartition uses only the allowed interfaces from the `system` partition.\n\nThe `product` partition must not have any dependency through unstable interfaces on\n`vendor` partition. Direct interaction between the\n`product` and `vendor` partitions is forbidden.\n(This is enforced by SEpolicy.)\n\nImplement product partitions\n----------------------------\n\n\nBefore implementing a new product partition, review the\n[related\nproduct partition changes in AOSP](https://android-review.googlesource.com/q/topic:product_partition+(status:open+OR+status:merged)). Then, to set up `product`,\ninclude the following board or product-build flags:\n\n- `BOARD_USES_PRODUCTIMAGE`\n- `BOARD_PRODUCTIMAGE_PARTITION_SIZE`\n- `BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE`\n- `PRODUCT_PRODUCT_PROPERTIES` for `/product/build.prop`. These must be within a `$(call inherit-product path/to/device.mk)`, as in `PRODUCT_PRODUCT_PROPERTIES += product.abc=ok`.\n\n### Install a module to the product partition\n\n\nUse the following build flags to install a module to the `product` partition.\n\n- `product_specific: true` in `Android.bp`\n- `LOCAL_PRODUCT_MODULE := true` in `Android.mk`\n\n### Enable Verified Boot\n\n\nTo prevent the `product` partition from being tampered with by\nmalicious software, enable\n[Android\nVerified Boot (AVB)](https://android.googlesource.com/platform/external/avb/) for that partition (just as you do for the\n`vendor` and `system` partitions). To enable AVB,\ninclude the following build flags:\n`BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS`."]]
