Reguły dopasowywania

Dwie pary macierzy zgodności i plików manifestu powinny być uzgodnione w celu sprawdzenia, czy platforma i implementacja dostawcy mogą ze sobą współdziałać. Weryfikacja kończy się powodzeniem, gdy macierz zgodności platformy jest zgodny z plikiem manifestu urządzenia, a także między plikiem manifestu platformy a tabelą zgodności urządzenia.

Ta weryfikacja jest przeprowadzana w czasie kompilacji, generowania pakietu aktualizacji OTA, uruchamiania i testów zgodności VTS.

W następnych sekcjach znajdziesz szczegółowe informacje o regułach dopasowywania używanych przez różne komponenty.

Dopasowania wersji w ramach macierzy zgodności

Aby dopasować plik manifestu urządzenia do macierzy zgodności frameworka, wersja FCM określona przez manifest.target-level musi być dokładnie taka sama jak wersja FCM określona przez compatibility-matrix.level. W przeciwnym razie nie ma dopasowania.

Gdy libvintf jest używane do wysyłania żądania dotyczącego macierzy zgodności platformy, zawsze jest to zgodne z oczekiwaniami, ponieważ libvintf otwiera plik manifestu urządzenia, pobiera wersję FCM do wysyłania i zwraca macierz zgodności platformy w wersji FCM do wysyłania (oraz niektóre opcjonalne HAL-e z macierzy zgodności w wyższych wersjach FCM).

Mecze HAL

Reguła dopasowania HAL identyfikuje wersje elementów hal w pliku manifestu, które są uznawane za obsługiwane przez właściciela odpowiedniej matrycy zgodności.

HIDL i natywne interfejsy HAL

Poniżej znajdziesz reguły dopasowania HIDL i natywnych HAL.

  • Wiele elementów <hal> jest ocenianych w ramach jednej relacji ORAZ.
  • Elementy <hal> mogą mieć atrybuty <hal optional="true">, aby oznaczyć je jako opcjonalne.
  • Wiele elementów <version> w tym samym <hal> jest połączonych relacją LUB. Jeśli określisz co najmniej 2, musisz zaimplementować tylko jedną z nich. (zobacz przykład DRM poniżej).
  • Gdy wymagany jest element <hal>, elementy <instance> i <regex-instance> w tym samym elemencie <hal> są oceniane za pomocą pojedynczej relacji AND. (patrz poniżej przykład dotyczący <ahref="#drm">DRM)</ahref="#drm">

Przykład: pomyślne dopasowanie HAL do modułu

W przypadku interfejsu HAL w wersji 2.5 reguła dopasowania wygląda tak:

Matrix Odpowiedni plik manifestu
2.5 2,5–2,∞. W macierz zgodności 2.5 to skrót od 2.5-5.
2.5-7 2.5–2.∞. Oznacza to:
  • Minimalna wymagana wersja to 2.5, co oznacza, że plik manifestu zawierający HAL 2.0–2.4 nie jest zgodny.
  • 2.7 to maksymalna wersja, o którą można poprosić, co oznacza, że właściciel macierzy zgodności (platformy lub urządzenia) nie będzie prosić o wersje starsze niż 2.7. Właściciel pasującego pliku manifestu może nadal wyświetlać wersję 2.10 (na przykład), gdy żądana jest wersja 2.7. Właściciel macierzy zgodności wie tylko, że żądana usługa jest zgodna z interfejsem API w wersji 2.7.
  • -7 ma charakter wyłącznie informacyjny i nie ma wpływu na proces aktualizacji OTA.
W związku z tym urządzenie z HAL w wersji 2.10 w pliku manifestu pozostaje zgodne z ramami, które w swojej tabeli zgodności zawierają wartość 2.5-7.

Przykład: pomyślne dopasowanie HAL do modułu DRM

Tablica zgodności platformy zawiera te informacje o wersji 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>

Dostawca musi wdrożyć JEDNĄ z tych opcji:

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

Muszą też być spełnione wszystkie te warunki:

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

Listy HAL AIDL

Wszystkie wersje Androida nowsze niż 11 (z wyjątkiem Androida 11) obsługują wersje interfejsów AIDL HAL w VINTF. Reguły dopasowywania w przypadku interfejsów HAL AIDL są podobne do reguł HIDL i natywnych interfejsów HAL, z tym że nie ma wersji głównych, a każdy instancja interfejsu HAL ma dokładnie jedną wersję (1, jeśli wersja nie jest określona).

  • Wiele elementów <hal> jest ocenianych za pomocą pojedynczego związku ORAZ.
  • Elementy <hal> mogą mieć atrybuty <hal optional="true">, aby oznaczyć je jako opcjonalne.
  • Jeśli w jednym elemencie <hal> jest wymagana pojedyncza relacja ORAZ, wiele elementów <instance> i <regex-instance> w obrębie tego samego elementu <hal> jest oceniane. (patrz poniżej przykład <ahref="#vibrator">wibratora).</ahref="#vibrator">

