Zasady dopasowania

Dwie pary macierzy zgodności i manifestów mają być 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.

Weryfikacja odbywa się w czasie kompilacji, w OTA czas generacji pakietu aktualizacji, w czasie startu systemu, a w testach zgodności VTS.

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

Dopasowana wersja macierzy zgodności z ramami

Aby dopasować manifestu urządzenie z matrycą kompatybilności ramy, wersja Dostawa FCM określony przez manifest.target-level musi być dokładnie równa wersji podanej przez FCM compatibility-matrix.level . W przeciwnym razie nie ma dopasowania.

Gdy macierz Zgodność ramy jest proszony o libvintf , to ten mecz zawsze skuteczne, ponieważ libvintf otwiera manifestu urządzeniu pobiera wysyłka FCM wersja, i zwraca macierz kompatybilności ramy w które Shipping FCM Version (plus kilka opcjonalnych HAL z macierzy kompatybilności w wyższej FCM Wersje).

Mecze HAL

HAL-mecz reguła identyfikuje wersje hal elementów w pliku manifestu, które są uważane być wspierane przez właściciela odpowiedniego macierzy kompatybilności.

HIDL i natywne warstwy HAL

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

  • Wiele <hal> elementy są oceniane z pojedynczym i relacji.
  • Wiele <version> elementy w obrębie tego samego <hal> mają lub stosunku. Jeśli określono dwie lub więcej, tylko jedna z wersji musi zostać zaimplementowana. (Patrz przykład DRM poniżej).
  • Stwardnienie <instance> i <regex-instance> elementy w obrębie tego samego <hal> są oceniane z pojedynczym i relacji. (Patrz 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 zgodności, 2.5 jest skrótem 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.
Zatem urządzenie z HAL w wersji 2.10 w jej pliku manifestu pozostaje kompatybilny z ramami, które stwierdza 2.5-7 w jego macierzy kompatybilności.

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

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. Zasady mecz dla HAL AIDL są podobne do tych z HIDL i rodzimych Hals, oprócz tego, że są tam żadnych poważnych wersje, a tam jest dokładnie jedna wersja na przykład HAL ( 1 jeśli wersja jest nieokreślona).

  • Wiele <hal> elementy są oceniane z pojedynczym i relacji.
  • Stwardnienie <instance> i <regex-instance> elementy w obrębie tego samego <hal> są oceniane z pojedynczym i relacji. (Patrz na przykład wibrującego 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 zgodności, 5 jest skrótem 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) w przypadku żądania 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.
Zatem urządzenie z HAL w wersji 10 w jej pliku manifestu pozostaje kompatybilny z ramami, które stwierdza 5-7 w jego macierzy kompatybilności.

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

<kernel> sekcja matrycy kompatybilności ramy opisuje wymagania Ramowej za jądra Linuksa na urządzeniu. Ta informacja ma być porównywane z informacjami o jądrze, która zostanie zgłoszona przez VINTF obiektu urządzenia.

Dopasuj gałęzie jądra

Każdy sufiks gałęzi jądra (na przykład, 5.4- r ) jest odwzorowany na unikalny 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 egzekwować że urządzenie wyraźnie określa wersję jądra FCM w manifeście urządzeniu /vendor/etc/vintf/manifest.xml , jeśli jeden z poniższych warunków:

  • Wersja jądra FCM różni się od docelowej wersji FCM. Na przykład, wspomniane urządzenie posiada cel FCM wersji 4 i jego wersja FCM jądra 5 (jądro gałąź sufiks r ).
  • Wersja FCM ziaren jest większy niż lub równy 5 (jądra gałęzi przyrostkiem 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 cel FCM w wersji 4 (wydany w Androidzie 10), ale działa kernel z 4.19-r oddziału, manifest urządzenie należy podać następujące dane:

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

Kontrole PRZEDMIOT VINTF jądro przed wymagań dotyczących kompatybilności 4.19-r gałęzi jądra, który jest określony w FCM wersji 5. Wymagania te są zbudowane z kernel/configs/r/android-4.19 w drzewie źródłowym Androida.

Dopasuj wersje jądra

Macierz może zawierać wiele <kernel> sekcje, każda o innej version atrybutu stosując format:

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

Przedmiotem VINTF uważa tylko <kernel> sekcję z FCM z pasującymi wersję FCM o tej samej ${ver} oraz ${major_rev} jako jądra urządzenia (tj version="${ver}.${major_rev}.${matrix_minor_rev}") ; inne sekcje są ignorowane. Ponadto, zmiana drobne z jądra muszą mieć wartość z matrycy zgodności ( ${kernel_minor_rev} >= ${matrix_minor_rev} ). Jeśli nie <kernel> sekcja ta spełnia te wymagania, to nie pasuje.

Przykład: Wybierz wymagania dotyczące dopasowania

Rozważmy następującą hipotetyczną sytuację, w której FCMs w /system/etc/vintf zadeklarować następujące wymagania (znaczniki nagłówka i stopki są pominięte):

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

Docelowa wersja FCM, wersja 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 odpowiednika (nr 4.19-p gałęzi jądra)
3 (P) 4 (P) 4.19.42 4.19-q
4 (P) nieokreślony 4.4.107 Brak odpowiednika (bez 4.4-q gałęzi jądra)
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 odpowiednika (bez 5.4-q gałęzi jądra)
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żeli <kernel> sekcja pasuje, proces jest kontynuowany, próbując dopasować config elementy przed /proc/config.gz . Dla każdego elementu config w tabeli zgodności, wygląda się /proc/config.gz aby sprawdzić, czy konfiguracja jest obecna. Gdy element konfiguracyjny jest ustawiony na n w tabeli zgodności na dopasowanie <kernel> sekcja musi być nieobecny /proc/config.gz . Wreszcie, nie w tabeli zgodności poz config mogą lub nie mogą być obecne w /proc/config.gz .

Przykład: Dopasuj konfiguracje jądra

  • <value type="string">bar</value> mecze "bar" . Cytaty zostały pominięte w matrycy kompatybilności, ale występuje w /proc/config.gz .
  • <value type="int">4096</value> pasuje 4096 lub 0x1000 lub 0X1000 .
  • <value type="int">0x1000</value> pasuje 4096 lub 0x1000 lub 0X1000 .
  • <value type="int">0X1000</value> pasuje 4096 lub 0x1000 lub 0X1000 .
  • <value type="tristate">y</value> odpowiada y .
  • <value type="tristate">m</value> pasuje m .
  • <value type="tristate">n</value> oznacza, że element konfiguracyjny nie musi istnieć w /proc/config.gz .
  • <value type="range">1-0x3</value> odpowiada 1 , 2 lub 3 , lub równoważne szesnastkowym.

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. Oddział jądro jest określona w manifeście urządzenia w manifest.kernel.target-level , który domyślnie manifest.level jeśli pierwsze nie jest określona. 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() raportów:

  • 4.9.84 (nie pasuje do matrycy o ile nie znajduje się oddzielna sekcja jądro o <kernel version="4.9.x"> , gdzie x <= 84 )
  • 14/04/41 (nie pasuje do matrycy mniejszy niż version )
  • 4.14.42 (dopasowanie do matrycy)
  • 4.14.43 (dopasowanie do matrycy)
  • 4.1.22 (nie pasuje do matrycy o ile nie znajduje się oddzielna sekcja jądro o <kernel version="4.1.x"> w którym x <= 22 )

Po odpowiednim <kernel> sekcja jest wybrany, dla każdego <config> elementu o wartości innej niż n , oczekujemy Drugostronnie być obecne w /proc/config.gz ; dla każdego <config> elementu o wartości n , oczekujemy odpowiedni wpis nie być obecny w /proc/config.gz . Oczekujemy treść <value> , aby dokładnie dopasować tekst po znaku równości (w tym cudzysłowów), aż do znaku nowego wiersza lub # , a początkowe i końcowe spacje obcinane.

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ętą gamę wersji moll na każdej większej wersji. Wersja sepolityki 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 sepolicy jest wyższa lub równa wersji minimalnej dla zakresu. Wersja maksymalna ma charakter wyłącznie informacyjny.
  • <kernel-sepolicy-version> tzn policydb wersja. Musi być mniejsza niż security_policyvers() zgłaszanych 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 mecz. Na przykład:
    • Jeśli urządzenie zwraca 29, nie jest to dopasowanie.
    • Jeśli urządzenie zwraca 31, jest to dopasowanie.
  • Wersja Polityki SE musi mieć 25,0-∞ lub 26,0-∞. W przeciwnym razie to nie pasuje. (Dalej „ -3 ” po „ 26.0 ” ma charakter 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, patrz Versioning i kompatybilności . Wersja AVB ma następujące właściwości systemowe:

  • ro.boot.vbmeta.avb_version jest libavb wersja bootloadera
  • ro.boot.avb_version jest libavb wersja systemu operacyjnego 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 matrycy kompatybilności ramy;
    • 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 matrycy kompatybilności ramy.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Bootloader lub Android OS może zawierać dwie kopie libavb bibliotek, każdy z innej wersji dur na urządzeniach uaktualnienia i urządzeń nośnych. W tym przypadku, ten sam układ podpisany obraz może być wspólna, ale końcowe podpisane obrazy systemu są różne (z różnym avb.vbmeta-version ):

Rysunek 1. dopasowania wersja AVB ( /system jest P, wszystkie pozostałe ścianki są O).


Wersja mecze Rysunek 2. AVB (wszystkie partycje są P).

Przykład: Pomyślne dopasowanie wersji AVB

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

Dopasowanie wersji AVB podczas OTA

W przypadku urządzeń uruchamianych z systemem Android 9 lub starszym podczas aktualizacji do systemu Android 10 wymagania dotyczące 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ć wersję fałszywy AVB w pakiecie OTA ( compatibility.zip ) przekazać czek. Aby to zrobić:

  1. Wybierz następujące CL z drzewa źródłowego Androida 9:
  2. Definiowanie 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.

Zmiany te automatycznie umieszczać BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE jak compatibility-matrix.avb.vbmeta-version w następujących plików:

  • /system/compatibility_matrix.xml (które nie są wykorzystywane w Android 9) w urządzeniu
  • system_matrix.xml w compatibility.zip w pakiecie OTA

Zmiany te nie wpływają na inne matryce zgodnością ramowego, w tym /system/etc/vintf/compatibility_matrix.xml . Po OTA, nowa wartość w /system/etc/vintf/compatibility_matrix.xml służy do kontroli zgodności zamiast.

Dopasowana wersja VNDK

Macierz kompatybilności urządzenia deklaruje wymaganej wersji VNDK w compatibility-matrix.vendor-ndk.version . Jeśli macierz Zgodność Urządzenie nie posiada <vendor-ndk> tag, bez wymagania nałożone, a więc to zawsze uważany za mecz.

Jeśli macierz Zgodność Urządzenie posiada <vendor-ndk> tag, a <vendor-ndk> wpis z dopasowaną <version> jest wzrok ze zbioru VNDK migawek dostawcy, który jest przewidziany przez ramy w manifeście ramowej. 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 jest dopasowana, ponieważ VNDK wersja 27 jest w manifeście ramowej oraz {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. Chociaż VNDK wersja 27 jest w manifeście ramowej libjpeg.so nie jest obsługiwany przez ramy w tej migawce. Wersja 26 VNDK jest ignorowana.

Wersja systemowego SDK jest zgodna

Macierz kompatybilności urządzenia deklaruje zbiór wymaganej wersji SDK systemu w compatibility-matrix.system-sdk.version . Jest to mecz tylko wtedy, gdy zbiór jest podzbiorem świadczonych wersjach systemu SDK zadeklarowanymi w manifest.system-sdk.version w manifeście ramowej.

  • W szczególnym przypadku, jeśli żadna wersja System SDK nie jest wyliczana 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.