2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
VNDK 확장 프로그램
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 기기 제조업체는 다양한 이유로 AOSP 라이브러리의 소스 코드를 변경합니다. 일부 공급업체는 AOSP 라이브러리에 기능을 재구현하여 성능을 높이는 반면 어떤 공급업체는 새로운 후크, API나 기능을 AOSP 라이브러리에 추가합니다. 이 섹션에서는 CTS/VTS를 손상시키지 않는 방식으로 AOSP 라이브러리를 확장하는 과정에 대한 가이드라인을 제공합니다.
드롭인(Drop-in) 교체
모든 수정된 공유 라이브러리는 바이너리와 호환되어야 하며, AOSP 상응 대상의 드롭인 교체여야 합니다. 모든 기존 AOSP 사용자는 재컴파일 없이 수정된 공유 라이브러리를 사용할 수 있어야 합니다. 이러한 요구사항은 다음을 의미합니다.
- AOSP 함수를 제거하면 안 됩니다.
- 사용자에게 노출되는 구조를 변경하면 안 됩니다.
- 함수 전제 조건을 보강하면 안 됩니다.
- 함수가 동일한 기능을 제공해야 합니다.
- 함수 전제 조건이 약화되면 안 됩니다.
확장 모듈 분류
모듈에 의해 정의 및 사용되는 기능에 따라 모듈을 분류하세요.
참고: 여기서 API/ABI 대신 기능이 사용되는 이유는 API/ABI를 변경하지 않고도 기능을 추가할 수 있기 때문입니다.
모듈에 정의된 기능에 따라 모듈은 DA 모듈 및 DX 모듈로 분류할 수 있습니다.
- 정의 전용 AOSP 모듈(DA 모듈)은 AOSP 상응 대상에 없었던 새로운 기능을 정의하지 않습니다.
- 예시 1: 수정되지 않은 온전한 AOSP 라이브러리가 DA 모듈입니다.
- 예시 2: 공급업체가 새 함수를 추가하지 않고 SIMD 명령어로
libcrypto.so의 함수를 다시 작성하면 수정된 libcrypto.so가 DA 모듈이 됩니다.
- 정의 확장 모듈(DX 모듈)은 새 기능을 정의하거나 AOSP 상응 대상을 보유하지 않습니다.
- 예시 1: 공급업체가 도우미 함수를
libjpeg.so에 추가하여 일부 내부 데이터에 액세스하면 수정된 libjpeg.so가 DX-Lib가 되고 새로 추가된 함수는 라이브러리의 확장 부분이 됩니다.
- 예시 2: 공급업체가
libfoo.so라는 비 AOSP 라이브러리를 정의하는 경우 libfoo.so는 DX-Lib가 됩니다.
모듈에서 사용하는 기능에 따라 모듈은 UA 모듈 및 UX 모듈로 분류될 수 있습니다.
-
사용 전용 AOSP 모듈(UA 모듈)은 구현에 AOSP 기능만 사용하며, 비 AOSP 확장 프로그램에 의존하지 않습니다.
- 예시 1: 수정되지 않은 온전한 AOSP 라이브러리가 UA 모듈입니다.
- 예시 2: 수정된 공유 라이브러리
libjpeg.so가 다른 AOSP API에만 의존하는 경우 UA 모듈이 됩니다.
- 사용 확장 모듈(UX 모듈)은 구현에 일부 비 AOSP 기능을 사용합니다.
- 예시 1: 수정된
libjpeg.so가 libjpeg_turbo2.so라는 또 다른 비 AOSP 라이브러리에 의존한다면 수정된 libjpeg.so는 UX 모듈이 됩니다.
- 예시 2: 공급업체가 새 함수를 수정된
libexif.so에 추가하고 수정된 libjpeg.so가 libexif.so에서 새로 추가된 함수를 사용하면 수정된 libjpeg.so는 UX 모듈이 됩니다.
정의 및 사용은 서로 독립적입니다.
|
사용된 기능 |
| AOSP만(UA) |
확장(UX) |
| 정의된 기능 |
AOSP만(DA) |
DAUA |
DAUX |
| 확장(DX) |
DXUA |
DXUX |
VNDK 확장 메커니즘
확장 기능에 의존하는 공급업체 모듈은 작동하지 않습니다. 이는 이름이 같은 AOSP 라이브러리에 확장 기능이 없기 때문입니다. 공급업체 모듈이 직간접적으로 확장 기능에 종속되는 경우, 공급업체는 DAUX, DXUA 및 DXUX 라이브러리를 공급업체 파티션에 복사해야 합니다(공급업체 프로세스는 항상 공급업체 파티션에서 먼저 공유 라이브러리를 찾음). 하지만 LL-NDK 라이브러리는 복사하면 안 됩니다. 따라서 공급업체 모듈은 수정된 LL-NDK 라이브러리에서 정의한 확장 기능에 의존하면 안 됩니다.
DAUA 공유 라이브러리는 해당하는 AOSP 라이브러리에서 동일한 기능을 제공할 수 있고, 시스템 파티션이 일반 시스템 이미지(GSI)에 의해 덮어쓰기되었을 때 공급업체 모듈이 계속해서 작동하는 경우 시스템 파티션에서 유지될 수 있습니다.
드롭인 교체가 중요한 이유는 GSI의 수정되지 않은 라이브러리가 이름 충돌 시 수정된 공유 라이브러리와 링크되기 때문입니다. AOSP 라이브러리가 API/ABI와 호환되는 방식으로 수정되면 GSI의 AOSP 라이브러리가 링크에 실패하거나 정의되지 않은 동작으로 이어집니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-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"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# VNDK extensions\n\nAndroid device manufacturers change the source code of AOSP libraries for\nvarious reasons. Some vendors reimplement functions in AOSP libraries to\nboost the performance while other vendors add new hooks, new APIs, or new\nfunctionalities to AOSP libraries. This section provides guidelines for\nextending AOSP libraries in a way that does not break CTS/VTS.\n\nDrop-in replacement\n-------------------\n\nAll modified shared libraries must be **binary-compatible** ,\n**drop-in replacements** of their AOSP counterpart. All existing\nAOSP users must be able to use the modified shared library without\nrecompilations. This requirement implies the following:\n\n- AOSP functions must not be removed.\n- Structures must not be altered if such structures are exposed to their users.\n- Pre-condition of functions must not be strengthened.\n- Functions must provide equivalent functionalities.\n- Post-condition of functions must not be weakened.\n\nExtended module classifications\n-------------------------------\n\nClassify modules by the functionalities they **define** and\n**use**.\n\n**Note** : *Functionalities* is used here\ninstead of API/ABI because it is possible to add functionality without changing\nany API/ABI.\n\nDepending on the functionalities defined in a module, modules can be\nclassified into **DA-Module** and **DX-Module**:\n\n- *Defining-only-AOSP Modules (DA-Module)* do not define new functionalities which were not in the AOSP counterpart.\n - *Example 1.* An intact unmodified AOSP library is a DA-Module.\n - *Example 2.* If a vendor rewrites the functions in `libcrypto.so` with SIMD instructions (without adding new functions), then the modified `libcrypto.so` will be a DA-Module.\n- *Defining-Extension Modules (DX-Module)* either define new functionalities or do not have an AOSP counterpart.\n - *Example 1.* If a vendor adds a helper function to `libjpeg.so` to access some internal data, then the modified `libjpeg.so` will be a DX-Lib and the newly added function will be the extended portion of the library.\n - *Example 2.* If a vendor defines a non-AOSP library named `libfoo.so`, then `libfoo.so` will be a DX-Lib.\n\nDepending on the functionalities used by a module, modules can be classified\ninto **UA-Module** and **UX-Module**.\n\n- *Using-only-AOSP Modules (UA-Module)* only use AOSP functionalities in their implementations. They do not rely on any non-AOSP extensions.\n - *Example 1.* An intact unmodified AOSP library is an UA-Module.\n - *Example 2.* If a modified shared library `libjpeg.so` only relies on other AOSP APIs, then it will be an UA-Module.\n- *Using-Extension Modules (UX-Module)* rely on some non-AOSP functionalities in their implementations.\n - *Example 1.* If a modified `libjpeg.so` relies on another non-AOSP library named `libjpeg_turbo2.so`, then the modified `libjpeg.so` will be an UX-Module.\n - *Example 2.* If a vendor adds a new function to their modified `libexif.so` and their modified `libjpeg.so` uses the newly added function from `libexif.so`, then their modified `libjpeg.so` will be an UX-Module.\n\nDefinitions and usages are independent from each other:\n\n|---------------|------|----------------|---------------|\n| || Used Functionalities ||\n| || Only AOSP (UA) | Extended (UX) |\n| Extended (DX) | DXUA | DXUX |\n\nVNDK extension mechanism\n------------------------\n\nVendor modules that rely on extended functionalities won't work because the\nAOSP library with the same name does not have the extended functionality. If\nvendor modules directly or indirectly depend on extended functionalities,\nvendors should copy DAUX, DXUA, and DXUX shared libraries to the vendor\npartition (vendor processes always look for shared libraries in the vendor\npartition first). However, LL-NDK libraries must not be copied, so vendor\nmodules must not rely on the extended functionalities defined by the modified\nLL-NDK libraries.\n\nDAUA shared libraries can remain on the system partition if the\ncorresponding AOSP library can provide the same functionality and vendor\nmodules continue to work when the system partition is overwritten by a Generic\nSystem Image (GSI).\n\nDrop-in replacement is important because the unmodified VNDK libraries in\nthe GSI will link with the modified shared libraries on name collision. If the\nAOSP libraries are modified in an API/ABI incompatible manner, the AOSP\nlibraries in the GSI might fail to link or result in undefined behaviors."]]
