매칭 규칙

호환성 매트릭스와 매니페스트로 이루어진 두 개의 쌍은 조정되어 프레임워크와 공급업체 구현이 상호 작동할 수 있음을 검증해야 합니다. 이러한 검증은 프레임워크 호환성 매트릭스와 기기 매니페스트, 그리고 프레임워크 매니페스트와 기기 호환성 매트릭스 간의 매칭이 있을 때 이루어집니다.

이러한 검증은 빌드 시간, OTA 업데이트 패키지 생성 시간 및 부팅 시점에, 그리고 VTS 호환성 테스트에서 이루어집니다.

다음 섹션에서는 다양한 구성요소에 의해 사용되는 매칭 규칙을 자세히 설명합니다.

프레임워크 호환성 매트릭스 버전 매칭

기기 매니페스트를 프레임워크 호환성 매트릭스와 매칭하려면 manifest.target-level에 의해 지정된 배송 FCM 버전이 compatibility-matrix.level에 의해 지정된 FCM 버전과 정확히 같아야 합니다. 그렇지 않으면 매칭이 이루어지지 않습니다.

프레임워크 호환성 매트릭스가 libvintf로 요청되면 libvintf가 기기 매니페스트를 열고 배송 FCM 버전을 검색하고 배송 FCM 버전에서 프레임워크 호환성 매트릭스(및 더 높은 FCM 버전의 호환성 매트릭스에서 발생하는 일부 선택적 HAL)를 반환하기 때문에 항상 성공합니다.

HAL 매칭

HAL 매칭 규칙은 해당하는 호환성 매트릭스의 소유자에 의해 지원되는 것으로 간주되는 매니페스트 파일 내 hal 요소의 버전을 식별합니다.

HIDL 및 네이티브 HAL

HIDL 및 네이티브 HAL의 매칭 규칙은 다음과 같습니다.

  • 여러 개의 <hal> 요소가 단일 AND 관계로 평가됩니다.
  • <hal> 요소에는 해당 요소를 필요하지 않은 것으로 표시하는 <hal optional="true">가 있을 수 있습니다.
  • 같은 <hal>에 있는 여러 개의 <version> 요소는 OR 관계를 가집니다. 2개 이상이 지정된 경우 버전 중에서 하나만 구현하면 됩니다. 아래의 DRM 예시를 참고하세요.
  • 동일한 <hal> 내의 여러 <instance>와 <regex-instance> 요소는 <hal>이 필요할 때 단일 AND 관계로 평가됩니다. (<ahref="#drm">아래 DRM 예</ahref="#drm"> 참고)

예: 모듈의 HAL 매칭 성공

버전 2.5가 적용된 HAL의 매칭 규칙은 다음과 같습니다.

매트릭스 매칭 매니페스트
2.5 2.5-2.∞. 호환성 매트릭스에서 2.5는 2.5-5의 약식 표현입니다.
2.5-7 2.5-2.∞. 다음을 나타냅니다.
  • 2.5는 필요한 최소 버전입니다. 즉, HAL 2.0-2.4를 제공하는 매니페스트가 호환되지 않습니다.
  • 2.7은 요청 가능한 최대 버전입니다. 즉, 호환성 매트릭스(프레임워크 또는 기기)의 소유자가 2.7을 초과하는 버전을 요청하지 않습니다. 예를 들어 2.7이 요청되면 매칭 매니페스트의 소유자가 계속해서 버전 2.10 등을 제공할 수 있습니다. 호환성 매트릭스 소유자는 요청된 서비스가 API 버전 2.7과 호환된다는 사실만 인지합니다.
  • -7은 정보 제공의 목적으로만 사용되며 OTA 업데이트 프로세스에는 영향을 미치지 않습니다.
따라서 매니페스트 파일에 버전 2.10이 적용된 HAL이 있는 기기는 계속해서 호환성 매트릭스에 2.5-7을 명시하는 프레임워크와 호환됩니다.

