Android 9 and higher includes support for building
product partitions using the Android build system. Previously,
Android 8.x enforced the separation of SoC-specific components
system partition to the
partition without dedicating space for OEM-specific components built from the
Android build system. Android 9 and higher provides additional
and whitelisting features that apply to priv-apps on different partitions.
About product partitions
Many OEMs customize the AOSP system image to implement their own features,
as well as carrier requirements. However, such customizations make it
impossible to use a single system image for multiple software SKUs. Each
image must be different to support the customizations, such as with
different locales or carriers. Using a
product partition to contain customizations makes it
possible to use a single system image for multiple software SKUs. (The
system partition hosts generic code that can be shared among
many software SKUs). The
vendor partition continues to host
SoC-specific BSP code which can be shared among multiple
devices based on the given SoC.
Using separate partitions has some disadvantages, such as
managing disk space (a limited amount of space must remain reserved for future
growth) and maintaining
a stable application binary interface (ABI) between partitions. Before
deciding to use
product partitions, take time to consider your
unique AOSP implementation and possible mitigation tactics (such as
repartitioning a device during an over-the-air
(OTA) update, which isn't done by Google but is done by some OEMs).
Dynamic partitioning will
be a good solution for this.
Product partitions and permissions
In Android 9 and higher, a change in the permissions
and whitelisting process affects how you grant priv-apps permissions on
your `product` partitions. The
must reside in the same partition as the priv-apps. Placing a
permissions.xml file in the
for priv-apps doesn't extend those permissions to priv-apps in the
partition, even though the former is an extension of the latter.
For details on the permissions and whitelisting processes, see
Privileged Permission Whitelisting.
Legacy /oem vs /product
We have two kinds of attributes of the
product partition depending
on the product
interface enforcement. Also, the
product partition is different
than the legacy
For these reasons, Android 9 supports the
product partition while
retaining support for the legacy
oem partition, for devices that depend on
it. To decouple the
product partition from the
partition, Android 11 supports
product partition contains the following components:
- Product-specific system properties (
- Product-specific RROs (
- Product-specific apps (
- Product-specific priv-apps (
- Product-specific libraries (
- Product-specific java libraries (
- Product-specific Android Framework system configs
- Product-specific media files (
You can't use
custom_images. They lack support for the
- Installing modules into a specific target.
custom_imagessupport 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.
- Soong support.
custom_imagescan't be built using the Soong build system.
- OTA update support.
custom_imagesare used as factory ROM images that can't receive OTA updates.
Maintaining ABIs between partitions
product partition in Android 9 is an extension of the
system partition. There's a weak ABI between
system partitions, so both must be
upgraded at the same time, and the ABI should be system SDK-based. If the
system SDK doesn't cover all API surfaces between
system, OEMs must maintain their own ABIs between
the two partitions.
system partitions can have
dependency on each other. However, tests with the
Generic System Image (GSI)
must work properly without the
product interfaces are enforced, the
partition is decoupled with the
system partition. The
partition uses only the allowed interfaces from the
product partition must not have any dependency on
vendor partition. Direct interaction between the
vendor partitions is forbidden.
(This is enforced by SEpolicy.)
Implementing product partitions
Before implementing a new product partition, review the
product partition changes in AOSP. Then, to set up
include the following board or product-build flags:
/product/build.prop. These must be within a
$(call inherit-product path/to/device.mk), as in
PRODUCT_PRODUCT_PROPERTIES += product.abc=ok.
Installing a module to the product partition
Use the following build flags to install a module to the
LOCAL_PRODUCT_MODULE := truein
Enabling verified boot
To prevent the
product partition from being tampered with by
malicious software, enable
Verified Boot (AVB) for that partition (just as you do for the
system partitions). To enable AVB,
include the following build flags: