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가 됩니다.
- 예시 1: 공급업체가 도우미 함수를
모듈에서 사용하는 기능에 따라 모듈은 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 모듈이 됩니다.
- 예시 1: 수정된
정의 및 사용은 서로 독립적입니다.
사용된 기능 | |||
---|---|---|---|
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 라이브러리가 링크에 실패하거나 정의되지 않은 동작으로 이어집니다.