2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
ODM 파티션
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 10은 Android 빌드 시스템을 사용하여 odm 파티션 빌드를 지원합니다.
ODM 파티션 정보
원천 디자인 제조업체(ODM)는 단일 칩 시스템(SoC) 공급업체 보드 서포트 패키지(BSP)를 특정 기기(보드)에 맞게 맞춤설정합니다. 이를 통해 보드 관련 구성요소, 보드 관련 데몬 또는 하드웨어 추상화 계층(HAL)의 자체 기능을 위한 커널 모듈을 구현할 수 있습니다. SoC 구성요소를 교체하거나 맞춤설정할 수도 있습니다.
낮은 Android 버전에서는 이러한 맞춤설정으로 인해 SoC가 동일하거나 SoC는 다르지만 같은 제품군인 기기에 단일 공급업체 이미지를 사용하지 못했습니다. Android 10 이상에서는 맞춤설정에 별도의 odm 파티션을 사용할 수 있으므로 여러 하드웨어 SKU에 단일 공급업체 이미지를 사용할 수 있습니다.
제품 및 ODM 파티션 사용
Android 9에서는 product 파티션을 빌드하도록 지원을 추가하여 서로 다른 product.img 이미지에서 제공하는 여러 소프트웨어 SKU에 단일 시스템 이미지를 사용할 수 있습니다. product 파티션은 소프트웨어 SKU용이며 odm 파티션은 하드웨어 SKU용입니다.
전용 제품 및 ODM 파티션을 사용하면 여러 소프트웨어 SKU 간 공유를 위해 일반 코드를 호스팅하는 system 파티션과 특정 SoC를 기반으로 여러 기기 간 공유를 위해 SoC 관련 BSP 코드를 호스팅하는 vendor 파티션을 사용할 수 있습니다.
별도의 파티션을 사용하면 디스크 공간 관리의 어려움과 같은 단점이 있습니다. 예를 들어 향후 확장을 위한 제한된 공간을 확보해야 합니다. 그러나 Android 10에서는 동적 파티션을 지원하여 디스크 문제를 제거하고 무선 업데이트(OTA) 도중 기기의 파티션을 다시 나눌 수 있습니다.
ODM 구성요소
vendor 파티션과 마찬가지로 odm 파티션에는 다음 테이블에 나열된 ODM 관련 구성요소가 포함됩니다.
| ODM 관련 구성요소 |
위치 |
| 로드 가능한 커널 모듈(LKM) |
/odm/lib/modules/*.ko |
| 네이티브 라이브러리 |
/odm/lib[64] |
| HAL |
/odm/lib[64]/hw |
| SEPolicy |
/odm/etc/selinux |
| VINTF 객체 데이터 |
/odm/etc/vintf |
init.rc 파일 |
/odm/etc/init |
| 시스템 속성 |
/odm/build.prop |
| 런타임 리소스 오버레이(RRO) |
/odm/overlay/*.apk |
| 앱 |
/odm/app/*.apk |
| Priv-app |
/odm/priv-app/*.apk |
| 자바 라이브러리 |
/odm/framework/*.jar |
| Android 프레임워크 시스템 구성 |
/odm/etc/sysconfig/*, /odm/etc/permissions/* |
맞춤 이미지 없음
맞춤 이미지는 다음을 지원하지 않으므로 사용하지 않습니다.
- 특정 타겟에 모듈 설치:
맞춤 이미지는 아티팩트를 이미지로 복사하는 것을 지원하지만, 타겟 파티션을 빌드 규칙의 일부로 지정하여 모듈을 특정 파티션에 설치할 수는 없습니다.
- Soong:
custom_images는 Soong 빌드 시스템을 사용하여 빌드할 수 없습니다.
- OTA 업데이트: 맞춤 이미지는 무선 업데이트할 수 없는 공장 출고 시 ROM 이미지로 사용됩니다.
파티션 간 ABI 유지
odm 파티션은 vendor 파티션의 확장입니다. Application Binary Interface(ABI) 안정성을 고려할 때 다음 아키텍처에 유의합니다.
그림 1. 파티션 간 ABI 유지
odm 및 vendor 파티션 간에는 ABI 안정성이 없습니다. 두 파티션을 동시에 업그레이드해야 합니다.odm 및 vendor 파티션은 서로 의존할 수 있지만, vendor 파티션은 반드시 odm 파티션 없이도 작동해야 합니다.odm과 system 간 ABI는 vendor와 system 간 ABI와 동일합니다.
product 파티션과 vendor 또는 odm 파티션 간의 직접 상호작용은 허용되지 않습니다. 이 정책은 SEpolicy에 의해 적용됩니다.
ODM 파티션 구현
새 파티션을 구현하기 전에 관련 AOSP 변경을 검토하세요.
ODM 파티션 설정
odm 파티션을 설정하려면 다음 빌드 플래그를 포함합니다.
- 고정 파티션 크기의 경우:
BOARD_ODMIMAGE_PARTITION_SIZE
- 동적 파티션 크기의 경우:
PRODUCT_USE_DYNAMIC_PARTITIONS 및 BOARD_ODMIMAGE_PARTITION_RESERVED_SIZE
- ODM 이미지에 사용하는
BOARD_ODMIMAGE_FILE_SYSTEM_TYPE 파일 시스템 유형
/odm/build.prop의 PRODUCT_ODM_PROPERTIES를 PRODUCT_ODM_PROPERTIES += product.abc=ok에서와 같이 $(call inherit-product path/to/device.mk) 내에서 사용
ODM 파티션에 모듈 설치
다음 빌드 플래그를 사용하여 odm 파티션에 모듈을 설치합니다.
Android.bp에서 device_specific: trueAndroid.mk에서 LOCAL_ODM_MODULE := true
자체 검사 부팅 사용 설정
악성 소프트웨어가 odm 파티션을 변조하지 못하게 하려면 vendor와 system 파티션에 하는 것처럼 파티션에 Android 자체 검사 부팅(AVB)을 사용 설정합니다.
AVB를 사용 설정하려면 BOARD_AVB_ODM_ADD_HASHTREE_FOOTER_ARGS 빌드 플래그를 포함합니다. 동적 파티션에 AVB를 구성하는 것에 관한 자세한 내용은 AVB 구성 변경을 참고하세요.
/odm을 다른 /vendor 파티션으로 처리
시스템이 odm 파티션을 vendor 파티션으로 처리하기 위해 하드 코딩 vendor 참조를 일련의 하드웨어 지향 파티션(현재 odm 및 vendor)으로 대체합니다. 플랫폼의 주요 vendor 참조 위치에는 동적 링커, 패키지 관리자, shell/libc가 포함됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-04-27(UTC)
[[["이해하기 쉬움","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"]],["최종 업데이트: 2024-04-27(UTC)"],[],[],null,["# ODM partitions\n\nAndroid 10 includes support for building\n`odm` partitions using the Android build system.\n\nAbout ODM partitions\n--------------------\n\n\nOriginal design manufacturers (ODMs) customize system-on-chip (SoC) vendor\nboard-support packages (BSPs) to their specific devices (their boards). This\nenables them to implement kernel modules for board-specific components,\nboard-specific daemons, or their own features on hardware abstraction layers\n(HALs). They might also want to replace or customize SoC components.\n\n\nIn lower Android releases, such customizations prevented the use of a single\nvendor image for devices with the same SoC (or with different SoCs, but in the\nsame family). In Android 10 and higher, you can use a\nseparate `odm` partition for customizations, which enables you to\nuse a single vendor image for multiple hardware SKUs.\n\n### Use product and ODM partitions\n\n\nAndroid 9 added support for building\n[`product`\npartitions](/docs/core/architecture/bootloader/partitions/product-partitions), enabling the use of a single system image for multiple software\nSKUs supplied by different `product.img` images. While the\n`product` partition is intended for software SKUs, the\n`odm` partition is intended for hardware SKUs.\n\n\nWith dedicated product and ODM partitions, you can use the `system`\npartition to host generic code for sharing among many software SKUs, and the\n`vendor` partition to host SoC-specific BSP code to share among\nmultiple devices based on the given SoC.\n\n\nUsing separate partitions has disadvantages, such as the difficulty in managing\ndisk space (for example, you must reserve a limited amount of space for future\ngrowth). However, Android 10 support for\n[dynamic partitions](/docs/core/ota/dynamic_partitions)\nremoves the disk issue, and makes repartitioning a device during an\n[over-the-air (OTA)](/docs/core/ota) update possible.\n\n### ODM components\n\n\nThe `odm` partition contains the following ODM-specific components\n(similar to the `vendor` partition), listed in the following table.\n\n| ODM-specific component | Location |\n|-------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|\n| Loadable kernel modules (LKMs) | `/odm/lib/modules/*.ko` |\n| Native libraries | `/odm/lib[64]` |\n| HALs | `/odm/lib[64]/hw` |\n| SEPolicy | `/odm/etc/selinux` |\n| [VINTF object data](/docs/core/architecture/vintf/objects) | `/odm/etc/vintf` |\n| [`init.rc` files](https://android.googlesource.com/platform/system/core/+/android16-release/init/README.md) | `/odm/etc/init` |\n| System properties | `/odm/build.prop` |\n| Runtime resource overlays (RROs) | `/odm/overlay/*.apk` |\n| Apps | `/odm/app/*.apk` |\n| Priv-apps | `/odm/priv-app/*.apk` |\n| Java libraries | `/odm/framework/*.jar` |\n| Android Framework system configs | `/odm/etc/sysconfig/*` and `/odm/etc/permissions/*` |\n\n### No custom images\n\n\nDon't use\n[custom\nimages](https://android.googlesource.com/platform/build/+/bc7e3f98f41108c03a06abbf98add08ad4a05040/cor\ne/tasks/build_custom_images.mk#53) because they lack support for the following:\n\n- **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.\n- **Soong.** `custom_images` can't be built using the Soong build system.\n- **OTA update.** Custom images are used as factory ROM images that can't be OTA-ed.\n\n### Maintain ABIs between partitions\n\n\nThe `odm` partition is an extension of the `vendor`\npartition. When considering application binary interface (ABI) stability, keep\nthe following architecture in mind.\n\n**Figure 1.** Maintaining ABI between partitions.\n\n- There's no ABI stability between `odm` and `vendor` partitions. Both partitions must be upgraded at the same time.\n- The `odm` and `vendor` partitions can depend on each other, but the `vendor` partition **must** work without an `odm` partition.\n- The ABI between `odm` and `system` is the same as the ABI between `vendor` and `system`.\n\n\nDirect interaction between the `product` partition and the\n`vendor` or `odm` partition **isn't\nallowed**. (This is enforced by SEpolicy.)\n\nImplement ODM partitions\n------------------------\n\n\nBefore implementing a new partition, review the\n[related AOSP\nchanges](https://android-review.googlesource.com/q/topic:odm_partition_+OR+topic:odm_partition+(status:open+OR+status:merged)).\n\n### Set up ODM partitions\n\n\nTo set up `odm` partitions, include these build flags:\n\n- `BOARD_ODMIMAGE_PARTITION_SIZE` for a fixed partition size\n- `PRODUCT_USE_DYNAMIC_PARTITIONS` and `BOARD_ODMIMAGE_PARTITION_RESERVED_SIZE` for a [dynamic partition](/docs/core/ota/dynamic_partitions) size\n- `BOARD_ODMIMAGE_FILE_SYSTEM_TYPE` file system type used for the ODM image\n- `PRODUCT_ODM_PROPERTIES` for `/odm/build.prop` for use within a `$(call inherit-product path/to/device.mk)`, as in `PRODUCT_ODM_PROPERTIES += product.abc=ok`\n\n### Install a module to an ODM partition\n\n\nUse these build flags to install a module to an `odm` partition:\n\n- `device_specific: true` in `Android.bp`\n- `LOCAL_ODM_MODULE := true` in `Android.mk`\n\n### Enable Verified Boot\n\n\nTo prevent malicious software from tampering with `odm` partitions,\nenable [Android Verified Boot\n(AVB)](/docs/security/features/verifiedboot/avb) for those partitions (just as you do for `vendor` and\n`system` partitions).\n\n\nTo enable AVB, include the build flag\n`BOARD_AVB_ODM_ADD_HASHTREE_FOOTER_ARGS`. For details on configuring\nAVB on dynamic partitions, see\n[AVB configuration\nchanges](/docs/core/ota/dynamic_partitions/implement#avb-configuration-changes).\n\n### Treat /odm as another /vendor partition\n\n\nTo ensure that the system handles the `odm` partition as a\n`vendor` partition, replace any hard-coded `vendor`\nreferences with a set of hardware-oriented partitions (currently\n`odm` and `vendor`). Notable `vendor`\nreference locations in the platform include\n[dynamic\nlinker](https://android.googlesource.com/platform/bionic/+/android16-release/linker/),\n[package\nmanager](https://android.googlesource.com/platform/frameworks/base/+/android16-release/services/core/java/com/andr\noid/server/pm/PackageManagerService.java), and `shell/libc`."]]
