Obiekt VINTF agreguje dane z plików manifestu urządzenia i manifestu frameworku (XML). Oba manifesty mają ten sam format, ale nie wszystkie elementy są wspólne (szczegółowe informacje o schemacie znajdziesz w schemacie pliku manifestu).
Plik manifestu urządzenia
Manifest urządzenia (dostarczony przez urządzenie) składa się z manifestu dostawcy i manifestu ODM.
- Plik manifestu dostawcy określa interfejsy HAL, wersje zasad SELinux itp., które są wspólne dla SoC. Zaleca się umieszczenie go w drzewie źródłowym Androida w folderze
device/VENDOR/DEVICE/manifest.xml, ale można użyć wielu plików fragmentów. Więcej informacji znajdziesz w artykułach Fragmenty pliku manifestu i Generowanie DM z fragmentów. - Manifest ODM zawiera listę HAL-i dla danego produktu w partycji ODM.
Obiekt VINTF wczytuje plik manifestu ODM w takiej kolejności:
- Jeśli zdefiniowana jest wartość
SKU(gdzieSKUto wartość właściwościro.boot.product.hardware.sku),/odm/etc/vintf/manifest_SKU.xml /odm/etc/vintf/manifest.xml- Jeśli określono właściwość
SKU,/odm/etc/manifest_SKU.xml /odm/etc/manifest.xml
- Jeśli zdefiniowana jest wartość
- Manifest dostawcy zawiera listę HAL-i dla produktu w partycji dostawcy.
Obiekt VINTF wczytuje manifest dostawcy w takim porządku:
- Jeśli zdefiniowana jest wartość
SKU(gdzieSKUto wartość właściwościro.boot.product.vendor.sku),/vendor/etc/vintf/manifest_SKU.xml /vendor/etc/vintf/manifest.xml
- Jeśli zdefiniowana jest wartość
- Obiekt VINTF wczytuje plik manifestu urządzenia w takim porządku:
- Jeśli plik manifestu dostawcy istnieje, połącz te elementy:
- Plik manifestu dostawcy
- Opcjonalne fragmenty pliku manifestu dostawcy
- Opcjonalny plik manifestu ODM
- Opcjonalne fragmenty pliku manifestu ODM
- Jeśli plik manifestu ODM istnieje, połącz go z opcjonalnymi fragmentami pliku manifestu ODM.
/vendor/manifest.xml(starsza wersja, brak fragmentów)- Na koniec połącz fragmenty pliku manifestu z dowolnych plików APEX dostawcy. Fragmenty pliku manifestu
są ładowane z katalogu
etc/vintfkażdego Apexa (np./apex/<apex name>/etc/vintf).
Uwaga:
- Na starszych urządzeniach używany jest stary plik manifestu dostawcy i plik 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 z pliku manifestu dostawcy.
- Podczas łączenia listy plików manifestu pliki manifestu, które znajdują się na liście później, mogą zastąpić tagi w plikach manifestu, które znajdują się na liście wcześniej, pod warunkiem że tagi w późniejszym pliku manifestu mają atrybut
override="true". Na przykład manifest ODM może zastąpić niektóre tagi<hal>z manifestu dostawcy. Poniżej znajdziesz dokumentację atrybutuoverride.
- Jeśli plik manifestu dostawcy istnieje, połącz te elementy:
Dzięki temu wiele produktów z tą samą płytką może korzystać z tego samego obrazu dostawcy (który udostępnia wspólne interfejsy HAL) i mieć różne obrazy ODM (które określają interfejsy HAL dla poszczególnych produktów).
Oto przykład pliku 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ład pliku 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ład pliku 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 artykule Tworzenie pliku manifestu urządzenia.
Plik manifestu platformy
Plik manifestu platformy składa się z manifestu systemu, manifestu produktu i manifestu system_ext.
-
Plik manifestu systemu (dostarcza Google) jest generowany ręcznie i znajduje się w drzewie źródłowym Androida na stronie
/system/libhidl/manifest.xml. - Manifest produktu (dostarczony przez urządzenie) zawiera listę interfejsów HAL obsługiwanych przez moduły zainstalowane na partycji produktu.
-
Plik manifestu system_ext (dostarczony przez urządzenie) zawiera te informacje:
- 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żyć wielu plików fragmentów. Więcej informacji znajdziesz w artykule Fragmenty pliku manifestu.
Oto przykład manifestu 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 pliku manifestu
W Androidzie 10 lub nowszym możesz powiązać wpis w pliku manifestu z modułem HAL w systemie kompilacji. Dzięki temu łatwiej jest warunkowo uwzględnić moduł HAL w systemie kompilacji.
Przykład
W pliku Android.bp lub Android.mk dodaj vintf_fragments do dowolnego zainstalowanego na urządzeniu modułu, np. cc_binary lub rust_binary.
Możesz na przykład zmodyfikować moduł za pomocą implementacji interfejsu HAL (my.package.foo@1.0-service-bar).
... { ... vintf_fragments: ["manifest_foo.xml"], ... }
LOCAL_MODULE := ... LOCAL_VINTF_FRAGMENTS := manifest_foo.xml
Utwórz plik o nazwie manifest_foo.xml, w którym umieścisz plik manifestu dla tego modułu. Podczas kompilacji ten plik manifestu jest dodawany do urządzenia. Dodanie wpisu tutaj jest równoznaczne z dodaniem wpisu do głównego pliku manifestu urządzenia.
Umożliwia to klientom korzystanie z interfejsu i umożliwia VTS identyfikowanie implementacji HAL na urządzeniu. Ten plik manifestu wykonuje wszystkie funkcje zwykłego pliku manifestu.
Przykład poniżej 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 typu framework zamiast typu 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 jest zapakowany w APEX dostawcy, należy spakować powiązane fragmenty VINTF w tym samym APEX za pomocą prebuilt_etc, zgodnie z opisem w fragmentach VINTF.
Schemat pliku manifestu
W tej sekcji opisano znaczenie tych tagów XML. Niektóre tagi „required” mogą nie występować w pliku źródłowym w drzewie źródłowym Androida i być zapisane przez assemble_vintf w czasie kompilacji. Wymagane tagi muszą znajdować się w odpowiednich plikach na urządzeniu.
?xml- Opcjonalnie. Udostępnia informacje tylko parsownikowi XML.
manifest.version- Wymagane. Metawersja tego pliku manifestu. Opisuje elementy oczekiwane w pliku manifestu. Niezwiązane z wersją pliku XML.
manifest.type- Wymagane. Typ tego pliku manifestu. W przypadku pliku manifestu urządzenia ma on wartość
device, a w przypadku pliku manifestu platformy – wartośćframework. manifest.target-level- Wymagany w pliku manifestu urządzenia. Określa wersję ramki zgodności (FCM), z którą ma być zgodny ten plik manifestu urządzenia. Jest to też wysyłana wersja FCM urządzenia.
manifest.hal- Opcjonalnie, można powtórzyć. Pojedynczy HAL (HIDL lub natywny, np. GL) w zależności od atrybutu
format. manifest.hal.format- Opcjonalnie. Wartość może być równa:
hidl: interfejsy HIDL HAL. Jest to ustawienie domyślne.aidl: interfejsy AIDL HAL. Dozwolone tylko w przypadku metawersji pliku manifestu w wersji 2.0 lub nowszej.native: natywne HAL.
manifest.hal.max-level- Opcjonalnie. Obowiązuje tylko w przypadku plików manifestu frameworka. Jeśli jest ustawiona, funkcje HAL o poziomie maksymalnym niż docelowa wersja FCM w pliku manifestu frameworka są wyłączone.
manifest.hal.override- Opcjonalnie. Wartość może być równa:
true: zastąpić inne elementy<hal>tymi samymi elementami<name>w tej samej wersji głównej. Jeśli w tym elemencie<hal>nie ma elementów<version>ani<fqname>, element<hal>deklaruje, że ten interfejs HAL jest wyłączony.false: nie zastępuj innych elementów<hal>tymi z tą samą wersją główną i wersją<name>.
manifest.hal.name- Wymagane. Pełna nazwa pakietu HAL. Wiele wpisów HAL może używać tej samej nazwy. Przykłady:
android.hardware.camera(HIDL lub AIDL HAL)GLES(natywne HAL, wymagana tylko nazwa)
manifest.hal.transport- Wymagany, gdy
manifest.hal.format == "hidl". W innych przypadkach nie może być obecny. Określa, jaki transport jest używany, gdy menedżer usługi otrzymuje zapytanie od interfejsu z tego pakietu. Wartość może być równa:hwbinder: tryb binderapassthrough: tryb przekazywania
- Opcjonalnie, jeśli
manifest.hal.format == "aidl". W innych przypadkach nie może być obecny. Określa, jaki transport jest używany, gdy interfejs jest obsługiwany zdalnie. Wartość musi być:inet: gniazdo internetowe
manifest.hal.transport.ipimanifest.hal.transport.port. manifest.hal.transport.arch- jest wymagane w przypadku
passthrough, ale nie może być obecne w przypadkuhwbinder. Opisuje liczbę bitów usługi przesyłania dalej. Wartość może być równa:32: tryb 32-bitowy64: tryb 64-bitowy32+64: obie
manifest.hal.transport.ip- Wymagane w przypadku
inet, w przeciwnym razie nie może być obecne. Opisuje adres IP, z którego jest obsługiwany zdalny interfejs. manifest.hal.transport.port- Wymagane w przypadku
inet, w przeciwnym razie nie może być obecne. Opisuje port, z którego udostępniany jest interfejs zdalny. manifest.hal.version- Opcjonalnie, można powtórzyć. Wersja tagów
halw pliku manifestu.
W przypadku interfejsów HIDL i natywnych interfejsów HAL formatem jestMAJOR.MINOR. Przykłady:hardware/interfaces,vendor/${VENDOR}/interfaces,frameworks/hardware/interfaceslubsystem/hardware/interfaces.
HIDL i natywne interfejsy HAL mogą używać wielu pól wersji, o ile reprezentują różne wersje główne, przy czym na każdą wersję główną przypada tylko jedna wersja podrzędna. Na przykład wersje 3.1 i 3.2 nie mogą współistnieć, ale 1.0 i 3.4 mogą. Dotyczy to wszystkich elementówhalo tej samej nazwie, z wyjątkiemoverride="true". Wartości<version>nie są powiązane z wartościami<fqname>, ponieważ<fqname>przechowuje wersję.
W przypadku interfejsów AIDL HAL<version>nie może być obecny na urządzeniach z Androidem 11 lub starszym. Na urządzeniach z Androidem 12 lub nowszym wartość<version>musi być liczbą całkowitą. W przypadku każdej kolumny(package, interface, instance)może być podana co najwyżej 1 wartość<version>. Jeśli nie jest obecny, przyjmuje wartość domyślną1. Wartość<version>jest powiązana ze wszystkimi<fqname>w tym samym<hal>, ponieważ<fqname>nie ma wersji. manifest.hal.interface- Wymagane, może się powtarzać bez duplikatów. W pakiecie określ interfejs, który ma nazwę instancji. W elementach
<hal>może być wiele elementów<interface>, ale ich nazwy muszą być różne. manifest.hal.interface.name- Wymagane. Nazwa interfejsu.
manifest.hal.interface.instance- Wymagane, można powtórzyć. Nazwa instancji interfejsu. Może mieć wiele instancji interfejsu, ale bez duplikatów elementów
<instance>. manifest.hal.fqname- Opcjonalnie, można powtórzyć. Alternatywny sposób określania instancji HAL o nazwie
manifest.hal.name.- W przypadku interfejsów HIDL HAL format to
@MAJOR.MINOR::INTERFACE/INSTANCE. - W przypadku interfejsów AIDL HAL format to
INTERFACE/INSTANCE.
- W przypadku interfejsów HIDL HAL format to
manifest.sepolicy- Wymagane. Zawiera wszystkie wpisy związane z sepolicy.
manifest.sepolicy.version- Wymagany w pliku manifestu urządzenia. Deklaruje wersję SELinux. Ma format
SDK_INT.PLAT_INT. manifest.vendor-ndk- Wymagany, może się powtarzać; wymagany w pliku manifestu platformy. Nie może być obecny w pliku manifestu urządzenia. Wiersze
<vendor-ndk>muszą mieć różne wartości<version>. Opisuje zestaw zrzutów ekranu VNDK udostępnianych przez platformę. manifest.vendor-ndk.version- Wymagane. Dodatnia liczba całkowita określająca wersję snapshotu VNDK.
manifest.vendor-ndk.library- Opcjonalnie, można powtarzać, bez duplikatów. Opisuje zestaw bibliotek VNDK udostępnionych przez framework w ramach tego snapshotu dostawcy VNDK. Wartość to nazwa pliku biblioteki, np.
libjpeg.so, z w. w. z prefiksemlibi sufiksem.so. Nie można stosować komponentów ścieżki. manifest.system-sdk.version- Opcjonalne, mogą się powtarzać bez duplikatów; używane tylko przez manifest frameworku. Opisuje zestaw wersji systemu pakietu SDK udostępnianych przez platformę aplikacjom dostawców.
manifest.kernel- Opcjonalnie. Zawiera opis statycznych informacji o jądrze.
manifest.kernel.target-level- Opcjonalnie. Opisuje gałąź jądra. Jeśli nie podano wartości, domyślnie jest to
manifest.target-level. Musi być większa lub równamanifest.target-level. Szczegółowe informacje znajdziesz w regułach dopasowania jądra.