Android 10 includes support for building
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 may also want to replace or customize SoC components.
In previous 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, you can use a separate
/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
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
/odm partition is intended for hardware SKUs.
With dedicated product
and ODM partitions, you can use the
/system 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||
Don't use custom images because they lack support for the following:
- Installation of a module to a specific target.
custom_imagessupports copying artifacts into an image, but it can’t install a module into a specific partition by specifying its target partition as a part of a build rule.
custom_imagescan’t be built using the Soong build system.
custom_imagesare used as factory ROM images that can't be OTA-ed.
Maintaining ABIs between partitions
/odm partition is an extension of the
/vendor 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
Use this 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
/odm partitions, enable Android Verified Boot (AVB) for
those partitions (just as you do for
To enable AVB, include the build flag
details on configuring AVB on dynamic partitions, see AVB configuration changes.
Treating /odm as another /vendor partition
To ensure that the system handles the
/odm partition as a
partition, replace any hard-coded
/vendor references with a set of hardware-oriented
reference locations in the platform include dynamic linker, package manager, and