HIDL 프레임워크 이전 버전과의 호환성 확인

HIDL HAL은 Android 핵심 시스템(system.img 또는 프레임워크)이 이전 버전과 호환됨을 보장합니다. 공급업체 테스트 도구 모음(VTS) 테스트는 HAL이 예상대로 작동(예를 들어 1.1 HAL 테스트는 모든 1.2 구현에서 실행됨)하는지 확인하는 반면에 프레임워크 테스트는 지원되는 HAL(1.0, 1.1, 1.2)이 제공되면 프레임워크가 HAL과 제대로 작동하는지 확인하기 위해 필요합니다.

HAL 인터페이스 정의 언어(HIDL)에 관한 자세한 내용은 HIDL, HIDL 버전 관리 및 HIDL HAL 지원 중단을 참조하세요.

HAL 업그레이드 정보

HAL 업그레이드에는 주 버전과 부 버전의 두 가지 유형이 있습니다. 대부분의 시스템은 하나의 HAL 구현만을 포함하지만 여러 구현이 지원됩니다. 예:

android.hardware.teleport@1.0 # initial interface
android.hardware.teleport@1.1 # minor version upgrade
android.hardware.teleport@1.2 # another minor version upgrade
...
android.hardware.teleport@2.0 # major version upgrade
...

일반적으로 시스템 파티션에는 특정 HAL 구현 그룹과의 통신을 관리하는 프레임워크 데몬(예: teleportd)이 포함됩니다. 또는 편리한 클라이언트 동작을 구현하는 시스템 라이브러리(예: android.hardware.configstore-utils)를 포함하는 시스템이 있을 수도 있습니다. 위의 예에서 teleportd는 기기에 설치된 HAL 버전과 관계없이 작동해야 합니다.

Google에서 유지하는 버전

주 버전 업그레이드(1.0, 2.0, 3.0 등)가 있는 경우 Google에서 유지하는 하나 이상의 기기는 이 버전이 지원 중단될 때까지 각 주 버전의 구현이 유지되어야 합니다. Google에서 유지하는 기기에 특정 주요 버전이 제공되지 않는 경우 Google은 이 주요 버전의 이전 구현을 계속 유지합니다.

새로운 구현(예 : 2.0)을 만들 때 이전 구현(예 : 1.2)은 유지되고 기본적으로 사용되지 않으므로 유지하는 데 약간의 추가 오버헤드가 추가됩니다.

부 버전 업그레이드 테스트

프레임워크에서 하위 버전의 이전 버전과의 호환성을 테스트하려면 부 버전 구현을 자동으로 생성하는 방법이 필요합니다. Google에서 유지하는 버전 관련 제한이 있을 때 hidl-gen은 1.(x+n) 구현을 사용하고 1.x 구현을 제공하는 어댑터만 생성합니다. 2.0 구현에서 주 버전의 정의에 따라 1.0 구현을 생성할 수 없습니다.

예를 들어 1.2 구현에서 1.1 테스트를 실행하려면 1.1 구현을 시뮬레이션할 수 있어야 합니다. 1.2 인터페이스는 동작(예: 프레임워크가 수동으로 버전을 확인하거나 castFrom을 호출함)에 약간의 차이가 있는 1.1 구현으로 자동 사용될 수 있습니다.

기본 개념은 다음과 같습니다.

  1. Android 휴대기기에 x.(y + n) 인터페이스를 설치합니다.
  2. xy 대상 어댑터를 설치하고 활성화합니다.
  3. 이전 버전의 부 버전을 실행할 때 예상대로 작동하는지 기기를 테스트합니다.

이러한 어댑터는 구현이 실제로 1.2 인터페이스에서 지원되고 1.1 인터페이스만 제공한다는 사실을 완전히 숨깁니다. 어댑터는 1.2 인터페이스를 사용하고 1.1 인터페이스처럼 보이게 만듭니다.

워크플로 예

이 예에서 Android 기기는 android.hardware.foo@1.1::IFoo/default를 실행합니다. 클라이언트가 android.hardware.foo@1.0::IFoo/default를 제대로 작동하는지 확인하려면 다음을 실행합니다.

  1. 터미널에서 다음을 실행합니다. 
    $ PACKAGE=android.hidl.allocator@1.0-adapter
$ INTERFACE=IAllocator
$ INSTANCE=ashmem
$ THREAD_COUNT=1 # can see current thread use on `lshal -i -e`
$ m -j $PACKAGE
$ /data/nativetest64/$PACKAGE/$PACKAGE $INTERFACE $INSTANCE $THREAD_COUNT
Trying to adapt down android.hidl.allocator@1.0-adapter/default
Press any key to disassociate adapter.
  2. adb shell stop 또는 start를 사용하여 클라이언트를 다시 시작하거나 프로세스를 종료합니다.
  3. 테스트가 완료되면 어댑터의 연결을 해제합니다.
  4. 기기를 다시 시작하거나 클라이언트를 다시 시작하여 시스템 상태를 복원합니다.

추가 타겟

hidl-gen은 빌드 시스템에서 hidl_interface로 지정된 모든 인터페이스와 관련한 어댑터의 추가 빌드 타겟을 자동으로 추가합니다. a.b.c@x.y 패키지에는 추가 C++ 타겟 a.b.c@x.y-adapter가 있습니다.

a.b.c@x.y 관련 어댑터는 일부 구현 a.b.c@x.(y+n)::ISomething/instance-name을 입력으로 가져오고 a.b.c@x.y::ISomething/instance-name을 등록해야 하며 y+n 구현도 취소해야 합니다.

다음과 같은 샘플 인터페이스가 제공됩니다.

// IFoo.hal
package a.b.c@1.0;
interface IFoo {
    doFoo(int32_t a) generates (int64_t b);
    doSubInterface() generates (IFoo a);
};

a.b.c@1.0-adapter에서 제공하는 코드는 아래 샘플과 비슷합니다.

// autogenerated code
// in namespace a::b::c::V1_0::IFoo
struct MockFoo {
    // takes some subclass of V1_0. May be V1_1, V1_2, etc...
    MockFoo(V1_0::IFoo impl) mImpl(impl) {}

    Return<int64_t> doFoo(int32_t a) {
        return this->mImpl->doFoo(a);
    }

    Return<V1_0::ICallback> doSubInterface() {
        // getMockForBinder returns MockCallback instance
        // that corresponds to a particular binder object
        // It can't return a new object every time or
        // clients using interfacesSame will have
        // divergent behavior when using the mock.
        auto _hidl_out = this->mImpl->doSubInterface();
        return getMockForBinder(_hidl_out);
    }
};

데이터 값은 반환되는 하위 인터페이스를 제외하고 자동 생성된 모의 클래스 외부 및 내부로 정확하게 전달됩니다. 이러한 인터페이스는 상응하는 최신 콜백 객체로 래핑되어야 합니다.