Pasujące reguły

Dwie pary macierzy zgodności i plików manifestu powinny uzgodniony w celu zweryfikowania, platformy i implementacji dostawców mogą ze sobą współpracować. Ta weryfikacja uda się dopasować macierz zgodności platformy w pliku manifestu urządzenia oraz między plikiem manifestu platformy a urządzeniem. macierz zgodności.

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

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

Zgodność wersji macierzy zgodności platformy

Aby dopasować plik manifestu urządzenia do macierzy zgodności platformy, wersję FCM związaną z dostawą określoną przez: manifest.target-level musi być dokładnie taka sama jak wersja FCM określona przez compatibility-matrix.level Inaczej nie ma dopasowania.

Gdy za pomocą interfejsu libvintf wysyła żądanie macierzy zgodności platformy, to dopasowanie jest zawsze się udało, ponieważ libvintf otwiera plik manifestu urządzenia i pobiera informacje o dostawie FCM i zwraca macierz zgodności platformy z daną wersją FCM dostawy (plus niektóre opcjonalne HAL z tabel zgodności w wyższych wersjach FCM).

Mecze HAL

Reguła dopasowania HAL określa wersje elementów hal w plik manifestu, który jest uznawany za obsługiwany przez właściciela odpowiedniego macierz zgodności.

HIDL i natywne HAL

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

  • Wiele elementów <hal> jest ocenianych za pomocą jednego operatora ORAZ. relacji.
  • Elementy <hal> mogą mieć atrybut <hal optional="true"> umożliwiający oznaczenie ich jako nie jest wymagane.
  • Wiele elementów <version> w obrębie tego samego <hal> mają LUB. Jeśli określono więcej niż 2 wartości, Trzeba wdrożyć jedną z wersji. (zobacz przykład DRM poniżej).
  • Wiele elementów <instance> i <regex-instance> elementów w obrębie tego samego Wartości <hal> są oceniane w ramach pojedynczej relacji ORAZ, gdy funkcja Pole <hal> jest wymagane. (Zobacz <ahref="#drm">przykład DRM poniżej.)</ahref="#drm">

Przykład: udane dopasowanie HAL do modułu

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

Matrix Odpowiedni plik manifestu
2.5 2,5–2°∞. W tabeli zgodności 2.5 to skrót od 2.5-5
2.5-7 2,5–2°∞. Wskazuje:
  • 2.5 to minimalna wymagana wersja, co oznacza, że plik manifestu z zasobami HAL Wersje 2.0–2.4 są niezgodne.
  • 2.7 to maksymalna wersja, której można zażądać, co oznacza, że właściciel tablica zgodności (ramka lub urządzenie) nie żąda wersji powyżej 2,7. Właściciel pasującego pliku manifestu nadal może wyświetlać wersję 2.10 (np.) gdy wymagany jest kod 2.7. Właściciel macierzy zgodności wie tylko że żądana usługa jest zgodna z interfejsem API w wersji 2.7.
  • Wartość -7 ma wyłącznie charakter informacyjny i nie wpływa na proces aktualizacji OTA.
. Oznacza to, że urządzenie z HAL w wersji 2.10 w pliku manifestu pozostaje zgodne z ramami, które określają, 2.5-7 w tabeli zgodności.

Przykład: udane dopasowanie HAL dla modułu DRM

Tablica zgodności platformy zawiera te informacje o wersji w przypadku 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ć JEDEN z tych przypadków: albo

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

ORAZ musi też zaimplementować wszystkie poniższe wystąpienia:

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ługuje wersje HAL AIDL w VINTF. Reguły dopasowania HAL AIDL są podobne do reguł HIDL i natywnych HAL, z tym że nie ma wersji głównych i istnieje dokładnie 1 wersja na instancję HAL (1, jeśli wersja jest nieokreślona).

  • Wiele elementów <hal> jest ocenianych za pomocą jednego operatora ORAZ. relacji.
  • Elementy <hal> mogą mieć atrybut <hal optional="true"> umożliwiający oznaczenie ich jako nie jest wymagane.
  • Wiele elementów <instance> i <regex-instance> elementów w obrębie tego samego Wartości <hal> są oceniane w ramach pojedynczej relacji ORAZ, gdy funkcja Pole <hal> jest wymagane. (Zobacz <ahref="#vibrator">przykład wibratora poniżej).</ahref="#vibrator">

Przykład: udane dopasowanie HAL do modułu

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

Matrix Odpowiedni plik manifestu
5 5-∞. W tabeli zgodności 5 to skrót od 5-5
5-7 5-∞. Wskazuje:
  • 5 to minimalna wymagana wersja, co oznacza, że plik manifestu z zasobami HAL Wartości 1–4 są niezgodne.
  • 7 to maksymalna wersja, której można zażądać, co oznacza, że właściciel tablica zgodności (ramka lub urządzenie) nie żąda wersji powyżej 7. Właściciel pasującego pliku manifestu nadal może wyświetlać wersję 10 (np.) gdy wymagane jest podanie liczby 7. Właściciel macierzy zgodności wie tylko że żądana usługa jest zgodna z interfejsem API w wersji 7.
  • Wartość -7 ma wyłącznie charakter informacyjny i nie wpływa na proces aktualizacji OTA.
. Oznacza to, że urządzenie z HAL w wersji 10 w pliku manifestu pozostaje zgodne z ramami, które określają, 5-7 w tabeli zgodności.

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

Tablica zgodności platformy zawiera te informacje o wersji w przypadku kluczy HAL do wibracji 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 zaimplementować wszystkie te instancje:

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

Sekcja <kernel> macierzy zgodności platformy opisuje wymagania platformy dotyczące jądra systemu Linux na urządzeniu. Ten które mają być dopasowane do informacje na temat jądra zgłaszanego przez obiekt VINTF urządzenia.

Dopasuj gałęzie jądra

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

Testy VTS wymuszają, aby urządzenie jawnie określało wersję FCM jądra w Plik 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 parametr wspomniane urządzenie ma docelową wersję FCM w wersji 4, a jej wersję FCM w jej jądrze to 5 (jądro sufiks gałęzi r).
  • Wersja FCM jądra jest większa lub równa 5 (sufiks gałęzi jądra r).
.

Testy VTS wymuszają, że jeśli określona jest wersja FCM jądra, wersja FCM jądra to jest równa docelowej wersji FCM w pliku manifestu urządzenia lub jej równa.

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

Jeśli urządzenie ma docelowy FCM w wersji 4 (opublikowanej w Androidzie 10), ale uruchamia jądro z gałęzi 4.19-r, plik manifestu urządzenia powinien zawierać te informacje: 

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

Obiekt VINTF sprawdza zgodność jądra pod kątem wymagań jądra 4.19-r gałąź określona w FCM w wersji 5. Wymagania te opierają się 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) i ciągu tekstowego jądra z /proc/version wygląda tak:

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, wersję FCM jądra systemu operacyjnego. W tym przykładzie android12 oznacza FCM w wersji 6 jądra (opublikowane w Androidzie 12).

Szczegółowe informacje o tym, jak jest analizowany ciąg znaków wersji jądra, znajdziesz w sekcji Obsługa wersji GKI.

Dopasuj wersje jądra

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

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

Obiekt VINTF uwzględnia tylko sekcję <kernel> z FCM z pasującą wersją FCM z taką samą ${ver} i ${major_rev} jako jądro urządzenia (tzn. version="${ver}.${major_rev}.${matrix_minor_rev}"); inne sekcje są ignorowane. Dodatkowo minimalna wersja z jądra musi być wartością z tablicy zgodności (${kernel_minor_rev} >= ${matrix_minor_rev};). Jeśli żadna sekcja <kernel> nie spełnia warunków do tych wymagań, to nie zostaną spełnione.

Przykład: wybierz wymagania dotyczące dopasowania

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

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

Jądro są wybierane przez docelowe wersje FCM, FCM jądra i wersje jądra. wymagania określone przez FCM:

Docelowa wersja FCMWersja FCM jądraWersja jądraDopasuj do
3 (K)nie określono4.4.106 Brak dopasowania (drobna niezgodność wersji)
3 (K)nie określono4.4.107 4.4-p
3 (K)nie określono4.19.42 4.19-q (zobacz uwagę poniżej)
3 (K)nie określono5.4.41 5.4-r (zobacz uwagę 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 (K) 4.19.42 4.19-q
4 (K)nie określono4.4.107 Brak dopasowania (brak gałęzi jądra 4.4-q)
4 (K)nie określono4.9.165 4.9-q
4 (K)nie określono5.4.41 5.4-r (zobacz uwagę poniżej)
4 (K)4 (K) 4.9.165 4.9-q
4 (K)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 (K)5 (R) 5.4.41 5.4-r
5 (R)nie określonokażdy Błąd VTS (należy określić wersję FCM jądra dla docelowej wersji FCM w wersji 5)
5 (R)4 (K) każdy Błąd VTS (wersja FCM jądra < docelowa wersja FCM)
5 (R)5 (R) 4.14.1804.14-r

Dopasuj konfiguracje jądra

Jeśli sekcja <kernel> zgadza się, proces będzie kontynuowany. próbując dopasować config elementy do /proc/config.gz Dla każdego elementu konfiguracji w zgodności macierz, sprawdza, czy konfiguracja to /proc/config.gz obecnie. Gdy element konfiguracji ma w zgodności wartość n dla pasującej sekcji <kernel>, musi jej brakować od /proc/config.gz. Element konfiguracji, którego nie ma w parametrze /proc/config.gz może nie występować w tabeli zgodności.

Przykład: dopasowywanie konfiguracji jądra

  • Dopasowania: <value type="string">bar</value> "bar" Cudzysłowy są pomijane w macierzy zgodności, ale występują w usłudze /proc/config.gz.
  • Dopasowania: <value type="int">4096</value> 4096, 0x1000 lub 0X1000.
  • Dopasowania: <value type="int">0x1000</value> 4096, 0x1000 lub 0X1000.
  • Dopasowania: <value type="int">0X1000</value> 4096, 0x1000 lub 0X1000.
  • Dopasowania: <value type="tristate">y</value> y
  • Dopasowania: <value type="tristate">m</value> m
  • <value type="tristate">n</value> oznacza konfigurację element NIE może istnieć w lokalizacji /proc/config.gz.
  • Dopasowania: <value type="range">1-0x3</value> 1, 2 lub 3 lub odpowiednik szesnastkowy.

Przykład: udane dopasowanie jądra

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

Gałąź jądra jest dopasowywana jako pierwsza. Gałąź jądra jest określona w pliku manifestu urządzenia w polu manifest.kernel.target-level, który przyjmuje wartość domyślną manifest.level jeśli nie określono pierwszego terminu. Jeśli gałąź jądra w pliku manifestu urządzenia:

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

Wtedy dopasowywana jest wersja jądra. Jeśli urządzenie w budynku uname() raportów:

  • 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 (dopasowanie do macierzy)
  • 4.14.43 (dopasowanie do macierzy)
  • 4.1.22 (brak dopasowania do macierzy, chyba że istnieje oddzielna sekcja jądra) z wartością <kernel version="4.1.x">, gdzie x <= 22)

Po wybraniu odpowiedniej sekcji <kernel> w przypadku każdy element <config> o wartości innej niż n, oczekuje, że odpowiedni wpis będzie znajdować się w /proc/config.gz; dla każdego elementu <config> o wartości n oczekujemy odpowiadający wpisowi, który nie ma być w /proc/config.gz. Śr oczekiwanie, że treść ciągu <value> będzie dokładnie odpowiadać tekstowi po znaku równości (wraz z cudzysłowami) do znaku nowego wiersza lub # z obciętym odstępem na początku i na końcu ciągu.

Oto przykład udanego dopasowania 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"

Taka 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

Pasujące zasady SE

Zasada SE wymaga tych dopasowań:

  • <sepolicy-version> określa zamknięty zakres osób niepełnoletnich 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ł zgodny z platformą. Dopasowanie są podobne do wersji HAL, pasuje, jeśli wersja sepolicy to wyższą lub równą minimalnej wersji w danym zakresie. Maksymalna wersja to czysto informacyjna.
  • <kernel-sepolicy-version>, czyli wersja bazy danych policydb. Musi być mniejsza niż wartość security_policyvers() zgłoszona przez urządzenie.

Przykład: udane dopasowanie 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 nie więcej niż 30. W przeciwnym razie się nie uda. Na przykład:
    • Jeśli urządzenie zwraca kod 29, nie oznacza to dopasowania.
    • Jeśli urządzenie zwróci kod 31, oznacza to dopasowanie.
  • Wersja zasady SE musi mieć format 25.0-∞ lub 26.0-∞. W przeciwnym razie nie jest dopasowania. („-3” po „26.0” to całkowita wartość tylko informacyjną).

Pasujące wersje AVB

Wersja AVB zawiera wersję MAJOR i wersję MINOR w formacie jako GŁÓWNA.POMOCNA (np. 1,0 i 2,1). Więcej informacji: Kontrola wersji i zgodność. Wersja AVB ma te właściwości systemowe:

  • ro.boot.vbmeta.avb_version to wersja libavb w programie rozruchowym
  • ro.boot.avb_version to wersja libavb w: System operacyjny Android (init/fs_mgr)

Właściwość systemowa pojawia się tylko wtedy, gdy użyto odpowiedniej biblioteki libavb w celu zweryfikowania metadanych AVB (i zwraca wartość OK). Pole nie występuje, jeśli weryfikacja się nie powiodła (lub w ogóle nie przeprowadzono weryfikacji).

Zgodność obejmuje takie elementy:

  • sysprop ro.boot.vbmeta.avb_version z avb.vbmeta-version z tabeli 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 tabeli 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ć dwie kopie pliku libavb i bibliotekami. Każda z nich ma inną wersję MAJOR na potrzeby uaktualniania urządzeń urządzenia. W takim przypadku można udostępnić ten sam niepodpisany obraz systemu, ale ostateczne podpisane obrazy systemu są różne (różnią się avb.vbmeta-version):

Rysunek 1. Zgodność wersji AVB (/system to P, wszystkie pozostałe partycje są oznaczone jako O).



Rysunek 2. Zgodność wersji AVB (wszystkie partycje to 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 

Dopasowanie wersji AVB podczas OTA

Na urządzeniach z Androidem 9 lub starszym po aktualizacji do Android 10, AVB wymagania wersji w macierzy zgodności platformy są dopasowywane do bieżącego AVB w wersji zapisanej na urządzeniu. Jeśli wersja AVB została uaktualniona podczas aktualizacji OTA (na przykład od 0.0 do 1.0), weryfikacja zgodności VINTF w OTA nie odzwierciedla jej po OTA.

Aby rozwiązać ten problem, producent OEM może umieścić fałszywą wersję AVB w pakiecie OTA. (compatibility.zip), 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ść wersja AVB musi być równa wersji AVB przed OTA. Oznacza to, że wersja AVB urządzenia była który został już wprowadzony.
  3. Utwórz ponownie pakiet OTA.

Zmiany te są automatycznie wprowadzane BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE jako compatibility-matrix.avb.vbmeta-version w tych plikach:

  • /system/compatibility_matrix.xml (nieużywane w Androidzie 9) na urządzeniu
  • system_matrix.xml w compatibility.zip w pakiecie OTA

Te zmiany nie mają wpływu na inne macierzy zgodności z platformami, w tym /system/etc/vintf/compatibility_matrix.xml Po zakończeniu aktualizacji OTA nowa wartość w argumencie Zamiast tego do sprawdzania zgodności używany jest interfejs /system/etc/vintf/compatibility_matrix.xml.

Zgodność wersji VNDK

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

Jeśli tablica zgodności urządzeń zawiera atrybut <vendor-ndk> tag, wpis <vendor-ndk> z pasującym Domena <version> została wyszukana na podstawie zestawu zrzutów dostawcy VNDK które udostępnia platforma w pliku manifestu platformy. Jeśli taki wpis nie zostanie nie ma żadnego dopasowania.

Jeśli taki wpis istnieje, zestaw bibliotek wyliczonych w urządzeniu tablica zgodności musi być podzbiorem zbiorów bibliotek określonych w plik manifestu platformy; w przeciwnym razie wpis nie zostanie uznany za pasujący.

  • Szczególny przypadek: jeśli urządzenie nie wymieniono żadnych bibliotek macierz zgodności, wpis jest zawsze uważany za dopasowanie, ponieważ jest pusty jest podzbiorem dowolnego zbioru.

Przykład: udane 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, i {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 VNDK w wersji 27 jest już dostępny pliku manifestu, libjpeg.so nie jest obsługiwany przez platformę w tym zdjęcia. VNDK w wersji 26 jest ignorowane.

Jednakowe wersje pakietu SDK systemu

Tablica zgodności urządzeń deklaruje zestaw wymaganego systemowego pakietu SDK wersję w systemie compatibility-matrix.system-sdk.version. Jest pasuje tylko wtedy, gdy zbiór jest podzbiorem przesłanych wersji systemowych pakietów SDK zgodnie z zadeklarowaniem w manifest.system-sdk.version w pliku manifestu platformy.

  • Szczególny przypadek: jeśli na urządzeniu nie zostały wymienione żadne wersje systemowego pakietu SDK macierz zgodności, zawsze jest uznawana za dopasowanie, ponieważ jest pusta jest podzbiorem dowolnego zbioru.

Przykład: udane dopasowanie wersji pakietu systemowego pakietu SDK

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

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

Następnie platforma musi udostępniać systemowy pakiet SDK w wersji 26 i 27.

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

Przykład A pasuje.

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

Przykład B pasuje.

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

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