Zasady dopasowania

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Dwie pary macierzy zgodności i manifestów 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 struktury i manifestem urządzenia, jak również między manifestem struktury i macierzą zgodności urządzenia.

Ta weryfikacja jest przeprowadzana w czasie kompilacji, w czasie generowania pakietu aktualizacji OTA , w czasie rozruchu oraz w testach zgodności VTS.

Poniższe sekcje szczegółowo opisują reguły dopasowywania używane przez różne komponenty.

Zgodna wersja macierzy zgodności z platformami

Aby dopasować manifest urządzenia do macierzy zgodności struktury, wersja wysyłki 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 zażądała macierzy kompatybilności frameworka, to dopasowanie jest zawsze udane, ponieważ libvintf otwiera manifest urządzenia, pobiera wersję Shipping FCM i zwraca macierz kompatybilności frameworka dla tej wersji Shipping FCM (plus kilka opcjonalnych HAL z macierzy kompatybilności w wyższym FCM Wersje).

Mecze HAL

Reguła zgodności 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 warstwy HAL

Zasady dopasowania dla HIDL i macierzystych warstw 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 nie wymagane.
  • Wiele elementów <version> w tym samym <hal> ma relację OR . Jeśli określono dwie lub więcej, tylko jedna z wersji musi zostać zaimplementowana. (Patrz przykład DRM poniżej.)
  • Wiele elementów <instance> i <regex-instance> w ramach tego samego elementu <hal> jest ocenianych za pomocą pojedynczej relacji AND , gdy wymagana jest wartość <hal> . (Zobacz Przykład DRM poniżej.)

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

W przypadku HAL w wersji 2.5 zasady dopasowania są następujące:

Matryca Dopasowany manifest
2.5 2,5-2.∞. W macierzy kompatybilności 2.5 to skrót od 2.5-5 .
2.5-7 2,5-2.∞. Wskazuje następujące informacje:
  • 2.5 to minimalna wymagana wersja, co oznacza, że ​​manifest zawierający HAL 2.0-2.4 nie jest kompatybilny.
  • 2.7 to maksymalna wersja, jakiej można zażądać, co oznacza, że ​​właściciel macierzy kompatybilności (szkielet lub urządzenie) nie będzie żądać wersji powyżej 2.7. Właściciel pasującego manifestu może nadal wyświetlać wersję 2.10 (jako przykład), gdy zażądano wersji 2.7. Właściciel macierzy zgodności wie tylko, że żądana usługa jest zgodna z API w wersji 2.7.
  • -7 ma charakter wyłącznie informacyjny i nie wpływa na proces aktualizacji OTA.
W ten sposób urządzenie z HAL w wersji 2.10 w swoim pliku manifestu pozostaje kompatybilne z frameworkiem, który w macierzy kompatybilności podaje 2.5-7 .

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

Macierz zgodności struktury zawiera następujące informacje o wersji dla 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ć JEDNO z następujących wystąpień; zarówno

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

AND musi również zaimplementować 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 nowsze niż Android 11 (z wyjątkiem Androida 11) obsługują wersje AIDL HAL w VinTF. Reguły dopasowania dla AIDL HAL są podobne do reguł HIDL i natywnych HAL, z wyjątkiem tego, że nie ma wersji głównych i istnieje dokładnie jedna wersja na wystąpienie warstwy HAL ( 1 , jeśli wersja jest nieokreślona).

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

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

W przypadku HAL w wersji 5 zasady dopasowania są następujące:

Matryca Dopasowany manifest
5 5-∞. W macierzy kompatybilności 5 to skrót od 5-5 .
5-7 5-∞. Wskazuje następujące informacje:
  • 5 to minimalna wymagana wersja, co oznacza, że ​​manifest zawierający warstwę HAL 1-4 nie jest zgodny.
  • 7 to maksymalna wersja, której można zażądać, co oznacza, że ​​właściciel macierzy kompatybilności (struktury lub urządzenia) nie będzie żądać wersji powyżej 7. Właściciel pasującego manifestu może nadal obsługiwać wersję 10 (jako przykład), gdy wymagana jest 7 . Właściciel macierzy zgodności wie tylko, że żądana usługa jest zgodna z API w wersji 7.
  • -7 ma charakter wyłącznie informacyjny i nie wpływa na proces aktualizacji OTA.
W ten sposób urządzenie z HAL w wersji 10 w swoim pliku manifestu pozostaje kompatybilne z frameworkiem, który w macierzy kompatybilności podaje 5-7 .

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

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

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

Dopasowania jądra

Sekcja <kernel> macierzy kompatybilności frameworka opisuje wymagania frameworka dla jądra Linux na urządzeniu. Te informacje mają być dopasowane do informacji o jądrze, które są zgłaszane 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 do unikalnej wersji FCM jądra (na przykład 5). Mapowanie jest takie samo jak mapowanie między wersjami wersji (na przykład R) i 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 wspomniane urządzenie ma docelową wersję FCM 4, a jego wersja FCM jądra to 5 (sufiks 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ę FCM jądra, wersja FCM jądra 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 FCM w wersji 5. Te wymagania są kompilowane na podstawie kernel/configs/r/android-4.19 w drzewie źródłowym systemu Android.

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

Jeśli urządzenie używa Generic Kernel Image (GKI), a ciąg wydania jądra z /proc/version jest następujący:

5.4.42-android12-0-00544-ged21d463f856

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

Aby uzyskać szczegółowe informacje na temat przetwarzania łańcucha wydania jądra, zobacz Wersjonowanie GKI .

Dopasuj wersje jądra

Macierz może zawierać wiele sekcji <kernel> , z których każda ma inny atrybut version przy użyciu formatu:

${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 z 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ń, oznacza to niedopasowanie.

Przykład: Wybierz wymagania dotyczące dopasowania

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

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

Wersja docelowa FCM Wersja jądra FCM Wersja jądra Pasuje do
3 (P) nieokreślony 4.4.106 Brak dopasowania (niezgodność wersji podrzędnej)
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 (P) 4.19.42 4.19-q
4 (P) nieokreślony 4.4.107 Brak dopasowania (brak gałęzi jądra 4.4-q )
4 (P) nieokreślony 4.9.165 4.9-q
4 (P) nieokreślony 5.4.41 5.4-r (patrz uwaga poniżej)
4 (P) 4 (P) 4.9.165 4.9-q
4 (P) 4 (P) 5.4.41 Brak dopasowania (brak gałęzi jądra 5.4-q )
4 (P) 5 (R) 4.14.105 4.14-r
4 (P) 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 (P) każdy Błąd VTS (wersja jądra FCM < 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 kompatybilności wyszukuje /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 . Na koniec, element konfiguracyjny, którego nie ma w macierzy kompatybilności, może, ale nie musi być obecny w /proc/config.gz .

Przykład: Dopasuj konfiguracje jądra

  • <value type="string">bar</value> odpowiada wartości "bar" . Cytaty są pomijane w macierzy zgodności, ale znajdują się w /proc/config.gz .
  • <value type="int">4096</value> odpowiada 4096 0x1000 lub 0X1000 .
  • <value type="int">0x1000</value> odpowiada 4096 0x1000 lub 0X1000 .
  • <value type="int">0X1000</value> odpowiada 4096 0x1000 lub 0X1000 .
  • <value type="tristate">y</value> odpowiada y .
  • <value type="tristate">m</value> pasuje do m .
  • <value type="tristate">n</value> oznacza, że ​​element konfiguracji NIE MOŻE istnieć w /proc/config.gz .
  • <value type="range">1-0x3</value> odpowiada wartości 1 , 2 lub 3 albo odpowiednikowi szesnastkowemu.

Przykład: Pomyślne dopasowanie jądra

Macierz zgodności frameworka z FCM w wersji 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>

Gałąź jądra jest dopasowywana jako pierwsza. Gałąź jądra jest określona w manifeście urządzenia w manifest.kernel.target-level , który domyślnie przyjmuje wartość manifest.level , jeśli nie określono tego pierwszego. 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. 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 macierzy, chyba że istnieje osobna sekcja jądra z <kernel version="4.9.x"> , gdzie x <= 84 )
  • 4.14.41 (brak dopasowania do matrycy, mniejsza niż version )
  • 4.14.42 (dopasowanie do matrycy)
  • 4.14.43 (dopasowanie do matrycy)
  • 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 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 pasować do tekstu po znaku równości (w tym cudzysłowów), aż do znaku nowej linii lub # , z obciętymi początkowymi i końcowymi białymi znakami.

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

Dopasowanie zasad SE

Polityka SE wymaga następujących dopasowań:

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

Przykład: Udane dopasowanie zasad SE

Macierz zgodności ram zawiera następujące informacje o sepolityce:

<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 security_policyvers() musi być większa lub równa 30. W przeciwnym razie nie jest to dopasowanie. Na przykład:
    • Jeśli urządzenie zwraca 29, nie jest to dopasowanie.
    • Jeśli urządzenie zwraca 31, jest zgodne.
  • Wersja Polityki SE musi mieć 25,0-∞ lub 26,0-∞. W przeciwnym razie to nie pasuje. (" -3 " po " 26.0 " ma charakter czysto informacyjny).

Dopasowana wersja AVB

Wersja AVB zawiera wersję GŁÓWNĄ i PODRĘCZNĄ, w formacie GŁÓWNA.PODROŻNA (np. 1.0, 2.1). Aby uzyskać szczegółowe informacje, zobacz Wersjonowanie i zgodność . 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 w systemie operacyjnym Android ( init/fs_mgr )

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

Zgodność 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

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

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


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

Przykład: Pomyślne dopasowanie wersji AVB

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

Dopasowanie wersji AVB podczas OTA

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

Aby złagodzić ten 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 z 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 (nieużywany w Androidzie 9) na urządzeniu
  • system_matrix.xml w compatibility.zip w pakiecie OTA

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

Dopasowana wersja VNDK

Macierz zgodności urządzeń deklaruje wymaganą wersję VNDK w compatibility-matrix.vendor-ndk.version . Jeśli macierz zgodności urządzeń nie zawiera <vendor-ndk> , nie są narzucane żadne wymagania i dlatego zawsze jest uważana za dopasowanie.

Jeśli macierz zgodności urządzeń ma znacznik <vendor-ndk> <vendor-ndk> , wpis <vendor-ndk> z pasującą <version> jest wyszukiwany z zestawu migawek dostawcy VNDK, który jest udostępniany przez platformę w manifeście platformy. Jeśli taki wpis nie istnieje, nie ma dopasowania.

Jeśli taki wpis istnieje, zestaw bibliotek wyliczonych w macierzy zgodności urządzeń musi być podzbiorem zestawu bibliotek określonego w manifeście struktury; w przeciwnym razie wpis nie jest uważany za dopasowanie.

  • W szczególnym przypadku, jeśli żadne biblioteki nie są wyliczone w macierzy zgodności urządzeń, wpis jest zawsze uważany za dopasowanie, ponieważ pusty zestaw jest podzbiorem dowolnego zestawu.

Przykład: Pomyślne dopasowanie wersji VNDK

Jeśli macierz zgodności urządzeń zawiera 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 frameworku 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 27 VNDK znajduje się w manifeście frameworka, 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 platformy, libjpeg.so nie jest obsługiwana przez platformę w tej migawce. Wersja 26 VNDK jest ignorowana.

Wersja systemowego SDK jest zgodna

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

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

Przykład: Pomyślna zgodność wersji systemowego SDK

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 zapewnić system SDK w wersji 26 i 27, aby pasowały.

<!-- 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 pasuje, ponieważ system SDK w wersji 27 nie jest dostarczany.