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>
. (ZobaczPrzykł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:
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 >= 0LUB
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>
. (Zobaczprzykł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-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 do4096
lub0x1000
lub0X1000
. -
<value type="int">0x1000</value>
odpowiada4096
,0x1000
lub0X1000
. -
<value type="int">0X1000</value>
odpowiada wartości4096
,0x1000
lub0X1000
. -
<value type="tristate">y</value>
odpowiaday
. -
<value type="tristate">m</value>
odpowiadam
. -
<value type="tristate">n</value>
oznacza, że element konfiguracji NIE może istnieć w/proc/config.gz
. -
<value type="range">1-0x3</value>
dopasowuje1
,2
lub3
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">
, gdziex <= 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">
gdziex <= 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 wersjalibavb
w bootloaderze -
ro.boot.avb_version
to wersjalibavb
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
zavb.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
zavb.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
):
![](https://source.android.google.cn/docs/core/architecture/images/treble_vintf_avb_o_p.png?authuser=7&hl=pl)
/system
to P, wszystkie pozostałe partycje to O).![](https://source.android.google.cn/docs/core/architecture/images/treble_vintf_avb_p.png?authuser=7&hl=pl)
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ć:
- Wybierz następujące CL do drzewa źródłowego Androida 9:
- 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. - 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
wcompatibility.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 sprawdzany 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.