Product partitions

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 from the system partition to the vendor partition without dedicating space for OEM-specific components built from the Android build system. Android 9 and higher provides additional permissions 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 separate 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 is 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 permissions.xml file must reside in the same partition as the priv-apps. Placing a permissions.xml file in the system partition for priv-apps doesn't extend those permissions to priv-apps in the product partition, even though the former is an extension of the latter. For details on the permissions and whitelisting processes, see Privileged Permission Allowlisting.

Legacy /oem versus /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 oem partition:

Partition	Attributes
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.
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.
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.

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 system partition, Android 11 supports enforcing product interfaces.

/product components

The product partition contains the following components:

• Product-specific system properties (/product/build.prop)
• Product-specific RROs (/product/overlay/*.apk)
• Product-specific apps (/product/app/*.apk)
• Product-specific priv-apps (/product/priv-app/*.apk)
• Product-specific libraries (/product/lib/*)
• Product-specific java libraries (/product/framework/*.jar)
• Product-specific Android Framework system configs (/product/etc/sysconfig/* and /product/etc/permissions/*)
• Product-specific media files (/product/media/audio/*)
• Product-specific bootanimation files

No custom_images

You can't use custom_images. They lack support for the following:

• 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.
• Soong support. custom_images can't be built using the Soong build system.
• OTA update support. custom_images are used as factory ROM images that can't receive OTA updates.

Maintain ABIs between partitions

The product partition in Android 9 is an extension of the system partition. There's a weak ABI between product and 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 product and system, OEMs must maintain their own ABIs between the two partitions.

The product and system partitions can have dependency on each other. However, tests with the Generic System Image (GSI) must work properly without the product partition.

When the product interfaces are enforced, the product partition is decoupled with the system partition. The product partition uses only the allowed interfaces from the system partition.

The product partition must not have any dependency through unstable interfaces on vendor partition. Direct interaction between the product and vendor partitions is forbidden. (This is enforced by SEpolicy.)

Implement product partitions

Before implementing a new product partition, review the related product partition changes in AOSP. Then, to set up product, include the following board or product-build flags:

• BOARD_USES_PRODUCTIMAGE
• BOARD_PRODUCTIMAGE_PARTITION_SIZE
• BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE
• 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.

Install a module to the product partition

Use the following build flags to install a module to the product partition.

• product_specific: true in Android.bp
• LOCAL_PRODUCT_MODULE := true in Android.mk

Enable Verified Boot

To prevent the product partition from being tampered with by malicious software, enable Android Verified Boot (AVB) for that partition (just as you do for the vendor and system partitions). To enable AVB, include the following build flags: BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS.