Zasady dopasowania

Obie pary macierzy i manifestów zgodności mają zostać uzgodnione w celu sprawdzenia, czy platforma i implementacja dostawcy mogą ze sobą współpracować. Ta weryfikacja kończy się pomyślnie po dopasowaniu między macierzą zgodności platformy a manifestem urządzenia, a także między manifestem struktury a macierzą zgodności urządzenia.

Ta weryfikacja odbywa się w czasie kompilacji, podczas generowania pakietu aktualizacji OTA , podczas uruchamiania systemu oraz podczas testów zgodności VTS.

W poniższych sekcjach szczegółowo opisano reguły dopasowywania używane przez różne komponenty.

Wersja macierzy zgodności platformy jest zgodna

Aby dopasować manifest urządzenia do macierzy zgodności platformy, wersja Shipping FCM określona przez manifest.target-level musi być dokładnie równa wersji FCM określonej przez compatibility-matrix.level . Inaczej nie ma dopasowania.

Kiedy za pomocą libvintf żądana jest macierz kompatybilności frameworka, to dopasowanie zawsze kończy się sukcesem, ponieważ libvintf otwiera manifest urządzenia, pobiera wersję Shipping FCM i zwraca macierz kompatybilności frameworka w tej wersji Shipping FCM (plus niektóre opcjonalne warstwy HAL z macierzy kompatybilności w wyższej wersji FCM) wersje).

mecze HAL-u

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

HIDL i natywne HAL

Zasady dopasowania dla HIDL i natywnych HAL są następujące.

  • Wiele elementów <hal> jest ocenianych za pomocą pojedynczej relacji AND .
  • Elementy <hal> mogą mieć <hal optional="true"> aby oznaczyć je jako niepotrzebne.
  • Wiele elementów <version> w tym samym <hal> ma relację LUB . Jeśli określono dwie lub więcej wersji, należy zaimplementować tylko jedną z wersji. (Zobacz przykład DRM poniżej.)
  • Wiele elementów <instance> i <regex-instance> w tym samym <hal> jest ocenianych za pomocą pojedynczej relacji AND , gdy wymagane jest <hal> . (Zobacz Przykład DRM poniżej.)

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

W przypadku HAL w wersji 2.5 reguła dopasowania jest następująca:

Matryca Dopasowany manifest
2.5 2,5-2,∞. W macierzy zgodności 2.5 jest skrótem od 2.5-5 .
2.5-7 2,5-2,∞. Wskazuje, co następuje:
  • Wersja 2.5 to minimalna wymagana wersja, co oznacza, że ​​manifest zawierający HAL 2.0–2.4 nie jest kompatybilny.
  • Wersja 2.7 to maksymalna wersja, o jaką można wystąpić, co oznacza, że ​​właściciel macierzy kompatybilności (frameworka lub urządzenia) nie będzie żądał wersji wyższych niż 2.7. Właściciel pasującego manifestu może nadal udostępniać wersję 2.10 (jako przykład), gdy żądana jest wersja 2.7. Właściciel macierzy zgodności wie tylko, że żądana usługa jest kompatybilna z wersją API 2.7.
  • -7 ma charakter wyłącznie informacyjny i nie wpływa na proces aktualizacji OTA.
Zatem urządzenie z warstwą HAL w wersji 2.10 w pliku manifestu pozostaje kompatybilne ze strukturą, która w swojej macierzy zgodności stwierdza 2.5-7 .

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

Matryca kompatybilności frameworka zawiera następujące 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 następujących instancji; 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 także implementować 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

AIDL HAL

Wszystkie wersje Androida późniejsze niż Android 11 (z wyjątkiem Androida 11) obsługują wersje AIDL HAL w VINTF. Reguły dopasowania dla warstw AIDL HAL są podobne do reguł HIDL i natywnych warstw HAL, z tą różnicą, że nie ma wersji głównych i istnieje dokładnie jedna wersja na każdą instancję HAL ( 1 , jeśli wersja nie jest określona).

  • Wiele elementów <hal> jest ocenianych za pomocą pojedynczej relacji AND .
  • Elementy <hal> mogą mieć <hal optional="true"> aby oznaczyć je jako niepotrzebne.
  • Wiele elementów <instance> i <regex-instance> w tym samym <hal> jest ocenianych za pomocą pojedynczej relacji AND , gdy wymagane jest <hal> . (Zobacz przykład wibratora poniżej.)

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

W przypadku warstwy HAL w wersji 5 reguła dopasowania jest następująca:

Matryca Dopasowany manifest
5 5-∞. W macierzy zgodności 5 jest skrótem od 5-5 .
5-7 5-∞. Wskazuje, co następuje:
  • 5 to minimalna wymagana wersja, co oznacza, że ​​manifest zapewniający HAL 1-4 nie jest kompatybilny.
  • 7 to maksymalna wersja, o jaką można poprosić, co oznacza, że ​​właściciel macierzy zgodności (framework lub urządzenie) nie będzie żądał wersji przekraczających 7. Właściciel pasującego manifestu może nadal udostępniać wersję 10 (jako przykład), gdy żądane jest 7 . Właściciel macierzy zgodności wie tylko, że żądana usługa jest kompatybilna z wersją API 7.
  • -7 ma charakter wyłącznie informacyjny i nie wpływa na proces aktualizacji OTA.
Zatem urządzenie z warstwą HAL w wersji 10 w pliku manifestu pozostaje kompatybilne ze strukturą, która w swojej macierzy zgodności stwierdza 5-7 .

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

Matryca zgodności platformy zawiera następujące informacje o wersji dla warstw HAL wibratorów i kamer:

<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

Dopasowania jądra

Sekcja <kernel> macierzy zgodności frameworka opisuje wymagania frameworka dotyczące jądra Linuksa na urządzeniu. Informacje te mają być porównywane z informacjami o jądrze zgłaszanymi przez obiekt VINTF urządzenia.

Dopasuj gałęzie jądra

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

Testy VTS wymuszają, aby urządzenie jawnie określało wersję jądra FCM w manifeście urządzenia /vendor/etc/vintf/manifest.xml , jeśli spełniony jest jeden z poniższych warunków:

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

Testy VTS wymuszają, że jeśli określono wersję jądra FCM, wersja jądra FCM jest większa lub równa docelowej wersji FCM w manifeście urządzenia.

Przykład: Określ gałąź jądra

Jeśli urządzenie ma docelową wersję FCM 4 (wydaną w systemie Android 10), ale uruchamia jądro z gałęzi 4.19-r , manifest urządzenia powinien zawierać następujące informacje:

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

Obiekt VINTF sprawdza zgodność jądra z wymaganiami gałęzi jądra 4.19-r , która jest określona w wersji 5 FCM. Wymagania te są zbudowane z kernel/configs/r/android-4.19 w drzewie źródeł Androida.

Przykład: Określ gałąź jądra dla GKI

Jeśli urządzenie korzysta z ogólnego obrazu jądra (GKI), a ciąg znaków zwalniających jądro z /proc/version jest następujący:

5.4.42-android12-0-00544-ged21d463f856

Następnie obiekt VINTF uzyskuje wersję Androida z wersji jądra i wykorzystuje ją do określenia wersji FCM jądra. W tym przykładzie android12 oznacza jądro FCM w wersji 6 (wydanej w systemie Android 12).

Aby uzyskać szczegółowe informacje na temat analizowania ciągu znaków wydania jądra, zobacz wersjonowanie GKI .

Dopasuj wersje jądra

Macierz może zawierać wiele sekcji <kernel> , każda z innym atrybutem version w formacie:

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

Obiekt VINTF uwzględnia tylko sekcję <kernel> z FCM z pasującą wersją FCM z tymi samymi ${ver} i ${major_rev} co jądro urządzenia (tj. version="${ver}.${major_rev}.${matrix_minor_rev}") ; inne sekcje są ignorowane. Dodatkowo drobna wersja jądra musi być wartością z macierzy kompatybilności ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Jeśli żadna sekcja <kernel> nie spełnia tych wymagań, jest to niezgodna.

Przykład: Wybierz wymagania dotyczące dopasowania

Rozważ następujący hipotetyczny przypadek, w którym FCM w /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 -->

Docelowa wersja FCM, wersja jądra FCM i wersja jądra razem wybierają wymagania jądra z FCM:

Docelowa wersja FCM Wersja jądra FCM Wersja jądra Pasuje do
3 (P) nieokreślony 4.4.106 Brak dopasowania (drobna niezgodność wersji)
3 (P) nieokreślony 4.4.107 4.4-p
3 (P) nieokreślony 4.19.42 4.19-q (patrz uwaga poniżej)
3 (P) nieokreślony 5.4.41 5.4-r (patrz uwaga poniżej)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Brak dopasowania (brak gałęzi jądra 4.19-p )
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) nieokreślony 4.4.107 Brak dopasowania (brak gałęzi jądra 4.4-q )
4 (Q) nieokreślony 4.9.165 4.9-q
4 (Q) nieokreślony 5.4.41 5.4-r (patrz uwaga poniżej)
4 (Q) 4 (Q) 4.9.165 4.9-q
4 (Q) 4 (Q) 5.4.41 Brak dopasowania (brak gałęzi jądra 5.4-q )
4 (Q) 5 (R) 4.14.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) nieokreślony każdy VTS nie działa (należy określić wersję jądra FCM dla docelowej wersji FCM 5)
5 (R) 4 (Q) każdy VTS nie działa (wersja FCM jądra < docelowa wersja FCM)
5 (R) 5 (R) 4.14.180 4.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 . Dla każdego elementu konfiguracji w macierzy zgodności sprawdza plik /proc/config.gz , aby sprawdzić, czy konfiguracja jest obecna. Gdy element konfiguracji jest ustawiony na n w macierzy zgodności dla pasującej sekcji <kernel> , musi być nieobecny w /proc/config.gz . Wreszcie element konfiguracji, którego nie ma w macierzy zgodności, może, ale nie musi, znajdować się w /proc/config.gz .

Przykład: Dopasuj konfiguracje jądra

  • <value type="string">bar</value> odpowiada "bar" . Cytaty są pomijane w macierzy zgodności, ale są obecne w /proc/config.gz .
  • <value type="int">4096</value> pasuje do 4096 lub 0x1000 lub 0X1000 .
  • <value type="int">0x1000</value> odpowiada 4096 , 0x1000 lub 0X1000 .
  • <value type="int">0X1000</value> odpowiada wartości 4096 , 0x1000 lub 0X1000 .
  • <value type="tristate">y</value> odpowiada y .
  • <value type="tristate">m</value> odpowiada m .
  • <value type="tristate">n</value> oznacza, że ​​element konfiguracji NIE może istnieć w /proc/config.gz .
  • <value type="range">1-0x3</value> dopasowuje 1 , 2 lub 3 lub odpowiednik w formacie szesnastkowym.

Przykład: pomyślne dopasowanie jądra

Macierz kompatybilności frameworka z wersją FCM 1 zawiera następujące 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 manifeście urządzenia w manifest.kernel.target-level , który domyślnie ma manifest.level , jeśli ten pierwszy nie został określony. Jeśli gałąź jądra w manifeście urządzenia:

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

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

  • 4.9.84 (brak dopasowania do matrix, chyba że istnieje osobna sekcja jądra z <kernel version="4.9.x"> , gdzie x <= 84 )
  • 4.14.41 (brak dopasowania do matrixa, mniejszy niż version )
  • 4.14.42 (dopasuj do matrixa)
  • 4.14.43 (dopasuj do matrixa)
  • 4.1.22 (brak dopasowania do matrix, 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 , oczekujemy, że odpowiedni wpis będzie obecny w /proc/config.gz ; dla każdego elementu <config> o wartości n oczekujemy, że odpowiedni wpis nie będzie obecny w /proc/config.gz . Oczekujemy, że zawartość <value> będzie dokładnie odpowiadać tekstowi znajdującemu się po znaku równości (łącznie z cudzysłowami), aż do znaku nowej linii lub # , z obciętymi białymi znakami na początku i końcu.

Następująca 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"

Następująca 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

Zasady SE są zgodne

Zasady SE wymagają następujących dopasowań:

  • <sepolicy-version> definiuje 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 kompatybilna ze strukturą. Zasady dopasowania są podobne do wersji HAL; jest to dopasowanie, jeśli wersja sepolicy jest wyższa lub równa wersji minimalnej dla zakresu. Wersja maksymalna ma charakter wyłącznie informacyjny.
  • <kernel-sepolicy-version> , czyli wersja policydb. Musi być mniejsza niż wartość security_policyvers() zgłoszona przez urządzenie.

Przykład: pomyślne dopasowanie zasad SE

Macierz kompatybilności frameworka zawiera następujące informacje 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ść zwrócona przez security_policyvers() musi być większa lub równa 30. W przeciwnym razie nie jest zgodna. Na przykład:
    • Jeśli urządzenie zwróci wartość 29, nie jest to dopasowanie.
    • Jeśli urządzenie zwróci 31, oznacza to dopasowanie.
  • Wersja zasad SE musi mieć wartość 25.0-∞ lub 26.0-∞. Inaczej to nie jest mecz. (Liczba „ -3 ” po „ 26.0 ” ma charakter wyłącznie informacyjny.)

Wersja AVB jest zgodna

Wersja AVB zawiera wersję MAJOR i wersję MINOR w formacie MAJOR.MINOR (np. 1.0, 2.1). Aby uzyskać szczegółowe informacje, zobacz Wersjonowanie i kompatybilność . Wersja AVB ma następujące właściwości systemowe:

  • ro.boot.vbmeta.avb_version to wersja libavb w bootloaderze
  • ro.boot.avb_version to wersja libavb dla systemu operacyjnego Android ( init/fs_mgr )

Właściwość systemowa pojawia się tylko wtedy, gdy odpowiednia libavb została użyta do sprawdzenia metadanych AVB (i zwraca OK). Nie ma go, jeśli wystąpił błąd weryfikacji (lub w ogóle nie nastąpiła weryfikacja).

Dopasowanie zgodności porównuje następujące elementy:

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

Program ładujący lub system operacyjny Android może zawierać dwie kopie bibliotek libavb , każda z inną wersją GŁÓWNĄ dla urządzeń do aktualizacji i urządzeń uruchamiających. W takim przypadku można udostępnić ten sam niepodpisany obraz systemu, ale ostateczne podpisane obrazy systemu są różne (z inną avb.vbmeta-version ):

Rysunek 1. Zgodna wersja AVB ( /system to P, wszystkie pozostałe partycje to O).


Rysunek 2. Zgodna wersja AVB (wszystkie partycje to P).

Przykład: pomyślne dopasowanie wersji AVB

Macierz kompatybilności frameworka zawiera następujące informacje 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 

Dopasowana wersja AVB podczas OTA

W przypadku urządzeń z systemem Android 9 lub starszym podczas aktualizacji do systemu Android 10 wymagania dotyczące wersji AVB w macierzy zgodności platformy są dopasowywane do bieżącej wersji AVB na urządzeniu. Jeśli wersja AVB została uaktualniona w trakcie OTA (na przykład z 0.0 do 1.0), sprawdzenie kompatybilności VINTF w OTA nie odzwierciedla kompatybilności po OTA.

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

  1. Wybierz następujące CL do drzewa źródłowego Androida 9:
  2. Zdefiniuj BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE dla urządzenia. Jego wartość powinna być równa wersji AVB przed OTA, czyli wersji AVB urządzenia w momencie jego uruchomienia.
  3. Odbuduj pakiet OTA.

Te zmiany automatycznie umieszczają BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE jako compatibility-matrix.avb.vbmeta-version w następujących plikach:

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

Zmiany te nie wpływają na inne macierze kompatybilności frameworka, w tym /system/etc/vintf/compatibility_matrix.xml . Po OTA do sprawdzania zgodności używana jest nowa wartość w /system/etc/vintf/compatibility_matrix.xml .

Wersja VNDK jest zgodna

Matryca kompatybilności urządzeń deklaruje wymaganą wersję VNDK w compatibility-matrix.vendor-ndk.version . Jeśli macierz kompatybilności urządzeń nie zawiera znacznika <vendor-ndk> , nie są narzucane żadne wymagania i dlatego zawsze uważa się, że pasuje.

Jeśli macierz kompatybilności urządzeń zawiera znacznik <vendor-ndk> , wpis <vendor-ndk> z pasującą <version> jest wyszukiwany w zestawie migawek dostawców VNDK dostarczonych przez platformę w manifeście platformy. Jeśli taki wpis nie istnieje, nie ma dopasowania.

Jeśli taki wpis istnieje, zestaw bibliotek wyliczony w macierzy kompatybilności urządzeń musi być podzbiorem zbioru bibliotek określonych w manifeście struktury; w przeciwnym razie wpis nie zostanie uznany za pasujący.

  • W szczególnym przypadku, jeśli w macierzy zgodności urządzeń nie są wyliczone żadne biblioteki, wpis jest zawsze uznawany za pasujący, ponieważ pusty zbiór jest podzbiorem dowolnego zbioru.

Przykład: pomyślne dopasowanie wersji VNDK

Jeżeli matryca kompatybilności urządzeń określa następujące wymagania 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 frameworka uwzględniany jest 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 27 VNDK znajduje się w manifeście 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 27 VNDK znajduje się w manifeście struktury, libjpeg.so nie jest obsługiwana przez platformę w tej migawce. Wersja VNDK 26 jest ignorowana.

Wersja systemu SDK jest zgodna

Macierz kompatybilności urządzeń deklaruje zestaw wymaganej wersji System SDK w compatibility-matrix.system-sdk.version . Dopasowanie występuje tylko wtedy, gdy zestaw jest podzbiorem dostarczonych wersji zestawu SDK systemu, zgodnie z deklaracją w pliku manifest.system-sdk.version w manifeście platformy.

  • W szczególnym przypadku, jeśli w macierzy zgodności urządzeń nie są wyliczone żadne wersje System SDK, zawsze uważa się to za dopasowanie, ponieważ pusty zestaw jest podzbiorem dowolnego zestawu.

Przykład: pomyślne dopasowanie wersji zestawu SDK systemu

Jeśli macierz zgodności urządzeń zawiera następujące wymagania dotyczące zestawu SDK systemu:

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

Następnie platforma musi zapewniać zgodność wersji 26 i 27 zestawu SDK systemu.

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

Przykład A to dopasowanie.

<!-- 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 jest zgodny, ponieważ nie dostarczono zestawu SDK systemu w wersji 27.