Reguły dopasowywania

Obie pary macierzy zgodności i manifestów mają być ze sobą porównywane, aby sprawdzić, czy framework i implementacja dostawcy mogą ze sobą współpracować. Weryfikacja zakończy się powodzeniem, jeśli matryca zgodności platformy będzie pasować do manifestu urządzenia, a manifest platformy będzie pasować do matrycy zgodności urządzenia.

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

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

Wersja macierzy zgodności platformy jest zgodna

Aby dopasować plik manifestu urządzenia do macierzy zgodności platformy, wersja FCM dostawy 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 będzie dopasowania.

Gdy matryca zgodności platformy jest żądana z parametrem libvintf, dopasowanie zawsze się udaje, ponieważ libvintf otwiera manifest urządzenia, pobiera wersję FCM dostarczoną z urządzeniem i zwraca matrycę zgodności platformy w tej wersji FCM (plus niektóre opcjonalne warstwy HAL z matryc zgodności w wyższych wersjach FCM).

Dopasowania HAL

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

HIDL i natywne HAL

Reguły dopasowywania w przypadku interfejsów HIDL i natywnych interfejsów HAL są następujące:

  • Wiele elementów <hal> jest łączonych za pomocą operatora AND.
  • Elementy <hal> mogą mieć atrybut <hal optional="true">, aby oznaczyć je jako niewymagane.
  • Wiele elementów <version> w obrębie tego samego elementu <hal> jest połączonych relacją LUB. Jeśli podano co najmniej 2 wersje, wystarczy wdrożyć tylko jedną z nich. (Patrz Prawidłowe dopasowanie HAL do modułu DRM).
  • Wiele elementów <instance> i <regex-instance> w tym samym elemencie <hal> jest ocenianych za pomocą pojedynczej relacji AND, gdy element <hal> jest wymagany. (Patrz Pomyślne dopasowanie HAL do modułu DRM).

Przykład: udane dopasowanie HAL do modułu

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

Macierz Pasujący plik manifestu
2.5 2.5–2.∞. W macierzy zgodności symbol 2.5 oznacza 2.5-5.
2.5-7 2,5–2,∞. Oznacza to:
  • Minimalna wymagana wersja to 2.5, co oznacza, że plik manifestu udostępniający HAL w wersji 2.0–2.4 nie jest zgodny.
  • 2.7 to maksymalna wersja, o którą można poprosić. Oznacza to, że właściciel macierzy zgodności (platformy lub urządzenia) nie może poprosić o wersje nowsze 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 wersją interfejsu API 2.7.
  • -7 ma charakter wyłącznie informacyjny i nie wpływa na proces aktualizacji OTA.
Dlatego urządzenie z HAL w wersji 2.10 w pliku manifestu pozostaje zgodne z platformą, która w macierzy zgodności ma wartość 2.5-7.

Przykład: udane dopasowanie HAL w przypadku modułu DRM

Macierz zgodności platformy zawiera te informacje o wersji interfejsu HAL DRM:

<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ć JEDEN z tych przypadków:

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

MUSI wdrożyć wszystkie te instancje:

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

Warstwy HAL języka AIDL

Android w wersji 10 i nowszych obsługuje wersje interfejsów HAL AIDL w VINTF. Reguły dopasowania dla interfejsów HAL AIDL są podobne do reguł interfejsów HAL HIDL i natywnych, z tym wyjątkiem, że nie ma wersji głównych i na każdą instancję interfejsu HAL przypada dokładnie jedna wersja (1, jeśli wersja nie jest określona):

  • Wiele elementów <hal> jest łączonych za pomocą operatora AND.
  • Elementy <hal> mogą mieć atrybut <hal optional="true">, aby oznaczyć je jako niewymagane.
  • Wiele elementów <instance> i <regex-instance> w tym samym elemencie <hal> jest ocenianych za pomocą pojedynczej relacji AND, gdy element <hal> jest wymagany. (Patrz Prawidłowe dopasowanie HAL w przypadku wielu modułów).

Przykład: udane dopasowanie HAL do modułu

W przypadku HAL w wersji 5 reguła dopasowania jest taka:

Macierz Pasujący plik manifestu
5 5–∞. W macierzy zgodności symbol 5 oznacza 5-5.
5-7 5–∞. Oznacza to:
  • 5 to minimalna wymagana wersja, co oznacza, że plik manifestu z HAL w wersji 1–4 nie jest zgodny.
  • 7 to maksymalna wersja, o którą można poprosić. Oznacza to, że właściciel macierzy zgodności (platformy lub urządzenia) nie będzie prosić o wersje powyżej 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 macierzy zgodności wie tylko, że żądana usługa jest zgodna z interfejsem API w wersji 7.
  • -7 ma charakter wyłącznie informacyjny i nie wpływa na proces aktualizacji OTA.
Dlatego urządzenie z HAL w wersji 10 w pliku manifestu pozostaje zgodne z platformą, która w macierzy zgodności ma wartość 5-7.

Przykład: udane dopasowanie HAL w przypadku wielu modułów

Macierz zgodności platformy zawiera te informacje o wersjach interfejsów HAL wibratora i aparatu:

<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

Pasujące jądra

W sekcji <kernel> macierzy zgodności platformy opisano wymagania platformy dotyczące jądra systemu Linux na urządzeniu. Te informacje mają być porównywane z informacjami o jądrze, które są zgłaszane przez obiekt VINTF urządzenia.

Dopasowywanie gałęzi jądra

Każdy sufiks gałęzi jądra (np. 5.4-r) jest mapowany na unikalną wersję FCM jądra (np. 5). Mapowanie jest takie samo jak mapowanie między literami wersji (np. R) a wersjami FCM (np. 5).

Testy VTS wymagają, aby urządzenie wyraźnie określało wersję FCM jądra w pliku manifestu urządzenia, /vendor/etc/vintf/manifest.xml, jeśli spełniony jest 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 FCM jądra to 5 (sufiks gałęzi jądra r).
  • Wersja FCM jądra jest większa lub równa 5 (sufiks gałęzi jądra r).

Testy VTS sprawdzają, czy jeśli określono wersję FCM jądra, jest ona większa lub równa docelowej wersji FCM w pliku manifestu urządzenia.

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

Jeśli urządzenie ma docelową wersję FCM 4 (wydaną w Androidzie 10), ale działa na jądrze z gałęzi 4.19-r, w jego manifeście powinny być podane te informacje: 

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

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

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

Jeśli urządzenie korzysta z ogólnego obrazu jądra (GKI), a ciąg wersji jądra z /proc/version jest taki:

5.4.42-android12-0-00544-ged21d463f856

Następnie obiekt VINTF pobiera wersję Androida z wersji jądra i używa jej do określenia wersji FCM jądra. W tym przykładzie android12 oznacza wersję 6 FCM w jądrze (wydaną w Androidzie 12).

Szczegółowe informacje o sposobie analizowania ciągu wersji jądra znajdziesz w sekcji Wersje GKI.

Dopasowywanie wersji 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 pliku FCM o pasującej wersji FCM z tymi samymi wartościami ${ver} i ${major_rev} co jądro urządzenia (czyli version="${ver}.${major_rev}.${matrix_minor_rev}")); inne sekcje są ignorowane. Dodatkowo wersja pomocnicza jądra musi być wartością z macierzy zgodności (${kernel_minor_rev} >= ${matrix_minor_rev};). Jeśli żaden fragment <kernel> nie spełnia tych wymagań, nie ma dopasowania.

Przykład: wybieranie wymagań dotyczących dopasowania