Przykład: pomyślne dopasowanie HAL do modułu

W przypadku HAL w wersji 5 reguła dopasowania wygląda tak:

Matrix Pasujący plik manifestu
5 5–∞. W macierz zgodności 5 jest skrótem dla 5-5.
5-7 5-∞. Oznacza:
  • 5 jest minimalną wymaganą wersją, co oznacza, że plik manifestu podający HAL 1–4 nie jest zgodny.
  • 7 to maksymalna wersja, o którą można poprosić, co oznacza, że właściciel matrycy zgodności (platformy lub urządzenia) nie będzie prosić o wersje starsze niż 7. Właściciel pasującego pliku manifestu może nadal wyświetlać wersję 10 (na przykład), gdy żądana jest wersja 7. Właściciel matrycy zgodności wie tylko, że żądana usługa jest zgodna z wersją 7 interfejsu API.
  • -7 ma charakter wyłącznie informacyjny i nie ma wpływu na proces aktualizacji OTA.
W związku z tym urządzenie z HAL w wersji 10 w pliku manifestu pozostaje zgodne z ramami, które w swojej tabeli zgodności zawierają wartość 5-7.

Przykład: pomyślne dopasowanie HAL do wielu modułów

W ramach tej tabeli zgodności podano następujące informacje o wersjach interfejsów API:

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

Dostawca musi wdrożyć wszystkie te przypadki:

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

Mecze jądra

W sekcji <kernel> w ramach matrycy zgodności frameworku opisane są wymagania frameworku dotyczące jądra Linuksa na urządzeniu. Te informacje mają być dopasowywane do informacji dotyczących jądra, które są przekazywane przez obiekt VINTF urządzenia.

Dopasuj gałęzie jądra

Każdy przyrostek gałęzi jądra (np. 5.4-r) jest mapowany na unikalną wersję FCM jądra (np. 5). Mapowanie jest takie samo jak mapowanie liter wersji (np. R) i wersji FCM (np. 5).

Testy VTS wymuszają, aby urządzenie wyraźnie określało wersję jądra FCM w pliku manifestu urządzenia (/vendor/etc/vintf/manifest.xml), jeśli jest spełniony co najmniej jeden z tych warunków:

  • Wersja FCM jądra różni się od docelowej wersji FCM. Na przykład wspomniane urządzenie ma docelową wersję FCM 4, a wersja jądra FCM to 5 (sufiks gałęzi jądra: r).
  • Wersja FCM jądra jest większa lub równa 5 (suffiks gałęzi jądra: r).

Testy VTS wymagają, aby w przypadku podania wersji FCM jądra była ona większa lub równa docelowej wersji FCM w pliku manifestu urządzenia.

Przykład: określenie gałęzi jądra

Jeśli urządzenie ma docelową wersję FCM 4 (wydana w Androidzie 10), ale używa jądra z gałęzi 4.19-r, w pliku manifestu urządzenia należy określić: 

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

Obiekt VINTF sprawdza zgodność jądra z wymaganiami w gałęzi jądra 4.19-r, która jest określona w wersji 5 FCM. Te wymagania są tworzone na podstawie kernel/configs/r/android-4.19 w drzewie źródłowym Androida.

Przykład: określenie gałęzi jądra dla GKI

Jeśli urządzenie korzysta z Generic Kernel Image (GKI), a ciąg znaków wersji jądra z /proc/version ma postać:

5.4.42-android12-0-00544-ged21d463f856

Następnie obiekt VINTF pobiera wersję Androida z wersji jądra i na jej podstawie określa wersję FCM jądra. W tym przykładzie android12 oznacza FCM jądra w wersji 6 (udostępnianej w Androidzie 12).

Szczegółowe informacje o parsowaniu ciągu wersji jądra znajdziesz w artykule Obsługa wersji GKI.

Dopasuj wersje jądra

Macierz może zawierać kilka sekcji <kernel>, z których każda ma inny atrybut version w formacie:

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

