Manifesty

Dane A kruszywa obiektów VINTF z manifestu urządzenia i ramowych oczywistych plików (XML). Obydwa manifesty dzielić formatu, choć nie wszystkie elementy dotyczą zarówno (szczegóły na schemacie, patrz Manifest schemat pliku ).

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ę, aby znajdować się w drzewie źródłowym Androida na device/ VENDOR / DEVICE /manifest.xml , ale wiele plików fragment może być używany. Szczegółowe informacje można znaleźć Manifest fragmenty i generowanie DM z fragmentów .
  • Wykazy ODM manifestują HAL specyficzne dla produktu w partycji ODM . Obiekt VinTF ładuje manifest ODM w następującej kolejności:
    1. Jeśli SKU określone (gdzie SKU jest wartość własności ro.boot.product.hardware.sku ) /odm/etc/vintf/manifest_ SKU .xml
    2. /odm/etc/vintf/manifest.xml
    3. Jeśli SKU jest zdefiniowana, /odm/etc/manifest_ SKU .xml
    4. /odm/etc/manifest.xml
  • Manifest dostawcy zawiera listę warstw HAL specyficznych dla produktu w partycji dostawcy. Obiekt VinTF ładuje manifest dostawcy w następującej kolejności:
    1. Jeśli SKU określone (gdzie SKU jest wartość własności ro.boot.product.vendor.sku ) /vendor/etc/vintf/manifest_ SKU .xml
    2. /vendor/etc/vintf/manifest.xml
  • Obiekt VinTF ładuje manifest urządzenia w następującej kolejności:
    1. Jeśli manifest dostawcy istnieje, połącz następujące elementy:
      1. Manifest sprzedawcy
      2. Opcjonalne fragmenty manifestu dostawcy
      3. Opcjonalny manifest ODM
      4. Opcjonalne fragmenty manifestu ODM
    2. W przeciwnym razie, jeśli manifest ODM istnieje, połącz manifest ODM z opcjonalnymi fragmentami manifestu ODM.
    3. /vendor/manifest.xml (starszego typu, nie 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.
    • Przy łączeniu wykaz manifestów, wykazy, które pojawiają się później w wykazie mogą zastąpić tagi w manifestach, które pojawiają się wcześniej na liście, pod warunkiem, że tagi w późniejszych oczywisty mają atrybutu override="true" . Na przykład, manifest ODM może zastąpić niektóre <hal> tagi z sprzedawca oczywisty. Zapoznać się z dokumentacją atrybutu override poniżej.

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 Device Manifest Development .

Manifest ramowy

Plik manifestu struktury składa się z manifestu systemu, manifestu produktu i manifestu system_ext.

  • Manifest System (dostarczone przez Google) jest generowany ręcznie i mieszka w drzewie źródłowym Androida w /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. Szczegółowe informacje można znaleźć Manifest fragmenty .

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 swojej Android.bp lub Android.mk pliku dodaj vintf_fragments do każdego modułu. Na przykład, można zmodyfikować moduł z realizacji swojej 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 utworzyć 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 narzędziach android.hardware.foo@1.0::IFoo/default , który jest zainstalowany na vendor lub odm partycji. Jeśli jest zainstalowany w system , product lub system_ext partycji, typ użycie 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>

Schemat pliku manifestu

W tej sekcji opisano znaczenie tych znaczników XML. Niektóre „niezbędne” znaczniki mogą być niedostępne z pliku źródłowego w drzewie źródłowym Androida i napisany przez assemble_vintf w czasie kompilacji. Wymagane tagi muszą być obecne w odpowiednich plikach na urządzeniu.

?xml
Opcjonalny. Dostarcza tylko 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 do pliku manifestu urządzenia i framework do pliku manifestu ramowej.
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 HAL (HIDL lub rodzimy, takich jak GL), w zależności od format atrybutu.
manifest.hal.format
Opcjonalny. Wartość może być jedną z:
  • hidl : HAL HIDL. To jest ustawienie domyślne.
  • aidl : HAL AIDL . Obowiązuje tylko w manifestach meta w wersji 2.0 i nowszych.
  • native : Native 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ępuje inne <hal> elementy z tego samego <name> i wersji głównej. Jeśli nie <version> lub <fqname> są w tym <hal> elementu, wówczas <hal> Element ten HAL deklaruje się być wyłączony.
  • false : Nie zastępują inne <hal> elementy z tego samego <name> i wersji głównej.
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 (native HAL, wymaga tylko nazwy)
manifest.hal.transport
Wymagana, gdy manifest.hal.format == "hidl" . NIE MOŻE być obecny w przeciwnym razie. 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 Binderized:
  • passthrough : tryb Passthrough
manifest.hal.transport.arch
Wymagane dla passthrough i nie muszą być obecni hwbinder . Opisuje bitowość świadczonej usługi przekazywania. Wartość może być jedną z:
  • 32 w trybie 32-bitowym:
  • 64 trybie 64-bitowym:
  • 32+64 : Zarówno
manifest.hal.version
Opcjonalnie, można powtórzyć. Wersja dla hal znaczników w manifeście.

Dla HIDL i rodzimych Hals, format jest MAJOR . MINOR . Przykłady można znaleźć w hardware/interfaces , vendor/${VENDOR}/interfaces , framework/hardware/interfaces lub system/hardware/interfaces .

HIDL i rodzime HAL może używać wielu pól wersji Dopóki stanowią one odrębne główne wersje, ze tylko jedna wersja moll na głównej wersji przewidzianej. Na przykład 3.1 i 3.2 nie mogą współistnieć, ale 1.0 i 3.4 mogą. Dotyczy to wszystkich hal elementów o tej samej nazwie, chyba override="true" . Wartości <version> nie są związane z <fqname> bo <fqname> niesie wersję.

Dla AIDL Hals, <version> nie muszą być obecne na urządzeniach z systemem Android 11 i poniżej. <version> musi być pojedynczą liczbę całkowitą na urządzeniach z systemem Android 12 i powyżej. Musi istnieć co najwyżej jeden <version> dla każdego (package, interface, instance) krotki. Jeśli nie występuje, domyślnie 1 . Wartość <version> jest związany ze wszystkimi <fqname> w tym samym <hal> bo <fqname> nie posiadać wersję.
manifest.hal.interface
Wymagane, można powtarzać bez duplikatów. Podaj w pakiecie interfejs, który ma nazwę instancji. Nie może być wielokrotnością <interface> elementy w <hal> ; 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żna mieć wiele wystąpień na interfejs, ale nie duplikowane <instance> elementów.
manifest.hal.fqname
Opcjonalnie, można powtórzyć. Alternatywnym sposobem, aby określić instancję dla HAL o nazwie manifest.hal.name .
  • Dla HAL HIDL, format jest @ MAJOR . MINOR :: INTERFACE / INSTANCE .
  • Dla HAL AIDL, format jest INTERFACE / INSTANCE .
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. Stwardnienie <vendor-ndk> wpisy muszą mieć inny <version> S. 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ść to nazwa biblioteki, np libjpeg.so tym prefiksu lib 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 domyślne wartości do manifest.target-level , jeśli nie występuje. Musi być większa lub równa manifest.target-level . Zobacz jądra zasady meczu dla szczegółów.