Obiekt VINTF zbiera dane z urządzenia Pliki manifestu i Manifest platformy (XML). Obie opcje pliki manifestu mają wspólny format, ale nie wszystkie elementy mają zastosowanie do obu (aby dowiedzieć się więcej, (patrz Schemat pliku manifestu).
Plik manifestu urządzenia
Plik manifestu urządzenia (dostarczony przez urządzenie) zawiera plik manifestu dostawcy. i plik manifestu ODM.
- Plik manifestu dostawcy określa interfejsy HAL, wersje zasad SELinux itp. wspólne dla SoC. it
zalecamy umieszczenie go w drzewie źródłowym Androida w:
device/VENDOR/DEVICE/manifest.xml
, ale kilka fragmentów Szczegółowe informacje znajdziesz w artykułach na temat fragmentów pliku manifestu oraz Generuj Czat we fragmentach. - Plik manifestu ODM zawiera listę HAL właściwych dla produktu w
Partycja ODM.
Obiekt VINTF wczytuje plik manifestu ODM w tej kolejności:
- Jeśli zdefiniowano
SKU
(gdzieSKU
to wartość argumentu usługaro.boot.product.hardware.sku
),/odm/etc/vintf/manifest_SKU.xml
/odm/etc/vintf/manifest.xml
- Jeśli zdefiniowano
SKU
,/odm/etc/manifest_SKU.xml
/odm/etc/manifest.xml
- Jeśli zdefiniowano
- Plik manifestu dostawcy zawiera listę HAL właściwych dla danego produktu w partycji dostawcy.
Obiekt VINTF wczytuje plik manifestu dostawcy w tej kolejności:
- Jeśli zdefiniowano
SKU
(gdzieSKU
to wartość argumentu usługaro.boot.product.vendor.sku
),/vendor/etc/vintf/manifest_SKU.xml
/vendor/etc/vintf/manifest.xml
- Jeśli zdefiniowano
- Obiekt VINTF wczytuje plik manifestu urządzenia w tej kolejności:
- Jeśli istnieje plik manifestu dostawcy, połącz te elementy:
- Plik manifestu dostawcy
- Opcjonalne fragmenty pliku manifestu dostawcy
- Opcjonalny plik manifestu ODM
- Opcjonalne fragmenty pliku manifestu ODM
- W przeciwnym razie, jeśli istnieje plik manifestu ODM, połącz go z opcjonalnym plikiem manifestu ODM. fragmenty pliku manifestu.
/vendor/manifest.xml
(starsza wersja, bez fragmentów)- Na koniec połącz fragmenty pliku manifestu z APEX dowolnego dostawcy.
Uwaga:
- Na starszych urządzeniach używane są starsze wersje pliku manifestu dostawcy i pliku manifestu ODM. Plik manifestu ODM może całkowicie zastąpić starszy plik manifestu dostawcy.
- Na urządzeniach z Androidem 9 plik manifestu ODM jest połączony. za pomocą pliku manifestu dostawcy.
- W przypadku łączenia listy plików manifestu pliki, które pojawiają się później na liście, mogą zastąpić
tagi w plikach manifestu pojawiających się wcześniej na liście, pod warunkiem że tagi w późniejszym
plik manifestu ma atrybut
override="true"
. Na przykład plik manifestu ODM może zastąp niektóre tagi<hal>
z pliku manifestu dostawcy. Zobacz dokumentację: atrybutoverride
poniżej.
- Jeśli istnieje plik manifestu dostawcy, połącz te elementy:
Dzięki tej konfiguracji wiele produktów na tej samej tablicy może być współużytkowanych obrazu dostawcy (który zawiera wspólne listy HAL), ale mają różne obrazy ODM (które (określanie numerów HAL dla poszczególnych produktów).
Oto przykładowy plik manifestu dostawcy.
<?xml version="1.0" encoding="UTF-8"?> <!-- Comments, Legal notices, etc. here --> <manifest version="2.0" type="device" target-level="1"> <hal> <name>android.hardware.camera</name> <transport>hwbinder</transport> <version>3.4</version> <interface> <name>ICameraProvider</name> <instance>legacy/0</instance> <instance>proprietary/0</instance> </interface> </hal> <hal> <name>android.hardware.nfc</name> <transport>hwbinder</transport> <version>1.0</version> <version>2.0</version> <interface> <name>INfc</name> <instance>nfc_nci</instance> </interface> </hal> <hal> <name>android.hardware.nfc</name> <transport>hwbinder</transport> <fqname>@2.0::INfc/default</fqname> </hal> <hal> <name>android.hardware.drm</name> <transport>hwbinder</transport> <version>1.0</version> <interface> <name>ICryptoFactory</name> <instance>default</instance> </interface> <interface> <name>IDrmFactory</name> <instance>default</instance> </interface> <fqname>@1.1::ICryptoFactory/clearkey</fqname> <fqname>@1.1::IDrmFactory/clearkey</fqname> </hal> <hal format="aidl"> <name>android.hardware.light</name> <version>1</version> <fqname>ILights/default</fqname> </hal> <hal format="aidl"> <name>android.hardware.power</name> <version>2</version> <interface> <name>IPower</name> <instance>default</instance> </interface> </hal> <hal format="native"> <name>EGL</name> <version>1.1</version> </hal> <hal format="native"> <name>GLES</name> <version>1.1</version> <version>2.0</version> <version>3.0</version> </hal> <sepolicy> <version>25.0</version> </sepolicy> </manifest>
Oto przykładowy plik manifestu ODM.
<?xml version="1.0" encoding="UTF-8"?> <!-- Comments, Legal notices, etc. here --> <manifest version="1.0" type="device"> <!-- camera 3.4 in vendor manifest is ignored --> <hal override="true"> <name>android.hardware.camera</name> <transport>hwbinder</transport> <version>3.5</version> <interface> <name>ICameraProvider</name> <instance>legacy/0</instance> </interface> </hal> <!-- NFC is declared to be disabled --> <hal override="true"> <name>android.hardware.nfc</name> <transport>hwbinder</transport> </hal> <hal> <name>android.hardware.power</name> <transport>hwbinder</transport> <version>1.1</version> <interface> <name>IPower</name> <instance>default</instance> </interface> </hal> </manifest>
Oto przykładowy plik manifestu urządzenia w pakiecie OTA.
<?xml version="1.0" encoding="UTF-8"?> <!-- Comments, Legal notices, etc. here --> <manifest version="1.0" type="device" target-level="1"> <!-- hals ommited --> <kernel version="4.4.176"> <config> <key>CONFIG_ANDROID</key> <value>y</value> </config> <config> <key>CONFIG_ARM64</key> <value>y</value> </config> <!-- other configs ommited --> </kernel> </manifest>
Więcej informacji znajdziesz w pliku manifestu urządzenia Programowanie.
Plik manifestu platformy
Plik manifestu platformy składa się z pliku manifestu systemu, pliku manifestu produktu i pliku manifestu plik manifestu system_ext.
-
Plik manifestu systemu (dostarczony przez Google) jest generowany ręcznie
mieszka w drzewie źródłowym Androida pod adresem
/system/libhidl/manifest.xml
- Plik manifestu produktu (dostarczony przez urządzenie) zawiera listę HAL obsługiwanych przez moduły zainstalowane w podziału produktu.
-
Plik manifestu system_ext (udostępniony przez urządzenie) zawiera następujące informacje:
- Listy HAL obsługiwane przez moduły zainstalowane na partycji system_ext;
- wersje VNDK;
- Wersja pakietu SDK systemu.
Podobnie jak w przypadku pliku manifestu urządzenia, możesz używać wielu plików z fragmentami. Więcej informacji: Fragmenty pliku manifestu.
Oto przykładowy plik manifestu platformy.
<?xml version="1.0" encoding="UTF-8"?> <!-- Comments, Legal notices, etc. here --> <manifest version="1.0" type="framework"> <hal> <name>android.hidl.allocator</name> <transport>hwbinder</transport> <version>1.0</version> <interface> <name>IAllocator</name> <instance>ashmem</instance> </interface> </hal> <hal> <name>android.hidl.memory</name> <transport arch="32+64">passthrough</transport> <version>1.0</version> <interface> <name>IMapper</name> <instance>ashmem</instance> </interface> </hal> <hal> <name>android.hidl.manager</name> <transport>hwbinder</transport> <version>1.0</version> <interface> <name>IServiceManager</name> <instance>default</instance> </interface> </hal> <hal> <name>android.frameworks.sensorservice</name> <transport>hwbinder</transport> <version>1.0</version> <interface> <name>ISensorManager</name> <instance>default</instance> </interface> </hal> <hal max-level="5"> <name>android.frameworks.schedulerservice</name> <transport>hwbinder</transport> <version>1.0</version> <interface> <name>ISchedulingPolicyService</name> <instance>default</instance> </interface> </hal> <vendor-ndk> <version>27</version> </vendor-ndk> <system-sdk> <version>27</version> </system-sdk> </manifest>
Fragmenty pliku manifestu
W Androidzie 10 i nowszych możesz powiązać plik manifestu z modułem HAL w systemie kompilacji. Dzięki temu łatwiej warunkowo umieść moduł HAL w systemie kompilacji.
Przykład
W pliku Android.bp
lub Android.mk
dodaj
vintf_fragments
do dowolnego modułu. Możesz na przykład zmienić
z implementacją kodu HAL
(my.package.foo@1.0-service-bar
).
... { ... vintf_fragments: ["manifest_foo.xml"], ... }
LOCAL_MODULE := ... LOCAL_VINTF_FRAGMENTS := manifest_foo.xml
W pliku manifest_foo.xml
utwórz plik manifestu dla:
w tym module. W momencie kompilacji ten plik manifestu jest dodawany do urządzenia. Dodaję
wpis w tym miejscu będzie taki sam jak dodanie wpisu w głównym pliku manifestu urządzenia.
Dzięki temu klienci mogą korzystać z interfejsu i VTS mogą określić, która zawartość HAL
na urządzeniach mobilnych. Wszystko, co znajduje się w zwykłym pliku manifestu
jak również ten plik manifestu.
Poniższy przykład implementuje
android.hardware.foo@1.0::IFoo/default
, która jest zainstalowana w
partycję vendor
lub odm
. Jeśli aplikacja jest zainstalowana w
Partycja system
, product
lub system_ext
, typ użycia
framework
zamiast
wpisz device
.
<manifest version="1.0" type="device"> <hal format="hidl"> <name>android.hardware.foo</name> <transport>hwbinder</transport> <fqname>@1.0::IFoo/default</fqname> </hal> </manifest>
Jeśli moduł HAL należy do APEX dostawcy,
spakować powiązane fragmenty VINTF w ramach tego samego punktu APEX za pomocą parametru prebuilt_etc
jako
omówiono we fragmentach VINTF.
Schemat pliku manifestu
W tej sekcji opisano znaczenie tych tagów XML. Niektóre „wymagane” tagi
może brakować w pliku źródłowym w drzewie źródłowym Androida i być zapisane przez
assemble_vintf
w momencie kompilacji. Wymagane tagi muszą znajdować się w odpowiednich plikach w
urządzenia.
?xml
- Opcjonalne. Podaje informacje tylko dla parsera XML.
manifest.version
- Wymagane. Metawersja tego pliku manifestu. Opisuje elementów oczekiwanych w pliku manifestu. Brak związku z wersją XML.
manifest.type
- Wymagane. Typ tego pliku manifestu. Ma wartość
device
dla atrybutu plik manifestu urządzenia iframework
dla platformy manifestu platformy . manifest.target-level
- Wymagane w przypadku pliku manifestu urządzenia. Określa tablicę zgodności platformy Wersja (FCM), która ma być zgodna z tym plikiem manifestu urządzenia. z naszymi usługami. Nazywa się to też wersją urządzenia w FCM.
manifest.hal
- Opcjonalnie, można powtórzyć. pojedynczy kod HAL (HIDL lub natywny, np. GL),
w zależności od atrybutu
format
. manifest.hal.format
- Opcjonalne. Możliwe wartości:
hidl
: wartości HAL HIDL. Jest to ustawienie domyślne.aidl
: HAL AIDL. Dotyczy tylko metawersji pliku manifestu w wersji 2.0 lub nowszej.native
: natywne HAL.
manifest.hal.max-level
- Opcjonalne. Dotyczy tylko plików manifestu platformy. Jeśli jest ustawiony, HAL o maksymalnym poziomie niższym niż docelowa wersja FCM w pliku manifestu platformy.
manifest.hal.override
- Opcjonalne. Możliwe wartości:
true
: zastąp inne elementy<hal>
wartością tę samą<name>
i wersję główną. Jeśli nie<version>
lub<fqname>
są w tym element<hal>
, a potem element<hal>
deklaruje, że ta platforma HAL jest wyłączona.false
: nie zastępuj innych elementów<hal>
z tą samą wersją<name>
i główną.
manifest.hal.name
- Wymagane. Pełna nazwa pakietu HAL. Wiele wpisów HAL może używać
o tej samej nazwie. Przykłady:
android.hardware.camera
(HIDL lub AIDL HAL)GLES
(natywna HAL, wymaga tylko nazwy)
manifest.hal.transport
- Wymagane, gdy
manifest.hal.format == "hidl"
. NIE może być w inny sposób. Określa, jaki rodzaj transportu jest używany, gdy interfejs z dotyczące tego pakietu jest wysyłane do menedżera usługi. Możliwe wartości:hwbinder
: tryb powiązaniapassthrough
: tryb przekazywania
.
- Opcjonalne, gdy
manifest.hal.format == "aidl"
. NIE może być w inny sposób. Określa, jaki transport jest używany podczas udostępniania interfejsu zdalnie. Wartość musi wynosić:inet
: gniazdo wejściowe
manifest.hal.transport.ip
imanifest.hal.transport.port
musi być użyty do dokładniejszego określenia informacji o połączeniu Inet. manifest.hal.transport.arch
- Wymagany w przypadku
passthrough
i nie może być dostępny w przypadkuhwbinder
Opisuje atmosferę usługi przekazywania dostępna. Możliwe wartości:32
: tryb 32-bitowy64
: tryb 64-bitowy32+64
: oba
manifest.hal.transport.ip
- Wymagany w przypadku
inet
, w przeciwnym razie NIE może występować. Opisuje adres IP z którego jest udostępniany interfejs zdalny. manifest.hal.transport.port
- Wymagany w przypadku
inet
, w przeciwnym razie NIE może występować. Opisuje port z który jest obsługiwany przez interfejs zdalny. manifest.hal.version
- Opcjonalnie, można powtórzyć. Wersja tagów
hal
w tabeli pliku manifestu.
W przypadku HIDL i natywnych HAL format toMAJOR.MINOR
Dla: Przykłady znajdziesz whardware/interfaces
,vendor/${VENDOR}/interfaces
,frameworks/hardware/interfaces
lubsystem/hardware/interfaces
HIDL i natywne HAL mogą używać wielu pól wersji, pod warunkiem że reprezentują różne wersje główne, z tylko 1 wersją podrzędną na każdą główną. wersji. Na przykład 3,1 i 3,2 nie mogą współistnieć, ale 1,0 i 3,4 mogą. Dotyczy to wszystkich elementówhal
o tej samej nazwie, chyba żeoverride="true"
Wartości<version>
nie są powiązane z adresem<fqname>
, ponieważ<fqname>
niesie własną wersję.
Zmienne HAL AIDL nie mogą zawierać<version>
na urządzeniach z uruchomionymi funkcjami Android 11 i starsze.<version>
musi być na urządzeniach z Androidem 12 lub nowszym. W każdym polu<version>
(package, interface, instance)
krotka. Jeśli go nie ma, użyj domyślnej wartości1
Wartość<version>
jest powiązana z wszystkie<fqname>
w tym samym<hal>
, ponieważ<fqname>
nie ma wersji. manifest.hal.interface
- Wymagane, można powtarzać bez duplikatów. Opisz interfejs w
pakiet, który ma nazwę instancji. Może być ich wiele
<interface>
elementów<hal>
; nazwy muszą się różnić od siebie. manifest.hal.interface.name
- Wymagane. Nazwa interfejsu.
manifest.hal.interface.instance
- Wymagane, można powtarzać. Nazwa instancji interfejsu. Może być ich więcej
instancji dla interfejsu, ale nie ma zduplikowanych instancji
<instance>
. manifest.hal.fqname
- Opcjonalnie, można powtórzyć. Alternatywny sposób określania instancji dla listy HAL
o nazwie
manifest.hal.name
.- W przypadku HAL HIDL format to
@MAJOR.MINOR::INTERFACE/INSTANCE
- W przypadku HAL AIDL format to
INTERFACE/INSTANCE
- W przypadku HAL HIDL format to
manifest.sepolicy
- Wymagane. Zawiera wszystkie wpisy związane z sepolicy.
manifest.sepolicy.version
- Wymagane w przypadku pliku manifestu urządzenia. Deklaruje wersję SELinux. Zawiera
format:
SDK_INT.PLAT_INT
. manifest.vendor-ndk
- Wymagane, można powtarzać. wymagane w przypadku pliku manifestu platformy. Nie może być obecne
w pliku manifestu urządzenia. Wiele wpisów
<vendor-ndk>
musi zawierać różne<version>
. Opisuje zestaw zrzutów VNDK manifest.vendor-ndk.version
- Wymagane. Jest to dodatnia liczba całkowita określająca wersję VNDK zdjęcia.
manifest.vendor-ndk.library
- Opcjonalnie, można powtarzać, bez duplikatów. Opisuje zbiór bibliotek VNDK
dostępnych w platformie dla tego zrzutu dostawcy VNDK. Wartość to
nazwa pliku biblioteki, np.
libjpeg.so
, łącznie z prefiksemlib
i sufiks.so
. Żadne komponenty ścieżki nie są jest dozwolona. manifest.system-sdk.version
- Opcjonalnie, można powtarzać, bez duplikatów. używane tylko przez platformę pliku manifestu. Opisuje zestaw wersji systemowych pakietów SDK udostępnianych przez platformę do w aplikacjach dostawców.
manifest.kernel
- Opcjonalne. Opisuje statyczne informacje o jądrze.
manifest.kernel.target-level
- Opcjonalne. Opisuje gałąź jądra. Domyślna wartość to
manifest.target-level
, jeśli nie ma tej wartości. Musi być większe niż lub równamanifest.target-level
. Zobacz reguły dopasowania jądra .