Obiekt VINTF uwzględnia tylko sekcję <kernel> z FCM z odpowiednią wersją FCM z tymi samymi wartościami ${ver} i ${major_rev} co jądro urządzenia (tzn. version="${ver}.${major_rev}.${matrix_minor_rev}"); inne sekcje są ignorowane. Dodatkowo drobna poprawka w jądrze musi być wartością z macierzy zgodności (${kernel_minor_rev} >= ${matrix_minor_rev}). Jeśli żadna sekcja <kernel> nie spełnia tych wymagań, oznacza to brak zgodności.

Przykład: wybieranie wymagań dotyczących dopasowywania

Rozważmy hipotetyczny przypadek, w którym pliki FCM w /system/etc/vintf deklarują następujące wymagania (tagi nagłówka i stopki są pominięte): 

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

Docelowa wersja FCM, wersja FCM jądra i wersja jądra razem określają wymagania dotyczące jądra z FCM:

Docelowa wersja FCMWersja FCM jądraWersja jądraDopasuj do
3 (K)nie określono4.4.106 Brak dopasowania (niezgodność wersji podrzędnej)
3 (K)nie określono4.4.107 4.4-p
3 (K)nie określono4.19.42 4.19-q (patrz uwaga poniżej)
3 (K)nie określono5.4.41 5.4-r (patrz uwaga poniżej)
3 (K)3 (K) 4.4.107 4.4-p
3 (K)3 (K) 4.19.42 Brak dopasowania (brak gałęzi jądra 4.19-p)
3 (K)4 (Q) 4.19.42 4.19-q
4 (Q)nie określono4.4.107 Brak dopasowania (brak gałęzi jądra 4.4-q)
4 (Q)nie określono4.9.165 4.9-q
4 (Q)nie określono5.4.41 5.4-r (zobacz uwagę poniżej)
4 (Q)4 (Q) 4.9.165 4.9-q
4 (Q)4 (K) 5.4.41 Brak dopasowania (brak gałęzi jądra 5.4-q)
4 (K)5 (R) 4.14.1054.14-r
4 (Q)5 (R) 5.4.41 5.4-r
5 (R)nie określonokażdy VTS nie działa (musisz określić wersję FCM rdzenia dla docelowej wersji FCM 5)
5 (R)4 (Q) każdy VTS nie działa (wersja FCM jądra jest starsza niż docelowa wersja FCM)
5 (R)5 (R) 4.14.1804.14-r

Dopasuj konfiguracje jądra

Jeśli sekcja <kernel> jest zgodna, proces jest kontynuowany, próbując dopasować elementy config do /proc/config.gz. W przypadku każdego elementu konfiguracji w tablicy zgodności sprawdza wartość /proc/config.gz, aby sprawdzić, czy konfiguracja jest obecna. Jeśli element konfiguracji ma wartość n w tablicy zgodności w sekcji dopasowania <kernel>, nie może być obecny w sekcji /proc/config.gz. Na koniec: element konfiguracji, który nie znajduje się w tablicy zgodności, może się w niej znajdować lub nie./proc/config.gz

Przykład: dopasowywanie konfiguracji jądra

  • <value type="string">bar</value> pasuje do "bar". Cudzysłówy są pomijane w tabeli zgodności, ale występują w pliku /proc/config.gz.
  • <value type="int">4096</value> pasuje do 4096, 0x1000 lub 0X1000.
  • <value type="int">0x1000</value> pasuje do wartości 4096, 0x1000 lub 0X1000.
  • <value type="int">0X1000</value> pasuje do 4096, 0x1000 lub 0X1000.
  • <value type="tristate">y</value> pasuje do y.
  • <value type="tristate">m</value> pasuje do m.
  • <value type="tristate">n</value> oznacza, że element konfiguracji NIE może istnieć w elementach /proc/config.gz.
  • <value type="range">1-0x3</value> odpowiada 1, 2 lub 3 albo ich szesnastkowemu odpowiednikowi.

Przykład: udane dopasowanie jądra

Matryca zgodności systemu z platformą FCM w wersji 1 zawiera te informacje o jądrze:

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

Najpierw dopasowywany jest element gałęzi jądra. Gałąź jądra jest określona w pliku manifestu urządzenia w sekcji manifest.kernel.target-level. Jeśli nie jest określona, domyślnie jest to manifest.level. Jeśli gałąź jądra w pliku manifestu urządzenia:

  • wynosi 1, przechodzi do następnego kroku i sprawdza wersję jądra.
  • jest 2, nie pasuje do macierzy. Obiekty VINTF odczytują wymagania jądra z macierzy w FCM w wersji 2.

