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.solibjpeg_turbo2.so라는 또 다른 비 AOSP 라이브러리에 의존한다면 수정된 libjpeg.so는 UX 모듈이 됩니다.
    • 예시 2: 공급업체가 새 함수를 수정된 libexif.so에 추가하고 수정된 libjpeg.solibexif.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 라이브러리가 링크에 실패하거나 정의되지 않은 동작으로 이어집니다.