Android 10 includes support for building
odm partitions using the Android build system.
About ODM partitions
Original design manufacturers (ODMs) customize system-on-chip (SoC) vendor board-support packages (BSPs) to their specific devices (their boards). This enables them to implement kernel modules for board-specific components, board-specific daemons, or their own features on hardware abstraction layers (HALs). They might also want to replace or customize SoC components.
In lower Android releases, such customizations prevented the use of a single
vendor image for devices with the same SoC (or with different SoCs, but in the
same family). In Android 10 and higher, you can use a
odm partition for customizations, which enables you to
use a single vendor image for multiple hardware SKUs.
Using product and ODM partitions
Android 9 added support for building
partitions, enabling the use of a single system image for multiple software
SKUs supplied by different
product.img images. While the
product partition is intended for software SKUs, the
odm partition is intended for hardware SKUs.
With dedicated product and ODM partitions, you can use the
partition to host generic code for sharing among many software SKUs, and the
vendor partition to host SoC-specific BSP code to share among
multiple devices based on the given SoC.
Using separate partitions has disadvantages, such as the difficulty in managing disk space (for example, you must reserve a limited amount of space for future growth). However, Android 10 support for dynamic partitions removes the disk issue, and makes repartitioning a device during an over-the-air (OTA) update possible.
odm partition contains the following ODM-specific components
(similar to the
vendor partition), listed in the following table.
|Loadable kernel modules (LKMs)||
|VINTF object data||
|Runtime resource overlays (RROs)||
|Android Framework system configs||
No custom images
Don't use custom images because they lack support for the following:
- Installation of a module to a specific target. Custom images support copying artifacts into an image, but can’t install a module into a specific partition by specifying the target partition as a part of a build rule.
custom_imagescan’t be built using the Soong build system.
- OTA update. Custom images are used as factory ROM images that can't be OTA-ed.
Maintaining ABIs between partitions
odm partition is an extension of the
partition. When considering application binary interface (ABI) stability, keep
the following architecture in mind.
- There's no ABI stability between
vendorpartitions. Both partitions must be upgraded at the same time.
vendorpartitions can depend on each other, but the
vendorpartition must work without an
- The ABI between
systemis the same as the ABI between
Direct interaction between the
product partition and the
odm partition isn't
allowed. (This is enforced by SEpolicy.)
Implementing ODM partitions
Before implementing a new partition, review the related AOSP changes.
Setting up ODM partitions
To set up
odm partitions, include these build flags:
BOARD_ODMIMAGE_PARTITION_SIZEfor a fixed partition size
BOARD_ODMIMAGE_PARTITION_RESERVED_SIZEfor a dynamic partition size
BOARD_ODMIMAGE_FILE_SYSTEM_TYPEfile system type used for the ODM image
/odm/build.propfor use within a
$(call inherit-product path/to/device.mk), as in
PRODUCT_ODM_PROPERTIES += product.abc=ok
Installing a module to an ODM partition
Use these build flags to install a module to an
LOCAL_ODM_MODULE := truein
Enabling Verified Boot
To prevent malicious software from tampering with
enable Android Verified Boot
(AVB) for those partitions (just as you do for
To enable AVB, include the build flag
BOARD_AVB_ODM_ADD_HASHTREE_FOOTER_ARGS. For details on configuring
AVB on dynamic partitions, see
Treating /odm as another /vendor partition
To ensure that the system handles the
odm partition as a
vendor partition, replace any hard-coded
references with a set of hardware-oriented partitions (currently
reference locations in the platform include