예시: DRM 모듈의 HAL 매칭 성공

프레임워크 호환성 매트릭스는 DRM HAL과 관련하여 다음과 같은 버전 정보를 명시합니다.

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

공급업체는 다음 인스턴스 중 하나를 구현해야 합니다.

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
OR 
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

AND 역시 이러한 모든 인스턴스를 구현해야 합니다.

android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

AIDL HAL

Android 11 이후의 모든 Android 버전(Android 11 제외)은 VINTF에서 AIDL HAL 버전을 지원합니다. AIDL HAL의 매칭 규칙은 HIDL 및 네이티브 HAL의 매칭 규칙과 유사합니다. 단, 메이저 버전이 없으며 HAL 인스턴스당 정확히 하나의 버전이 있습니다(버전이 지정되지 않은 경우 1).

  • 여러 개의 <hal> 요소가 단일 AND 관계로 평가됩니다.
  • <hal> 요소에는 해당 요소를 필요하지 않은 것으로 표시하는 <hal optional="true">가 있을 수 있습니다.
  • 동일한 <hal> 내의 여러 <instance>와 <regex-instance> 요소는 <hal>이 필요할 때 단일 AND 관계로 평가됩니다. (<ahref="#vibrator">아래 진동기 예</ahref="#vibrator"> 참고)

예: 모듈의 HAL 매칭 성공

버전 5가 적용된 HAL의 매칭 규칙은 다음과 같습니다.

매트릭스 매칭 매니페스트
5 5-∞. 호환성 매트릭스에서 5는 5-5의 약식 표현입니다.
5-7 5-∞. 다음을 나타냅니다.
  • 5는 필요한 최소 버전입니다. 즉, HAL 1-4를 제공하는 매니페스트가 호환되지 않습니다.
  • 7은 요청할 수 있는 최대 버전입니다. 즉, 호환성 매트릭스(프레임워크 또는 기기)의 소유자는 7을 초과하는 버전을 요청하지 않습니다. 예를 들어 7이 요청되면 매칭 매니페스트의 소유자가 계속해서 버전 10을 제공할 수 있습니다. 호환성 매트릭스 소유자는 요청된 서비스가 API 버전 7과 호환된다는 사실만 인지합니다.
  • -7은 정보 제공의 목적으로만 사용되며 OTA 업데이트 프로세스에는 영향을 미치지 않습니다.
따라서 매니페스트 파일에 버전 10이 적용된 HAL이 있는 기기는 계속해서 호환성 매트릭스에 5-7을 명시하는 프레임워크와 호환됩니다.

예: 여러 모듈의 HAL 매칭 성공

프레임워크 호환성 매트릭스는 진동기 및 카메라 HAL에 관해 다음의 버전 정보를 명시합니다.

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

공급업체는 다음 인스턴스를 모두 구현해야 합니다.

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

커널 매칭

프레임워크 호환성 매트릭스의 <kernel> 섹션은 기기에 있는 Linux 커널의 프레임워크 요구사항을 설명합니다. 이 정보는 기기의 VINTF 객체에 의해 보고되는 커널에 관한 정보와 비교하여 매칭되어야 합니다.

커널 분기 매칭

각 커널 분기 서픽스(예: 5.4-r)는 고유한 커널 FCM 버전(예: 5)에 매핑됩니다. 이 매핑은 출시 문자(예: R)와 FCM 버전(예: 5) 사이의 매핑과 동일합니다.

VTS 테스트는 다음 중 하나가 참인 경우 기기가 기기 매니페스트 /vendor/etc/vintf/manifest.xml에 커널 FCM 버전을 명시적으로 지정하도록 적용합니다.

  • 커널 FCM 버전이 타겟 FCM 버전과 다릅니다. 예를 들어 앞서 언급한 기기의 경우 타겟 FCM 버전은 4, 커널 FCM 버전은 5(커널 분기 서픽스 r)입니다.
  • 커널 FCM 버전이 5(커널 분기 서픽스 r) 이상입니다.

VTS 테스트는 커널 FCM 버전이 지정된 경우 커널 FCM 버전이 기기 매니페스트의 타겟 FCM 버전 이상이 되도록 적용합니다.

예: 커널 분기 결정

기기에 타겟 FCM 버전 4 (Android 10에서 출시)가 있지만 기기가 4.19-r 분기에서 커널을 실행하는 경우 기기 매니페스트는 다음을 지정해야 합니다.

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

VINTF 객체는 FCM 버전 5에 지정된 4.19-r 커널 분기의 요구사항과 비교하여 커널 호환성을 확인합니다. 이러한 요구사항은 Android 소스 트리의 kernel/configs/r/android-4.19에서 빌드됩니다.

예: GKI용 커널 브랜치 결정

기기가 일반 커널 이미지(GKI)를 사용하는 경우 /proc/version의 커널 출시 문자열은 다음과 같습니다.

5.4.42-android12-0-00544-ged21d463f856

그런 다음, VINTF 객체는 커널 출시의 Android 버전을 가져오고 이를 사용하여 커널 FCM 버전을 결정합니다. 이 예에서 android12는 Android 12에 출시된 커널 FCM 버전 6을 의미합니다.

커널 출시 문자열이 파싱되는 방법에 관한 자세한 내용은 GKI 버전 관리를 참고하세요.

커널 버전 매칭

매트릭스는 여러 <kernel> 섹션을 포함할 수 있으며 각 섹션에는 다음과 같은 형식을 사용하는 서로 다른 version 속성이 포함됩니다.

${ver}.${major_rev}.${kernel_minor_rev}

VINTF 객체는 기기 커널과 동일한 ${ver} 및 ${major_rev}가 포함된 매칭되는 FCM 버전이 있는 FCM의 <kernel> 섹션만 고려하고(예: version="${ver}.${major_rev}.${matrix_minor_rev}")) 다른 섹션은 무시합니다. 또한 커널의 부 버전은 호환성 매트릭스(${kernel_minor_rev} >= ${matrix_minor_rev};)의 값이어야 합니다. <kernel> 섹션에서 이러한 요구사항을 충족하지 않는 경우에는 매칭이 이루어지지 않습니다.

예: 매칭을 위한 요구사항 선택

/system/etc/vintf의 FCM에서 다음 요구사항을 선언하는 다음과 같은 가상의 사례를 생각해 보세요(헤더 및 바닥글 태그는 생략됨).

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

타겟 FCM 버전, 커널 FCM 버전, 커널 버전이 FCM에서 커널 요구사항을 선택합니다.

타겟 FCM 버전커널 FCM 버전커널 버전매칭 항목
3(P)지정되지 않음4.4.106 매칭 없음(부 버전 불일치)
3(P)지정되지 않음4.4.107 4.4-p
3(P)지정되지 않음4.19.42 4.19-q(아래 내용 참고)
3(P)지정되지 않음5.4.41 5.4-r (아래 내용 참고)
3(P)3(P) 4.4.107 4.4-p
3(P)3(P) 4.19.42 매칭 없음(4.19-p 커널 분기 없음)
3(P)4(Q) 4.19.42 4.19-q
4(Q)지정되지 않음4.4.107 매칭 없음(4.4-q 커널 분기 없음)
4(Q)지정되지 않음4.9.165 4.9-q
4(Q)지정되지 않음5.4.41 5.4-r (아래 내용 참고)
4(Q)4(Q) 4.9.165 4.9-q
4(Q)4(Q) 5.4.41 매칭 없음(5.4-q 커널 분기 없음)
4(Q)5(R) 4.14.1054.14-r
4(Q)5(R) 5.4.41 5.4-r
5(R)지정되지 않음모두 VTS 실패(타겟 FCM 버전 5의 커널 FCM 버전을 지정해야 함)
5(R)4(Q) 모두 VTS 실패(커널 FCM 버전 < 타겟 FCM 버전)
5(R)5(R) 4.14.1804.14-r

커널 구성 매칭

<kernel> 섹션이 일치하면 config 요소를 /proc/config.gz에 매칭하는 시도를 통해 프로세스가 계속 진행됩니다. 호환성 매트릭스의 각 config 요소에 대해서는 /proc/config.gz를 조회하여 config가 존재하는지 확인합니다. 호환성 매트릭스에서 일치하는 <kernel> 섹션과 관련해 config 항목이 n으로 설정되면 이 항목이 /proc/config.gz에 없어야 합니다. 마지막으로 config 항목이 호환성 매트릭스에 없거나 /proc/config.gz에 없을 수 있습니다.

예: 커널 구성 매칭

  • <value type="string">bar</value>가 "bar"와 일치합니다. 따옴표는 호환성 매트릭스에서 생략되지만 /proc/config.gz에는 있습니다.
  • <value type="int">4096</value>은 4096 또는 0x1000 또는 0X1000과 일치합니다.
  • <value type="int">0x1000</value>은 4096 또는 0x1000 또는 0X1000과 일치합니다.
  • <value type="int">0X1000</value>은 4096 또는 0x1000 또는 0X1000과 일치합니다.
  • <value type="tristate">y</value>가 y와 일치합니다.
  • <value type="tristate">m</value>은 m과 일치합니다.
  • <value type="tristate">n</value>은 config 항목이 /proc/config.gz에 있어서는 안 된다는 것을 의미합니다.
  • <value type="range">1-0x3</value>은 1, 2, 3 중 한 가지와 일치하거나 16진수와 같습니다.

예시: 커널 매칭 성공

FCM 버전 1의 프레임워크 호환성 매트릭스에는 다음과 같은 커널 정보가 포함됩니다.

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

커널 분기가 먼저 매칭됩니다. 커널 분기는 기기 매니페스트 manifest.kernel.target-level에 지정되며 전자가 지정되지 않은 경우 기본값은 manifest.level입니다. 기기 매니페스트의 커널 분기에 따라 다음과 같습니다.

  • 분기가 1이면 다음 단계로 진행하여 커널 버전을 확인합니다.
  • 분기가 2이면 매트릭스 매칭이 없습니다. VINTF 객체는 대신 FCM 버전 2에서 매트릭스의 커널 요구사항을 읽습니다.

그런 다음 커널 버전이 매칭됩니다. uname()에 있는 기기의 보고에 따라 다음과 같습니다.

  • 4.9.84(x <= 84인 <kernel version="4.9.x">를 포함하는 별도의 커널 섹션이 없으면 매트릭스 매칭이 없음)
  • 4.14.41(매트리스 매칭 없음, version보다 작음)
  • 4.14.42(매트릭스 매칭)
  • 4.14.43(매트릭스 매칭)
  • 4.1.22(x <= 22인 <kernel version="4.1.x">를 포함하는 별도의 커널 섹션이 없으면 매트릭스 매칭이 없음)

