Te 2 pary matryc i plików manifestów zgodności należy uzgodnić, aby sprawdzić, czy framework i implementacja dostawcy mogą ze sobą współpracować. Weryfikacja przebiega pomyślnie, gdy matryca zgodności platformy i manifesztu urządzenia oraz matryca zgodności platformy i manifesztu urządzenia są zgodne.
Ta weryfikacja jest przeprowadzana w czasie kompilacji, generowania pakietu aktualizacji OTA, uruchamiania i testów zgodności VTS.
W następnych sekcjach znajdziesz szczegółowe informacje o regułach dopasowywania używanych przez różne komponenty.
Dopasowania wersji w ramach macierzy zgodności
Aby dopasować plik manifestu urządzenia do macierzy zgodności frameworka, wersja 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 jest używane do wysyłania żądania dotyczącego macierzy zgodności platformy, zawsze jest to zgodne z oczekiwaniami, ponieważ libvintf otwiera plik manifestu urządzenia, pobiera wersję FCM do wysyłania i zwraca macierz zgodności platformy w wersji FCM do wysyłania (oraz niektóre opcjonalne HAL-e z matrici zgodności w wyższych wersjach FCM).
Dopasowania HAL
Reguła dopasowania HAL identyfikuje wersje elementów hal w pliku manifestu, które są uznawane za obsługiwane przez właściciela odpowiedniej matrycy zgodności.
HIDL i natywne interfejsy HAL
Reguły dopasowywania do HIDL i domyślnych interfejsów HAL:
- Wiele elementów
<hal>jest ocenianych za pomocą pojedynczego związku ORAZ. - Elementy
<hal>mogą mieć atrybuty<hal optional="true">, aby oznaczyć je jako opcjonalne. Ostrzeżenie: ta wersjaoptionalnie jest już obsługiwana w Androidzie 15 - Wiele elementów
<version>w tym samym<hal>jest połączonych relacją LUB. Jeśli podasz co najmniej 2 wersje, musisz zaimplementować tylko jedną z nich. (zobacz przykład DRM poniżej). - Gdy wymagany jest element
<hal>, elementy<instance>i<regex-instance>w tym samym elemencie<hal>są oceniane za pomocą pojedynczej relacji AND. (patrz poniżej przykład dotyczący <ahref="#drm">DRM)</ahref="#drm">
Przykład: pomyślne dopasowanie HAL do modułu
W przypadku interfejsu HAL w wersji 2.5 reguła dopasowania wygląda tak:
| Matrix | Pasujący plik manifestu |
|---|---|
2.5 |
2,5–2,∞. W macierz zgodności 2.5 to skrót od 2.5-5. |
2.5-7 |
2,5–2,∞. Oznacza:
2.5-7. |
Przykład: pomyślne dopasowanie HAL do modułu DRM
W ramach tej tabeli zgodności podano te informacje o wersjach:
<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 tych opcji:
android.hardware.drm@1.x::IDrmFactory/default // where x >= 0 android.hardware.drm@1.x::IDrmFactory/specific // where x >= 0
android.hardware.drm@3.y::IDrmFactory/default // where y >= 1 android.hardware.drm@3.y::IDrmFactory/specific // where y >= 1
Muszą też być spełnione wszystkie te warunki:
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
Interfejsy AIDL HAL
Wszystkie wersje Androida nowsze niż 11 (z wyjątkiem Androida 11) obsługują wersje interfejsów AIDL HAL w VINTF.
Reguły dopasowywania w przypadku interfejsów HAL AIDL są podobne do reguł interfejsów HIDL i natywnych HAL, z tym że nie ma wersji głównych, a każdy instancja HAL ma dokładnie jedną wersję (1, jeśli wersja nie jest określona).
- Wiele elementów
<hal>jest ocenianych za pomocą pojedynczego związku ORAZ. - Elementy
<hal>mogą mieć atrybuty<hal optional="true">, aby oznaczyć je jako opcjonalne. Ostrzeżenie: ta wersjaoptionalnie jest już obsługiwana w Androidzie 15 - Gdy wymagany jest element
<hal>, elementy<instance>i<regex-instance>w tym samym elemencie<hal>są oceniane za pomocą pojedynczej relacji AND. (patrz poniżej przykład <ahref="#vibrator">wibratora).</ahref="#vibrator">
Przykład: pomyślne dopasowanie HAL do modułu
W przypadku HAL w wersji 5 reguła dopasowania wygląda tak:
| Matrix | Pasujący plik manifestu |
|---|---|
5 |
5–∞. W macierzy zgodności 5 to skrót od
5-5. |
5-7 |
5-∞. Oznacza:
5-7. |
Przykład: pomyślne dopasowanie HAL do wielu modułów
W ramach tej tabeli zgodności podano te informacje o wersjach interfejsów API:
<hal> <name>android.hardware.vibrator <version>1-2</version> <interface> <name>IVibrator</name> <instance>default</instance> <instance>specific</instance> </interface> </hal> <hal> <name>android.hardware.camera <version>5</version> <interface> <name>ICamera</name> <instance>default</instance> <regex-instance>[a-z]+/[0-9]+</regex-instance> </interface> </hal>
Dostawca musi wdrożyć wszystkie te przypadki:
android.hardware.vibrator.IVibrator/default // version >= 1
android.hardware.vibrator.IVibrator/specific // version >= 1
android.hardware.camera.ICamera/default // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
// with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
// e.g. legacy/0
Pasujące jądra
W sekcji <kernel> w ramach matrycy zgodności frameworku opisane są wymagania frameworku dotyczące jądra Linuksa na urządzeniu. Te informacje mają być dopasowywane do informacji dotyczących jądra, które są przekazywane przez obiekt VINTF urządzenia.
Dopasuj gałęzie jądra
Każdy przyrostek gałęzi jądra (np. 5.4-r) jest mapowany na unikalną wersję FCM jądra (np. 5). Mapowanie jest takie samo jak mapowanie liter wersji (np. R) i wersji FCM (np. 5).
Testy VTS wymuszają, aby urządzenie wyraźnie określało wersję jądra FCM w pliku manifestu urządzenia (/vendor/etc/vintf/manifest.xml), jeśli jest spełniony co najmniej jeden z tych warunków:
-
Wersja FCM jądra różni się od docelowej wersji FCM. Na przykład wspomniane urządzenie ma docelową wersję FCM 4, a wersja FCM jądra to 5 (suffiks gałęzi jądra:
r). -
Wersja FCM jądra jest większa lub równa 5 (suffiks gałęzi jądra:
r).
Testy VTS wymagają, aby w przypadku podania wersji FCM jądra była ona równa lub większa niż docelowa wersja FCM w pliku manifestu urządzenia.
Przykład: określenie gałęzi jądra
Jeśli urządzenie ma docelową wersję FCM 4 (wydana w Androidzie 10), ale działa z jądrem z gałęzi 4.19-r, w pliku manifestu urządzenia należy określić:
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
Obiekt VINTF sprawdza zgodność jądra z wymaganiami w gałęzi jądra 4.19-r, która jest określona w wersji 5 FCM. Te wymagania są tworzone na podstawie
kernel/configs/r/android-4.19 w drzewie źródłowym Androida.
Przykład: określenie gałęzi jądra dla GKI
Jeśli urządzenie korzysta z Generic Kernel Image (GKI), a ciąg znaków wersji jądra z /proc/version ma postać:
5.4.42-android12-0-00544-ged21d463f856
Następnie obiekt VINTF pobiera wersję Androida z wersji jądra i na jej podstawie określa wersję FCM jądra. W tym przykładzie android12 oznacza wersję FCM jądra 6 (wydana w Androidzie 12).
Szczegółowe informacje o analizowaniu ciągu wersji jądra znajdziesz w artykule Obsługa wersji GKI.
Dopasuj wersje jądra
Macierz może zawierać kilka sekcji <kernel>, z których każda ma inny atrybut version w formacie:
${ver}.${major_rev}.${kernel_minor_rev}
Obiekt VINTF uwzględnia tylko sekcję <kernel> z FCM z odpowiednią wersją FCM z tymi samymi wartościami ${ver} i ${major_rev} co jądro urządzenia (czyli
version="${ver}.${major_rev}.${matrix_minor_rev}"); inne sekcje są ignorowane. Dodatkowo drobna poprawka w jądrze musi być wartością z matrycy zgodności (${kernel_minor_rev} >=
${matrix_minor_rev}). Jeśli żadna sekcja <kernel> nie spełnia tych wymagań, oznacza to, że nie ma dopasowania.
Przykład: wybieranie wymagań dotyczących dopasowywania
Rozważmy hipotetyczny przypadek, w którym pliki FCM w /system/etc/vintf deklarują następujące wymagania (tagi 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 FCM rdzenia i wersja rdzenia razem określają wymagania dotyczące rdzenia z FCM:
| Docelowa wersja FCM | Wersja FCM jądra | Wersja jądra | Dopasuj do |
|---|---|---|---|
| 3 (K) | nie określono | 4.4.106 | Brak dopasowania (niezgodność wersji podrzędnej) |
| 3 (K) | nie określono | 4.4.107 | 4.4-p |
| 3 (K) | nie określono | 4.19.42 | 4.19-q (patrz uwaga poniżej) |
| 3 (K) | nie określono | 5.4.41 | 5.4-r (patrz uwaga 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 (Q) | 4.19.42 | 4.19-q |
| 4 (Q) | nie określono | 4.4.107 | Brak dopasowania (brak gałęzi jądra 4.4-q) |
| 4 (Q) | nie określono | 4.9.165 | 4.9-q |
| 4 (Q) | nie określono | 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) | nie określono | każdy | VTS nie działa (musisz określić wersję FCM jądra dla docelowej wersji FCM 5) |
| 5 (R) | 4 (Q) | każdy | VTS nie działa (wersja FCM jądra jest starsza niż docelowa wersja FCM) |
| 5 (R) | 5 (R) | 4.14.180 | 4.14-r |
Konfiguracje jądra dopasowania
Jeśli sekcja <kernel> pasuje, proces jest kontynuowany przez próbę dopasowania elementów config do elementów /proc/config.gz. W przypadku każdego elementu konfiguracji w tablicy zgodności sprawdza wartość /proc/config.gz, aby sprawdzić, czy konfiguracja jest obecna. Jeśli element konfiguracji ma wartość n w tablicy zgodności w sekcji dopasowania <kernel>, nie może występować w sekcji /proc/config.gz. Na koniec: element konfiguracji, który nie znajduje się w macierz zgodności, może się znajdować w elementach /proc/config.gz lub nie.
Przykład: dopasowywanie konfiguracji jądra
<value type="string">bar</value>pasuje do"bar". Cudzysłówy są pomijane w tabeli zgodności, ale występują w tagu/proc/config.gz.<value type="int">4096</value>pasuje do4096,0x1000lub0X1000.<value type="int">0x1000</value>pasuje do4096lub0x1000lub0X1000.<value type="int">0X1000</value>pasuje do4096,0x1000lub0X1000.<value type="tristate">y</value>pasuje doy.<value type="tristate">m</value>pasuje dom.<value type="tristate">n</value>oznacza, że element konfiguracji NIE może istnieć w elementach/proc/config.gz.<value type="range">1-0x3</value>odpowiada1,2lub3albo ich szesnastkowym odpowiednikom.
Przykład: pomyślne dopasowanie rdzenia
Matryca zgodności systemu z platformą FCM w wersji 1 zawiera te informacje o jądrze:
<kernel version="4.14.42"> <config> <key>CONFIG_TRI</key> <value type="tristate">y</value> </config> <config> <key>CONFIG_NOEXIST</key> <value type="tristate">n</value> </config> <config> <key>CONFIG_DEC</key> <value type="int">4096</value> </config> <config> <key>CONFIG_HEX</key> <value type="int">0XDEAD</value> </config> <config> <key>CONFIG_STR</key> <value type="string">str</value> </config> <config> <key>CONFIG_EMPTY</key> <value type="string"></value> </config> </kernel>
Najpierw dopasowywany jest element gałęzi jądra. Gałąź jądra jest określona w pliku manifestu urządzenia w sekcji manifest.kernel.target-level. Jeśli nie jest określona, domyślnie jest to manifest.level. Jeśli gałąź jądra w pliku manifestu urządzenia:
- jest równa 1, przechodzi do następnego kroku i sprawdza wersję jądra.
- jest 2, nie pasuje do macierzy. Obiekty VINTF odczytują wymagania dotyczące jądra z matriksa w wersji FCM 2.
Następnie dopasowuje wersję jądra. Jeśli urządzenie w grupie uname() zgłasza:
- 4.9.84 (nie pasuje do macierzy, chyba że istnieje osobna sekcja rdzenia z wartością
<kernel version="4.9.x">, gdziex <= 84) - 4.14.41 (brak dopasowania do macierzy, mniejsze niż
version) - 4.14.42 (dopasowywanie do macierzy)
- 4.14.43 (dopasowywanie do macierzy)
- 4.1.22 (brak dopasowania do macierzy, chyba że istnieje osobna sekcja jądra z wartością
<kernel version="4.1.x">, gdziex <= 22)
Po wybraniu odpowiedniej sekcji <kernel> oczekujemy, że w przypadku każdego elementu <config> o wartości innej niż n odpowiedni wpis będzie obecny w sekcji /proc/config.gz, a w przypadku każdego elementu <config> o wartości n odpowiedni wpis nie będzie obecny w sekcji /proc/config.gz. Zawartość <value> powinna dokładnie odpowiadać tekstowi po znaku równości (w tym cudzysłowach) aż do znaku nowego wiersza lub #, przy czym spacje na początku i na końcu powinny zostać obcięte.
Przykładem dopasowania jest następująca konfiguracja 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"
Przykładem nieudanego dopasowania jest ta konfiguracja jądra:
CONFIG_TRI="y" # mismatch: quotes CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists CONFIG_HEX=0x0 # mismatch; value doesn't match CONFIG_DEC="" # mismatch; type mismatch (expect int) CONFIG_EMPTY=1 # mismatch; expects "" # mismatch: CONFIG_STR is missing
Dopasowania do zasad SE
Zasady dotyczące wyszukiwania obrazów wymagają tych dopasowań:
<sepolicy-version>definiuje zamknięty zakres wersji podrzędnych 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ć zgodna z ramami. Zasady dopasowania są podobne do wersji HAL; dopasowanie występuje, jeśli wersja sepolicy jest większa lub równa wersji minimalnej dla zakresu. Wersja maksymalna jest czysto informacyjna.<kernel-sepolicy-version>np. wersja policydb. Musi być mniejsza niżsecurity_policyvers()zgłoszona przez urządzenie.
Przykład: zgodność z zasadami SE
W ramach tej tabeli zgodności podano te informacje o zasadach bezpieczeństwa:
<sepolicy>
<kernel-sepolicy-version>30</kernel-sepolicy-version>
<sepolicy-version>25.0</sepolicy-version>
<sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>Na urządzeniu:
- Wartość zwracana przez funkcję
security_policyvers()musi być większa lub równa 30. W przeciwnym razie nie będzie to pasować. Na przykład:- Jeśli urządzenie zwróci wartość 29, nie będzie pasować.
- Jeśli urządzenie zwróci wartość 31, będzie to oznaczać dopasowanie.
- Wersja zasad SE musi być 25.0-∞ lub 26.0-∞. W przeciwnym razie nie będzie pasować. (Wskazówka „
-3” po wskazówce „26.0” ma charakter wyłącznie informacyjny).
Dopasowania wersji AVB
Wersja AVB zawiera wersję GŁÓWNA i POMOCNICZA w formacie GŁÓWNA.POMOCNICZA (np. 1.0, 2.1). Więcej informacji znajdziesz w artykule Wersje i zgodność. Wersja AVB ma te właściwości systemu:
ro.boot.vbmeta.avb_versionto wersjalibavbprogramu rozruchowegoro.boot.avb_versionto wersjalibavbw systemie operacyjnym Android (init/fs_mgr)
Właściwość systemowa pojawia się tylko wtedy, gdy odpowiednia biblioteka libavb została użyta do zweryfikowania metadanych AVB (i zwraca OK). Nie ma go, jeśli wystąpił błąd weryfikacji (lub nie przeprowadzono żadnej weryfikacji).
Dopasowanie zgodności porównuje te elementy:
- sysprop
ro.boot.vbmeta.avb_versionzavb.vbmeta-versionz ramki zgodności;ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJORro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
- sysprop
ro.boot.avb_versionzavb.vbmeta-versionz macierzy zgodności systemu.ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJORro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR
Bootloader lub system operacyjny Android może zawierać 2 kopie bibliotek libavb, z których każda ma inną wersję GŁÓWNĄ dla urządzeń z aktualizacją i urządzeń z wersją wstępną. W takim przypadku można udostępnić ten sam niepodpisany obraz systemu, ale końcowe podpisane obrazy systemu są różne (z różnymi avb.vbmeta-version):
Rysunek 1. Dopasowanie wersji AVB (/system to P, wszystkie inne partycje to O).
Rysunek 2. Dopasowanie wersji AVB (wszystkie partycje są P).
Przykład: pomyślne dopasowanie wersji AVB
W ramach tej matrycy zgodności podano te informacje o AVB:
<avb>
<vbmeta-version>2.1</vbmeta-version>
</avb>Na urządzeniu:
ro.boot.avb_version == 1.0 && ro.boot.vbmeta.avb_version == 2.1 mismatch
ro.boot.avb_version == 2.1 && ro.boot.vbmeta.avb_version == 3.0 mismatch
ro.boot.avb_version == 2.1 && ro.boot.vbmeta.avb_version == 2.3 match
ro.boot.avb_version == 2.3 && ro.boot.vbmeta.avb_version == 2.1 match
Dopasowywanie wersji AVB podczas aktualizacji OTA
W przypadku urządzeń z Androidem 9 lub starszym, które są aktualizowane do Androida 10, wymagania dotyczące wersji AVB w matrycy zgodności frameworku są dopasowywane do bieżącej wersji AVB na urządzeniu. Jeśli podczas aktualizacji OTA wersja AVB została zaktualizowana (np. z 0.0 na 1.0), sprawdzenie zgodności w VINTF podczas aktualizacji OTA nie odzwierciedla zgodności po aktualizacji.
Aby rozwiązać ten problem, producent OEM może umieścić w pakiecie OTA (compatibility.zip) fałszywą wersję AVB, aby przejść weryfikację. Aby to zrobić:
- Dodaj do drzewa źródłowego Androida 9 te zmiany:
- Określ
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDEdla urządzenia. Jego wartość powinna być równa wersji AVB przed aktualizacją OTA, czyli wersji AVB urządzenia w momencie jego wprowadzenia na rynek. - Utwórz ponownie pakiet OTA.
Te zmiany automatycznie umieszczają BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE jako compatibility-matrix.avb.vbmeta-version w tych plikach:
/system/compatibility_matrix.xml(nie jest używany w Androidzie 9) na urządzeniu.system_matrix.xmlwcompatibility.zipw pakiecie OTA
Te zmiany nie mają wpływu na inne matrycy zgodności frameworków, w tym /system/etc/vintf/compatibility_matrix.xml. Po aktualizacji OTA do sprawdzania zgodności używana jest nowa wartość w polu /system/etc/vintf/compatibility_matrix.xml.
Dopasowania wersji VNDK
W tablicy zgodności urządzeń w polu compatibility-matrix.vendor-ndk.version podana jest wymagana wersja VNDK. Jeśli w macierz zgodności urządzenia nie ma tagu <vendor-ndk>, nie nakłada się żadnych wymagań, więc zawsze jest to zgodność.
Jeśli w macierz zgodności urządzeń występuje tag <vendor-ndk>, z zestawu zrzutów dostawcy VNDK, który jest udostępniany przez framework w ramach jego manifestu, pobierana jest pozycja <vendor-ndk> z odpowiadającym <version>. Jeśli taki wpis nie istnieje, nie ma dopasowania.
Jeśli taki wpis istnieje, zestaw bibliotek wymienionych w macierz zgodności urządzenia musi być podzbiorem zestawu bibliotek określonych w pliku manifestu frameworka. W przeciwnym razie wpis nie jest uznawany za pasujący.
- W szczególnym przypadku, gdy w macierz zgodności urządzenia nie ma wymienionych żadnych bibliotek, wpis jest zawsze uznawany za dopasowanie, ponieważ pusty zbiór jest podzbiorem dowolnego zbioru.
Przykład: pomyślne dopasowanie wersji VNDK
Jeśli w macierz zgodności urządzeń podano następujący wymóg dotyczący VNDK:
<!-- Example Device Compatibility Matrix --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk>
W pliku manifestu 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 VNDK 27 znajduje się w pliku manifestu frameworku, 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 jest zgodny. Mimo że w pliku manifestu platformy VNDK znajduje się wersja 27, platforma w tym zrzucie nie obsługuje funkcji libjpeg.so. Wersja VNDK 26 jest ignorowana.
Dopasowanie wersji pakietu SDK systemu
W macierz zgodności urządzeń w elementach compatibility-matrix.system-sdk.version podano wymaganą wersję System SDK. Dopasowanie występuje tylko wtedy, gdy zbiór jest podzbiorem podanych wersji pakietu System SDK zgodnie z deklaracją w manifest.system-sdk.version w pliku manifestu frameworku.
- W szczególnym przypadku, gdy w macierzy zgodności urządzeń nie ma wymienionych wersji pakietu SDK systemu, zawsze jest to uznawane za dopasowanie, ponieważ pusty zbiór jest podzbiorem dowolnego zbioru.
Przykład: pomyślne dopasowanie wersji pakietu System SDK
Jeśli w ramach matrycy zgodności urządzeń podano następujący wymóg dotyczący System SDK:
<!-- Example Device Compatibility Matrix --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
Następnie framework musi udostępniać pakiet SDK systemu w wersji 26 i 27.
<!-- Framework Manifest Example A --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
Przykład A jest zgodny.
<!-- 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ż nie podano wersji pakietu System SDK 27.