Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

매칭 규칙

호환성 매트릭스와 매니페스트로 이루어진 두 개의 쌍은 OTA 업데이트 시점에 조정되어 프레임워크와 공급업체 구현이 상호 작동할 수 있음을 검증해야 합니다. 이러한 검증은 프레임워크 호환성 매트릭스와 기기 매니페스트, 그리고 프레임워크 매니페스트와 기기 호환성 매트릭스 간의 매칭이 있을 때 이루어집니다. 다음 섹션에서는 다양한 구성요소에 의해 사용되는 매칭 규칙에 대해 상세히 설명합니다.

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

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

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

HAL 매칭

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

  • 여러 개의 <hal> 요소가 단일 AND 관계로 평가됩니다.
  • 같은 <hal>에 있는 여러 개의 <version> 요소는 OR 관계를 가집니다. 2개 이상이 지정된 경우 버전 중에서 하나만 구현하면 됩니다. 아래의 DRM 예시를 참조하세요.
  • 같은 <hal> 내의 여러 <instance><regex-instance> 요소는 단일 AND 관계로 평가됩니다. 아래의 DRM 예시를 참조하세요.

예시: 카메라 모듈의 HAL 매칭 성공

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

매트릭스 매칭 manifest
2.5 2.5-2.∞. 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이 있는 기기는 계속해서 호환성 매트릭스에 camera: 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

커널 매칭

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

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

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

OTA는 같은 ${ver}${major_rev}를 기기 커널로 보유한 <kernel> 섹션만 간주하며(예: version="${ver}.${major_rev}.${matrix_minor_rev}")) 다른 섹션은 무시됩니다. 또한 커널의 부 버전은 호환성 매트릭스(${kernel_minor_rev} >= ${matrix_minor_rev};)의 값이어야 합니다. <kernel> 섹션에서 이러한 요구사항을 충족하지 않는 경우에는 매칭이 이루어지지 않습니다.

<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>은 구성 항목이 /proc/config.gz에 있어서는 안 된다는 것을 의미합니다.
  • <value type="range">1-0x3</value>1, 2, 3 중 한 가지와 일치하거나 16진수와 같습니다.

예시: 커널 매칭 성공

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

<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>

커널 버전이 먼저 매칭됩니다. 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 이하로 출시된 기기의 경우 OTA 도중 프레임워크 호환성 매트릭스의 AVB 버전 요구사항이 기기의 최신 AVB 버전에 대해 매칭됩니다. AVB 버전에 OTA 도중의 주 버전 업그레이드가 있는 경우(예: 0.0에서 1.0) OTA의 검사에 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_OVERRIDEcompatibility-matrix.avb.vbmeta-version으로 자동 배치합니다.

  • 기기의 /system/compatibility_matrix.xml(Android 9에서 사용되지 않음)
  • OTA 패키지에 있는 compatibility.zipsystem_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이 제공되지 않으므로 매칭이 아닙니다.