n을 제외한 값을 가진 각 <config> 항목과 관련해 적절한 <kernel> 섹션이 선택된 후에는 해당하는 항목이 /proc/config.gz에 있어야 합니다. 값이 n인 각 <config> 항목의 경우에는 해당하는 항목이 /proc/config.gz에 없어야 합니다. <value>의 콘텐츠는 등부호(따옴표 포함) 이후의 텍스트와 정확히 일치해야 합니다(선행 및 후행 공백이 잘린 개행 문자 또는 #까지).

다음 커널 구성은 매칭 성공의 예입니다.

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

다음 커널 구성은 매칭 실패의 예입니다.

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

SE 정책 매칭

SE 정책에는 다음과 같은 매칭이 필요합니다.

  • <sepolicy-version>은 모든 주 버전에 대한 부 버전의 닫힌 범위를 정의합니다. 기기에 의해 보고된 sepolicy 버전은 이러한 범위 중 하나 내에 속해야만 프레임워크와 호환됩니다. 매칭 규칙은 HAL 버전과 유사하며, sepolicy 버전이 범위의 최소 버전과 동일하거나 높은 경우 매칭이 이루어집니다. 최대 버전은 순수한 정보 제공의 용도로만 사용됩니다.
  • <kernel-sepolicy-version>, 즉 policydb 버전. 기기에 의해 보고된 security_policyvers()보다 작아야 합니다.

예: SE 정책 매칭 성공

프레임워크 호환성 매트릭스는 다음과 같은 sepolicy 정보를 명시합니다.

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

기기:

  • security_policyvers()에 의해 반환된 값이 30 이상이어야 합니다. 그렇지 않으면 매칭이 아닙니다. 예:
    • 기기가 29를 반환하는 경우 매칭이 아닙니다.
    • 기기가 31을 반환하면 매칭입니다.
  • SE 정책 버전은 25.0-∞ 또는 26.0-∞이어야 하며 그렇지 않으면 매칭이 아닙니다. ‘26.0’ 이후의 ‘-3’은 정보를 제공하는 용도로만 쓰입니다.

AVB 버전 매칭

AVB 버전에는 MAJOR.MINOR 형식의 MAJOR 버전과 MINOR 버전이 포함됩니다. (예: 1.0, 2.1) 자세한 내용은 버전 관리 및 호환성을 참조하세요. AVB 버전에는 다음과 같은 시스템 속성이 포함됩니다.

  • ro.boot.vbmeta.avb_version은 부트로더의 libavb 버전입니다.
  • ro.boot.avb_version은 Android OS(init/fs_mgr)의 libavb 버전입니다.

시스템 속성은 해당하는 libavb가 AVB 메타데이터 검증을 위해 사용되고 OK를 반환하는 경우에만 표시됩니다. 검증에 실패하거나 검증이 아예 발생하지 않은 경우에는 표시되지 않습니다.

호환성 매칭은 다음을 비교합니다.

  • sysprop ro.boot.vbmeta.avb_version을 프레임워크 호환성 매트릭스의 avb.vbmeta-version과 비교
    • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
  • sysprop ro.boot.avb_version을 프레임워크 호환성 매트릭스의 avb.vbmeta-version과 비교
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

부트로더 또는 Android OS에는 libavb 라이브러리의 사본 두 개가 포함될 수 있으며, 각 사본에는 업그레이드 기기 및 출시 기기와 관련된 여러 MAJOR 버전이 포함됩니다. 이 경우 동일한 서명되지 않은 시스템 이미지를 공유할 수 있지만 서명된 최종 시스템 이미지는 다릅니다(avb.vbmeta-version도 다름).

그림 1. AVB 버전 매칭(/system은 P, 다른 모든 파티션은 O).


그림 2. AVB 버전 매칭(모든 파티션은 P).

예: AVB 버전 매칭 성공

프레임워크 호환성 매트릭스는 다음과 같은 AVB 정보를 명시합니다.

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

기기:

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match 

ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

OTA 도중의 AVB 버전 매칭

Android 9 이하로 출시된 기기의 경우 Android 10으로 업데이트하면 프레임워크 호환성 매트릭스의 AVB 버전 요구사항이 기기의 현재 AVB 버전과 비교하여 매칭됩니다. AVB 버전에 OTA 도중의 주 버전 업그레이드가 있는 경우(예: 0.0에서 1.0으로) OTA 중 VINTF의 호환성 검사에 OTA 이후의 호환성이 반영되지 않습니다.

문제를 완화하기 위해 OEM은 OTA 패키지(compatibility.zip)에 가짜 AVB 버전을 배치하여 검사를 전달합니다. 방법은 다음과 같습니다.

  1. Android 9 소스 트리에 다음과 같은 CL을 선택합니다.
  2. 기기의 BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE를 정의합니다. 값은 OTA 이전의 AVB 버전 즉, 기기가 출시되었을 당시의 AVB 버전과 동일해야 합니다.
  3. OTA 패키지를 다시 빌드합니다.

이러한 변경사항은 다음 파일에 BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE를 compatibility-matrix.avb.vbmeta-version으로 자동 배치합니다.

  • 기기의 /system/compatibility_matrix.xml(Android 9에서 사용되지 않음)
  • OTA 패키지에 있는 compatibility.zip의 system_matrix.xml

이러한 변경사항은 /system/etc/vintf/compatibility_matrix.xml을 포함한 다른 프레임워크 호환성 매트릭스에 영향을 미치지 않습니다. OTA 이후에는 /system/etc/vintf/compatibility_matrix.xml의 새 값이 호환성 검사에 대신 사용됩니다.

VNDK 버전 매칭

기기 호환성 매트릭스는 compatibility-matrix.vendor-ndk.version에 필수 VNDK 버전을 선언합니다. 기기 호환성 매트릭스에 <vendor-ndk> 태그가 없으면 어떠한 요구사항도 지정되지 않으므로 항상 매칭으로 간주됩니다.

기기 호환성 매트릭스에 <vendor-ndk> 태그가 없으면 일치하는 <version>이 있는 <vendor-ndk> 항목이 프레임워크 매니페스트의 프레임워크에 의해 제공된 VNDK 공급업체 스냅샷에서 조회됩니다. 이러한 항목이 존재하지 않으면 매칭도 없습니다.

이러한 항목이 존재하는 경우에는 기기 호환성 매트릭스에 열거된 라이브러리 집합이 프레임워크 매니페스트에 명시된 라이브러리 집합의 하위 집합이어야 합니다. 그렇지 않으면 항목이 매칭으로 간주되지 않습니다.

  • 기기 호환성 매트릭스에 라이브러리가 열거되지 않은 특별한 경우에는 빈 집합이 모든 집합의 하위 집합이므로 항목이 항상 매칭으로 간주됩니다.

예: VNDK 버전 매칭 성공

기기 호환성 매트릭스에서 VNDK에 대해 다음과 같은 요구사항을 명시하는 경우:

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

프레임워크 매니페스트에서 버전 27을 가진 항목만 고려됩니다.

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

A 예시는 프레임워크 매니페스트와 {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}에 VNDK 버전 27이 있으므로 매칭입니다. 

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

B 예시는 매칭이 아닙니다. VNDK 버전 27이 프레임워크 매니페스트에 있지만 libjpeg.so가 VNDK 공급업체 스냅샷의 프레임워크에 의해 지원되지 않기 때문입니다. VNDK 버전 26은 무시됩니다.

시스템 SDK 버전 매칭

기기 호환성 매트릭스는 compatibility-matrix.system-sdk.version의 필수 시스템 SDK 버전 집합을 선언합니다. 집합이 프레임워크 매니페스트의 manifest.system-sdk.version에 선언된 제공된 시스템 SDK 버전의 하위 집합인 경우에만 매칭이 있습니다.

  • 기기 호환성 매트릭스에 시스템 SDK 버전이 열거되지 않은 특별한 경우에는 빈 집합이 모든 집합의 하위 집합이므로 항상 매칭으로 간주됩니다.

예: 시스템 SDK 버전 매칭 성공

기기 호환성 매트릭스에서 시스템 SDK에 대한 다음과 같은 요구사항을 명시하는 경우: 

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

그러면 프레임워크에서 시스템 SDK 버전 26 및 27을 제공해야 매칭됩니다.

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

A 예시는 매칭입니다.

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

B 예시는 매칭입니다.

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

C 예시는 시스템 SDK 버전 27이 제공되지 않으므로 매칭이 아닙니다.