Wtedy dopasowywana jest wersja jądra. Jeśli urządzenie w uname() zgłasza:

  • 4.9.84 (brak dopasowania do macierzy, chyba że istnieje oddzielna sekcja jądra z funkcją <kernel version="4.9.x">, gdzie x <= 84)
  • 4.14.41 (brak dopasowania do macierzy, mniejsza niż version)
  • 4.14.42 (dopasowywanie do macierzy)
  • 4.14.43 (zgodność z macierzą)
  • 4.1.22 (brak dopasowania do macierzy, chyba że istnieje odrębna sekcja jądra z <kernel version="4.1.x">, gdzie x <= 22)

Po wybraniu odpowiedniej sekcji <kernel> oczekujemy, że w przypadku każdego elementu <config> o wartości innej niż n odpowiedni wpis będzie obecny w sekcji /proc/config.gz, a w przypadku każdego elementu <config> o wartości n odpowiedni wpis nie będzie obecny w sekcji /proc/config.gz. Zawartość <value> powinna dokładnie odpowiadać tekstowi po znaku równości (w tym cudzysłowach) do znaku nowego wiersza lub #, przy czym odstępy wiodące i zakończone powinny zostać obcięte.

Przykładem dopasowania jest następująca konfiguracja jądra:

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

Przykładem nieudanego dopasowania jest ta konfiguracja jądra:

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

Pasujące zasady SE

Zasady dotyczące wyszukiwania na stronie wymagają tych dopasowań:

  • <sepolicy-version> definiuje zamknięty zakres wersji podrzędnych dla każdej wersji głównej. Wersja sepolicy zgłaszana przez urządzenie musi mieścić się w jednym z tych zakresów, aby była zgodna z ramami. Zasady dopasowania są podobne do wersji HAL; dopasowanie występuje, jeśli wersja sepolicy jest większa lub równa wersji minimalnej dla zakresu. Wersja maksymalna ma charakter czysto informacyjny.
  • <kernel-sepolicy-version> np. wersja policydb. Musi być mniejsza niż security_policyvers() zgłoszona przez urządzenie.

Przykład: pomyślne dopasowanie do zasad SE

Tablica zgodności platformy zawiera te informacje o sepolicy: 

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

Na urządzeniu:

  • Wartość zwracana przez funkcję security_policyvers() musi być większa niż lub równa 30. W przeciwnym razie się nie uda. Na przykład:
    • Jeśli urządzenie zwróci wartość 29, nie będzie to pasujące urządzenie.
    • Jeśli urządzenie zwróci wartość 31, będzie to oznaczać dopasowanie.
  • Wersja zasad SE musi być 25.0-∞ lub 26.0-∞. W przeciwnym razie nie będzie pasować. (Wskazówka „-3” po wskazówce „26.0” ma charakter wyłącznie informacyjny).

Dopasowania wersji AVB

Wersja AVB zawiera wersję GŁÓWNA i PODRZĘDNA w formacie GŁÓWNA.PODRZĘDNA (np. 1.0, 2.1). Szczegółowe informacje znajdziesz w artykule na temat wersji i zgodności. Wersja AVB ma te właściwości systemowe:

  • ro.boot.vbmeta.avb_version to wersja libavb programu rozruchowego
  • ro.boot.avb_version to wersja libavb w systemie operacyjnym Android (init/fs_mgr)

Właściwość systemowa pojawia się tylko wtedy, gdy odpowiednia biblioteka libavb została użyta do zweryfikowania metadanych AVB (i zwraca OK). Nie ma go, jeśli wystąpił błąd weryfikacji (lub nie przeprowadzono żadnej weryfikacji).

Dopasowanie zgodności porównuje te elementy:

  • sysprop ro.boot.vbmeta.avb_version z wartością avb.vbmeta-version z tablicy zgodności platformy;
    • 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 z avb.vbmeta-version z tablicy zgodności platformy.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Bootloader lub system operacyjny Android może zawierać 2 kopie bibliotek libavb, z których każda ma inną wersję GŁÓWNĄ dla urządzeń z aktualizacją i urządzeń z wersją wstępną. W takim przypadku można udostępnić ten sam niepodpisany obraz systemu, ale końcowe podpisane obrazy systemu są różne (z różnymi wartościamiavb.vbmeta-version):

Rysunek 1. Dopasowanie wersji AVB (/system to P, wszystkie inne partycje to O).



Rysunek 2. Zgodność wersji AVB (wszystkie partycje to P).

Przykład: pomyślne dopasowanie wersji AVB

W ramach tej matrycy zgodności podano te informacje o AVB:

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

Na urządzeniu:

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 