Rozważmy hipotetyczny przypadek, w którym platformy zarządzania zgodą użytkowników w /system/etc/vintf deklarują te wymagania (tagi nagłówka i stopki zostały 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 wybierają wymagania jądra z FCM:

Docelowa wersja FCMWersja FCM jądraWersja jądraDopasuj do
3 (K)Nie określono4.4.106Brak dopasowania (niezgodność wersji dodatkowej)
3 (K)Nie określono4.4.1074.4-p
3 (K)Nie określono4.19.424.19-q (patrz uwaga pod tabelą)
3 (K)Nie określono5.4.415.4-r (patrz uwaga pod tabelą)
3 (K)3 (K)4.4.1074.4-p
3 (K)3 (K)4.19.42Brak dopasowania (brak gałęzi jądra 4.19-p)
3 (K)4 (Q)4.19.424.19-q
4 (Q)Nie określono4.4.107Brak dopasowania (brak gałęzi jądra 4.4-q)
4 (Q)Nie określono4.9.1654.9-q
4 (Q)Nie określono5.4.415.4-r (patrz uwaga pod tabelą)
4 (Q)4 (Q)4.9.1654.9-q
4 (Q)4 (Q)5.4.41Brak dopasowania (brak gałęzi jądra 5.4-q)
4 (Q)5 (R)4.14.1054.14-r
4 (Q)5 (R)5.4.415.4-r
5 (R)Nie określonokażdyTest VTS nie powiódł się (musisz określić wersję FCM jądra dla docelowej wersji FCM 5)
5 (R)4 (Q)każdyTest VTS nie powiódł się (wersja FCM jądra < docelowa wersja FCM)
5 (R)5 (R)4.14.1804.14-r

Dopasowywanie konfiguracji jądra

Jeśli sekcja <kernel> pasuje, proces jest kontynuowany przez dopasowanie elementów config do /proc/config.gz. W przypadku każdego elementu konfiguracji w macierzy zgodności wyszukuje /proc/config.gz, aby sprawdzić, czy konfiguracja jest obecna. Jeśli element konfiguracji ma wartość n w macierzy zgodności w sekcji <kernel>, musi być nieobecny w /proc/config.gz. Na koniec trzeba dodać, że element konfiguracji, którego nie ma w macierzy zgodności, może, ale nie musi być obecny w /proc/config.gz.

Przykład: dopasowywanie konfiguracji jądra

  • <value type="string">bar</value>pasuje do"bar". Cudzysłowy są pomijane w macierzy zgodności, ale występują w /proc/config.gz.
  • <value type="int">4096</value> pasuje do 4096, 0x1000 lub 0X1000.
  • <value type="int">0x1000</value> pasuje do 4096, 0x1000 lub 0X1000.
  • <value type="int">0X1000</value> pasuje do 4096, 0x1000 lub 0X1000.
  • <value type="tristate">y</value>pasuje doy.
  • <value type="tristate">m</value>pasuje dom.
  • <value type="tristate">n</value> oznacza, że element konfiguracji NIE może występować w /proc/config.gz.
  • <value type="range">1-0x3</value> odpowiada znakom 1, 2 lub 3 albo ich odpowiednikom w kodzie szesnastkowym.

Przykład: pomyślne dopasowanie jądra

Macierz zgodności frameworka z 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 dopasowywana jest gałąź jądra. Gałąź jądra jest określona w pliku manifestu urządzenia w elemencie manifest.kernel.target-level, który domyślnie ma wartość manifest.level, jeśli nie określono innej wartości:

  • Jeśli gałąź jądra w pliku manifestu urządzenia ma wartość 1, proces przechodzi do następnego kroku i sprawdza wersję jądra.
  • Jeśli gałąź jądra w pliku manifestu urządzenia ma wartość 2, nie ma dopasowania do macierzy. Obiekty VINTF odczytują wymagania jądra z macierzy w wersji FCM 2.

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

  • 4.9.84 (brak dopasowania do macierzy, chyba że istnieje osobna sekcja jądra z wartością <kernel version="4.9.x">, gdzie x <= 84)
  • 4.14.41 (brak dopasowania do macierzy, mniejszy niż version)
  • 4.14.42 (dopasowanie do macierzy)
  • 4.14.43 (dopasowanie do macierzy)
  • 4.1.22 (brak dopasowania do macierzy, chyba że istnieje osobna sekcja jądra z <kernel version="4.1.x">, gdzie x <= 22)

Po wybraniu odpowiedniej sekcji <kernel> dla każdego elementu <config> o wartości innej niż n odpowiedni wpis powinien znajdować się w sekcji /proc/config.gz; dla każdego elementu <config> o wartości n odpowiedni wpis nie powinien znajdować się w sekcji /proc/config.gz. Treść <value> powinna być identyczna z tekstem po znaku równości (w tym cudzysłowami) aż do znaku nowego wiersza lub #, z obciętymi początkowymi i końcowymi znakami białymi.

Poniższa konfiguracja jądra jest przykładem udanego dopasowania:

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

Poniższa konfiguracja jądra jest przykładem nieudanego dopasowania:

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

Dopasowania SEPolicy

SEPolicy wymaga tych dopasowań:

  • <sepolicy-version> określa zamknięty zakres wersji pomocniczych dla każdej wersji głównej. Wersja SEPolicy zgłoszona przez urządzenie musi mieścić się w jednym z tych zakresów, aby była zgodna z platformą. Reguły dopasowania są podobne do wersji HAL. Dopasowanie następuje, jeśli wersja SEPolicy jest wyższa lub równa minimalnej wersji w zakresie. Maksymalna wersja ma charakter wyłącznie informacyjny.
  • <kernel-sepolicy-version>, czyli wersja bazy danych zasad, musi być mniejsza niż security_policyvers() zgłaszana przez urządzenie.

Przykład: pomyślne dopasowanie do zasad SEPolicy

Macierz 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 lub równa 30. W przeciwnym razie nie będzie pasować. Na przykład:
    • Jeśli urządzenie zwróci wartość 29, nie jest zgodne.
    • Jeśli urządzenie zwróci wartość 31, oznacza to dopasowanie.
  • Wersja SEPolicy musi być z zakresu 25.0–∞ lub 26.0–∞. W przeciwnym razie nie będzie pasować. (Znak -3 po 26.0 ma charakter wyłącznie informacyjny).

Dopasowania wersji AVB

Wersja AVB zawiera wersję GŁÓWNĄ i wersję PODRZĘDNĄ w formacie GŁÓWNA.PODRZĘDNA (np. 1.0, 2.1). Więcej informacji znajdziesz w sekcji Wersje i zgodność. Wersja AVB ma te właściwości systemu:

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

Właściwość systemowa pojawia się tylko wtedy, gdy odpowiedni element libavb został użyty do weryfikacji metadanych AVB (i zwraca wartość OK). Nie występuje, jeśli weryfikacja się nie powiodła lub nie została przeprowadzona.

Dopasowanie pod względem zgodności porównuje te elementy:

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

Program rozruchowy lub system operacyjny Android może zawierać 2 kopie bibliotek, z których każda ma inną wersję GŁÓWNĄ dla urządzeń, na których przeprowadzono uaktualnienie, i urządzeń wprowadzanych na rynek.libavb W tym przypadku można udostępnić ten sam niepodpisany obraz systemu, ale ostateczne podpisane obrazy systemu są różne (z różnymi avb.vbmeta-version):

Rysunek 1. Wersja AVB jest zgodna (partycja /system to P, wszystkie inne partycje to O).



Rysunek 2. Wersja AVB jest zgodna (wszystkie partycje mają wartość P).

Przykład: udane dopasowanie wersji AVB

Macierz zgodności platformy zawiera 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 

Dopasowywanie wersji AVB podczas aktualizacji OTA

W przypadku urządzeń wprowadzonych na rynek z Androidem 9 lub starszym podczas aktualizacji do Androida 10 wymagania dotyczące wersji AVB w macierzy zgodności platformy są porównywane z obecną wersją AVB na urządzeniu. Jeśli podczas aktualizacji OTA wersja AVB zostanie uaktualniona do nowej wersji głównej (np. z 0.0 do 1.0), sprawdzenie zgodności VINTF w przypadku aktualizacji OTA nie odzwierciedla zgodności po aktualizacji OTA.

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

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

Te zmiany automatycznie umieszczają BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE jako compatibility-matrix.avb.vbmeta-version w tych plikach:

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

Te zmiany nie wpływają na inne matryce zgodności platform, w tym /system/etc/vintf/compatibility_matrix.xml. Po aktualizacji OTA do sprawdzania zgodności używana jest nowa wartość w /system/etc/vintf/compatibility_matrix.xml.

Wersja VNDK

Macierz zgodności urządzeń określa wymaganą wersję VNDK w compatibility-matrix.vendor-ndk.version. Jeśli w macierzy zgodności urządzeń nie ma tagu <vendor-ndk>, nie są narzucane żadne wymagania i zawsze jest ona uznawana za pasującą.

Jeśli macierz zgodności urządzeń zawiera tag <vendor-ndk>, w zestawie migawek dostawcy VNDK dostarczonym przez platformę w manifeście platformy wyszukiwane jest pole <vendor-ndk> z pasującym <version>. Jeśli taki wpis nie istnieje, nie ma dopasowania.

Jeśli taki wpis istnieje, zbiór bibliotek wymienionych w macierzy zgodności urządzenia musi być podzbiorem zbioru bibliotek wymienionych w pliku manifestu platformy. W przeciwnym razie wpis nie jest uznawany za pasujący.

  • W szczególnym przypadku, jeśli w macierzy zgodności urządzenia nie ma żadnych bibliotek, wpis jest zawsze uznawany za pasujący, ponieważ pusty zbiór jest podzbiorem dowolnego zbioru.

Przykład: zgodność wersji VNDK

Jeśli w macierzy zgodności urządzeń znajduje się 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 manifeście schematu brany jest pod uwagę tylko wpis z wersją 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 jest zgodny, ponieważ wersja VNDK 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 pasuje. Mimo że wersja VNDK 27 znajduje się w manifeście platformy, libjpeg.so nie jest obsługiwana przez platformę w tym migawce. Wersja 26 VNDK jest ignorowana.

Wersja pakietu SDK systemu jest zgodna

Macierz zgodności urządzeń deklaruje zestaw wymaganych wersji pakietu SDK systemu w compatibility-matrix.system-sdk.version. Dopasowanie występuje tylko wtedy, gdy zbiór jest podzbiorem podanych wersji pakietu SDK systemu zadeklarowanych w manifest.system-sdk.version w pliku manifestu platformy.

  • W szczególnym przypadku, jeśli w macierzy zgodności urządzenia nie ma wersji pakietu SDK systemu, zawsze jest ona uznawana za zgodną, ponieważ pusty zbiór jest podzbiorem dowolnego zbioru.

Przykład: zgodność wersji pakietu SDK systemu

Jeśli w macierzy zgodności urządzeń podano to wymaganie dotyczące pakietu SDK systemu: 

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

W takim przypadku platforma musi udostępniać wersje pakietu SDK systemu 26 i 27, aby były zgodne:

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

Przykład A jest dopasowaniem:

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

Przykład B jest dopasowaniem:

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

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