Obiekt VINTF agreguje dane z plików manifestu urządzenia i plików manifestu struktury (XML). Oba manifesty współużytkują format, chociaż nie wszystkie elementy dotyczą obu (aby uzyskać szczegółowe informacje na temat schematu, zobacz schemat pliku manifestu ).
Manifest urządzenia
Manifest urządzenia (dostarczany przez urządzenie) składa się z manifestu dostawcy i manifestu ODM.
- Manifest dostawcy określa warstwy HAL, wersje zasad SELinux itp. wspólne dla SoC. Zaleca się umieszczenie w drzewie źródłowym Androida w
device/ VENDOR / DEVICE /manifest.xml
, ale można użyć wielu plików fragmentów. Aby uzyskać szczegółowe informacje, zobacz Fragmenty manifestu i Generowanie wiadomości DM z fragmentów . - Manifest ODM zawiera listę warstw HAL specyficznych dla produktu w partycji ODM . Obiekt VinTF ładuje manifest ODM w następującej kolejności:
- Jeśli jednostka
SKU
jest zdefiniowana (gdzieSKU
jest wartością właściwościro.boot.product.hardware.sku
),/odm/etc/vintf/manifest_ SKU .xml
-
/odm/etc/vintf/manifest.xml
- Jeśli
SKU
jest zdefiniowana,/odm/etc/manifest_ SKU .xml
-
/odm/etc/manifest.xml
- Jeśli jednostka
- Manifest dostawcy zawiera listę warstw HAL specyficznych dla produktu w partycji dostawcy. Obiekt VinTF ładuje manifest dostawcy w następującej kolejności:
- Jeśli jednostka
SKU
jest zdefiniowana (gdzieSKU
jest wartością właściwościro.boot.product.vendor.sku
),/vendor/etc/vintf/manifest_ SKU .xml
-
/vendor/etc/vintf/manifest.xml
- Jeśli jednostka
- Obiekt VinTF ładuje manifest urządzenia w następującej kolejności:
- Jeśli manifest dostawcy istnieje, połącz następujące elementy:
- Manifest sprzedawcy
- Opcjonalne fragmenty manifestu dostawcy
- Opcjonalny manifest ODM
- Opcjonalne fragmenty manifestu ODM
- W przeciwnym razie, jeśli manifest ODM istnieje, połącz manifest ODM z opcjonalnymi fragmentami manifestu ODM.
-
/vendor/manifest.xml
(starszy, bez fragmentów)
Zwróć uwagę, że:
- Na starszych urządzeniach używany jest manifest starszego dostawcy i manifest ODM. Manifest ODM może całkowicie zastąpić manifest starszego dostawcy.
- Na urządzeniach z systemem Android 9 manifest ODM jest łączony z manifestem dostawcy.
- Podczas łączenia listy manifestów manifesty, które pojawiają się później na liście, mogą zastępować tagi w manifestach, które pojawiają się wcześniej na liście, pod warunkiem, że tagi w późniejszym manifeście mają atrybut
override="true"
. Na przykład manifest ODM może zastąpić niektóre<hal>
z manifestu dostawcy. Zapoznaj się z dokumentacją dotyczącąoverride
atrybutów poniżej.
- Jeśli manifest dostawcy istnieje, połącz następujące elementy:
Ta konfiguracja umożliwia wielu produktom z tą samą płytą główną współużytkowanie tego samego obrazu dostawcy (co zapewnia wspólne warstwy HAL), a jednocześnie posiada różne obrazy ODM (które określają warstwy HAL specyficzne dla produktu).
Oto przykładowy manifest 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ład 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 manifest 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>
Aby uzyskać więcej informacji, zobacz Tworzenie manifestu urządzenia .
Manifest ramowy
Plik manifestu struktury składa się z manifestu systemu, manifestu produktu i manifestu system_ext.
- Manifest systemowy (dostarczony przez Google) jest generowany ręcznie i znajduje się w drzewie źródłowym Androida pod adresem
/system/libhidl/manifest.xml
. - Manifest produktu (dostarczany przez urządzenie) zawiera listę warstw HAL obsługiwanych przez moduły zainstalowane na partycji produktu.
- Manifest system_ext (dostarczony przez urządzenie) zawiera następujące informacje:
- HAL obsługiwane przez moduły zainstalowane na partycji system_ext;
- wersje VNDK;
- Wersja systemowego SDK.
Podobnie jak w przypadku manifestu urządzenia, można użyć wielu plików fragmentów. Aby uzyskać szczegółowe informacje, zobacz Fragmenty manifestu .
Oto przykładowy manifest frameworka.
<?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 manifestu
W systemie Android 10 i nowszych możesz skojarzyć wpis manifestu z modułem HAL w systemie kompilacji. Ułatwia to warunkowe włączenie modułu HAL do systemu kompilacji.
Przykład
W pliku vintf_fragments
Android.mk
Android.bp
modułu. Na przykład możesz zmodyfikować moduł za pomocą swojej implementacji warstwy HAL ( my.package.foo@1.0-service-bar
).
... { ... vintf_fragments: ["manifest_foo.xml"], ... }
LOCAL_MODULE := ... LOCAL_VINTF_FRAGMENTS := manifest_foo.xml
W pliku o nazwie manifest_foo.xml
utwórz manifest dla tego modułu. W czasie kompilacji ten manifest jest dodawany do urządzenia. Dodanie wpisu w tym miejscu jest tym samym, co dodanie wpisu w głównym manifeście urządzenia. Dzięki temu klienci mogą korzystać z interfejsu, a VTS może zidentyfikować implementacje warstwy HAL znajdujące się na urządzeniu. Wszystko, co robi zwykły manifest, robi również ten manifest.
Poniższy przykład implementuje android.hardware.foo@1.0::IFoo/default
, który jest instalowany na partycji vendor
lub odm
. Jeśli jest zainstalowany na partycji system
, product
lub system_ext
, użyj type framework
zamiast type 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>
Schemat pliku manifestu
W tej sekcji opisano znaczenie tych znaczników XML. W pliku źródłowym w drzewie źródłowym systemu Android może brakować niektórych „wymaganych” tagów, które zostały zapisane przez assemble_vintf
w czasie kompilacji. Wymagane tagi muszą być obecne w odpowiednich plikach na urządzeniu.
-
?xml
- Opcjonalny. Tylko dostarcza informacje do parsera XML.
-
manifest.version
- Wymagany. Meta-wersja tego manifestu. Opisuje elementy oczekiwane w manifeście. Niezwiązany z wersją XML.
-
manifest.type
- Wymagany. Rodzaj tego manifestu. Ma wartość
device
dla pliku manifestu urządzenia iframework
dla pliku manifestu struktury. -
manifest.target-level
- Wymagane dla manifestu urządzenia. Określa wersję macierzy zgodności struktury (FCM), z którą ten manifest urządzenia ma być zgodny. Jest to również nazywane wysyłkową wersją FCM urządzenia.
-
manifest.hal
- Opcjonalnie, można powtórzyć. Pojedyncza warstwa HAL (HIDL lub natywna, taka jak GL), w zależności od atrybutu
format
. -
manifest.hal.format
- Opcjonalny. Wartość może być jedną z:
-
hidl
: HIDL HAL. To jest ustawienie domyślne. - pomoc : warstwy HAL AIDL
aidl
Obowiązuje tylko w manifestach meta w wersji 2.0 i nowszych. -
native
: natywne warstwy HAL.
-
-
manifest.hal.max-level
- Opcjonalny. Obowiązuje tylko w manifestach frameworka. Jeśli jest ustawiona, warstwy HAL z maksymalnym poziomem niższym niż docelowa wersja FCM w manifeście platformy są wyłączone.
-
manifest.hal.override
- Opcjonalny. Wartość może być jedną z:
-
true
: Zastąp inne elementy<hal>
tą samą<name>
i wersją główną. Jeśli w tym elemencie<hal>
nie ma<version>
ani<fqname>
, to element<hal>
deklaruje, że ta warstwa HAL jest wyłączona. -
false
: Nie zastępuj innych elementów<hal>
tą samą<name>
i wersją główną.
-
-
manifest.hal.name
- Wymagany. W pełni kwalifikowana nazwa pakietu warstwy HAL. Wiele wpisów HAL może używać tej samej nazwy. Przykłady:
-
android.hardware.camera
(HIDL lub AIDL HAL) -
GLES
(natywny HAL, wymaga tylko nazwy)
-
-
manifest.hal.transport
- Wymagane, gdy
manifest.hal.format == "hidl"
. W przeciwnym razie NIE może być obecny. Określa, jaki transport jest używany, gdy interfejs z tego pakietu jest wysyłany do menedżera usług. Wartość może być jedną z:-
hwbinder
: tryb spojony -
passthrough
: tryb przechodzenia
-
- Opcjonalne, gdy
manifest.hal.format == "aidl"
. W przeciwnym razie NIE może być obecny. Określa, jaki transport jest używany, gdy interfejs jest obsługiwany zdalnie. Wartość musi być:-
inet
: gniazdo inet
manifest.hal.transport.ip
imanifest.hal.transport.port
. -
-
manifest.hal.transport.arch
- Wymagane dla
hwbinder
passthrough
Opisuje bitowość świadczonej usługi przekazywania. Wartość może być jedną z:-
32
: tryb 32-bitowy -
64
: tryb 64-bitowy -
32+64
: Oba
-
-
manifest.hal.transport.ip
- Wymagane dla
inet
i NIE może być obecne w innym przypadku. Opisuje adres IP, z którego obsługiwany jest zdalny interfejs. -
manifest.hal.transport.port
- Wymagane dla
inet
i NIE może być obecne w innym przypadku. Opisuje port, z którego obsługiwany jest zdalny interfejs. -
manifest.hal.version
- Opcjonalnie, można powtórzyć. Wersja znaczników
hal
w manifeście.
W przypadku HIDL i macierzystych warstw HAL format toMAJOR . MINOR
. Przykłady można znaleźć whardware/interfaces
,vendor/${VENDOR}/interfaces
,frameworks/hardware/interfaces
lubsystem/hardware/interfaces
.
HIDL i rodzime warstwy HAL mogą używać wielu pól wersji, o ile reprezentują różne wersje główne , przy czym podana jest tylko jedna wersja pomocnicza na wersję główną. 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<fqname>
, ponieważ<fqname>
zawiera wersję.
W przypadku AIDL HAL<version>
nie może być obecna na urządzeniach z Androidem 11 lub starszym.<version>
musi być jedną liczbą całkowitą na urządzeniach z Androidem 12 lub nowszym. Musi być co najwyżej jedna<version>
dla każdej(package, interface, instance)
krotki. Jeśli nie ma, domyślnie1
. Wartość<version>
jest powiązana ze wszystkimi<fqname>
w tym samym<hal>
, ponieważ<fqname>
nie zawiera wersji. -
manifest.hal.interface
- Wymagane, można powtarzać bez duplikatów. Podaj w pakiecie interfejs, który ma nazwę instancji. W
<hal>
może być wiele elementów<interface>
> ; nazwy muszą być różne. -
manifest.hal.interface.name
- Wymagany. Nazwa interfejsu.
-
manifest.hal.interface.instance
- Wymagane, można powtórzyć. Nazwa instancji interfejsu. Może mieć wiele wystąpień interfejsu, ale bez zduplikowanych elementów
<instance>
. -
manifest.hal.fqname
- Opcjonalnie, można powtórzyć. Alternatywny sposób określenia wystąpienia warstwy HAL o nazwie
manifest.hal.name
.- W przypadku warstw HAL HIDL format to
@ MAJOR . MINOR :: INTERFACE / INSTANCE
. - W przypadku AIDL HAL format to
INTERFACE / INSTANCE
.
- W przypadku warstw HAL HIDL format to
-
manifest.sepolicy
- Wymagany. Zawiera wszystkie wpisy dotyczące sepolicy.
-
manifest.sepolicy.version
- Wymagane dla manifestu urządzenia. Deklaruje wersję SELinux. Ma format
SDK_INT . PLAT_INT
. -
manifest.vendor-ndk
- Wymagane, można powtórzyć; wymagane dla manifestu ramowego. Nie może znajdować się w manifeście urządzenia. Wiele wpisów
<vendor-ndk>
musi mieć różne<version>
. Opisuje zestaw migawek VNDK udostępnianych przez platformę. -
manifest.vendor-ndk.version
- Wymagany. Jest to dodatnia liczba całkowita reprezentująca wersję migawki VNDK.
-
manifest.vendor-ndk.library
- Opcjonalnie, może się powtarzać, bez duplikatów. Opisuje zestaw bibliotek VNDK udostępnianych przez platformę dla tej migawki dostawcy VNDK. Wartością jest nazwa pliku biblioteki, np.
libjpeg.so
, zawierająca prefikslib
i sufiks.so
. Żadne komponenty ścieżki nie są dozwolone. -
manifest.system-sdk.version
- Opcjonalnie, może się powtarzać, bez duplikatów; używane tylko przez manifest frameworka. Opisuje zestaw wersji systemowych SDK udostępnianych przez platformę aplikacjom dostawców.
-
manifest.kernel
- Opcjonalny. Opisuje statyczne informacje o jądrze.
-
manifest.kernel.target-level
- Opcjonalny. Opisuje gałąź jądra. Jego wartość domyślna to
manifest.target-level
, jeśli nie występuje. Musi być większa lub równamanifest.target-level
. Zobacz zasady dopasowania jądra, aby uzyskać szczegółowe informacje.