Dopasowanie wersji AVB podczas OTA

W przypadku urządzeń z Androidem 9 lub starszym, które są aktualizowane do Androida 10, wymagania dotyczące wersji AVB w matrycy zgodności frameworku są dopasowywane do bieżącej wersji AVB na urządzeniu. Jeśli wersja AVB ma uaktualnioną wersję główną podczas aktualizacji OTA (np. z 0.0 do 1.0), kontrola zgodności VINTF w OTA nie odzwierciedla zgodności po OTA.

Aby rozwiązać ten problem, producent OEM może umieścić w pakiecie OTA (compatibility.zip) fałszywą wersję AVB, aby przejść weryfikację. Aby to zrobić:

  1. Wybierz te listy CL do drzewa źródłowego Androida 9:
  2. Określ BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE dla urządzenia. Jego wartość powinna być równa wersji AVB przed aktualizacją OTA, czyli wersji AVB urządzenia w momencie jego wprowadzenia na rynek.
  3. Utwórz ponownie pakiet OTA.

Te zmiany powodują automatyczne umieszczenie elementu BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE jako compatibility-matrix.avb.vbmeta-version w tych plikach:

  • /system/compatibility_matrix.xml(nie jest używany w Androidzie 9) na urządzeniu.
  • system_matrix.xml w compatibility.zip w pakiecie OTA

Te zmiany nie mają wpływu na inne matrycy zgodności frameworków, w tym /system/etc/vintf/compatibility_matrix.xml. Po aktualizacji OTA do sprawdzania zgodności używana jest nowa wartość w polu /system/etc/vintf/compatibility_matrix.xml.

Dopasowania wersji VNDK

Tablica zgodności urządzeń deklaruje wymaganą wersję VNDK w zasadzie compatibility-matrix.vendor-ndk.version. Jeśli tablica zgodności urządzenia nie zawiera tagu <vendor-ndk>, nie są narzucane żadne wymagania i dlatego są zawsze uznawane za dopasowanie.

Jeśli tablica zgodności urządzeń zawiera tag <vendor-ndk>, pozycja <vendor-ndk> z pasującym atrybutem <version> jest przeszukiwana z zestawu zrzutów dostawcy VNDK podanych przez platformę w pliku manifestu platformy. Jeśli taki wpis nie istnieje, nie ma dopasowania.

Jeśli taki wpis istnieje, zestaw bibliotek wymienionych w macierz zgodności urządzenia musi być podzbiorem zestawu bibliotek określonych w pliku manifestu frameworka. W przeciwnym razie wpis nie jest uznawany za pasujący.

  • W szczególnym przypadku, gdy w macierz zgodności urządzenia nie ma wymienionych żadnych bibliotek, wpis jest zawsze uznawany za dopasowanie, ponieważ pusty zbiór jest podzbiorem dowolnego zbioru.

Przykład: pomyślne dopasowanie wersji VNDK

Jeśli tablica zgodności urządzeń zawiera to wymaganie dotyczące VNDK: 

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

W pliku manifestu platformy uwzględniany jest tylko wpis w wersji 27.

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

Przykład A pasuje, ponieważ VNDK w wersji 27 znajduje się w pliku manifestu platformy, a {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}. 

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

Przykład B nie jest zgodny. Mimo że w pliku manifestu platformy VNDK znajduje się wersja 27, platforma w tym zrzucie nie obsługuje funkcji libjpeg.so. Wersja VNDK 26 jest ignorowana.

Jednakowe wersje pakietu SDK systemu

W macierz zgodności urządzeń w elementach compatibility-matrix.system-sdk.version podano wymaganą wersję System SDK. Dopasowanie występuje tylko wtedy, gdy zbiór jest podzbiorem podanych wersji pakietu System SDK, jak określono w manifest.system-sdk.version w pliku manifestu frameworku.

  • W szczególnym przypadku, gdy w macierzy zgodności urządzeń nie ma wymienionych wersji pakietu SDK systemu, zawsze jest to uznawane za dopasowanie, ponieważ pusty zbiór jest podzbiorem dowolnego zbioru.

Przykład: udane dopasowanie wersji pakietu systemowego pakietu SDK

Jeśli w ramach matrycy zgodności urządzeń podano następujący wymóg dotyczący System SDK: 

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

Następnie framework musi udostępniać pakiet SDK systemu w wersji 26 lub 27.

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

Przykład A jest zgodny.

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

Przykład B to dopasowanie.

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

Przykład C nie pasuje, ponieważ nie podano wersji pakietu System SDK 27.