Pliki manifestu

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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:
    1. Jeśli jednostka SKU jest zdefiniowana (gdzie SKU jest wartością właściwoś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 jednostka SKU jest zdefiniowana (gdzie SKU jest wartością właściwoś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 (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.

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 i framework 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
Aby dokładniej określić informacje o połączeniu z Inet, należy użyć manifest.hal.transport.ip i manifest.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 to MAJOR . MINOR . Przykłady można znaleźć w hardware/interfaces , vendor/${VENDOR}/interfaces , frameworks/hardware/interfaces lub system/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ów hal o tej samej nazwie, chyba że override="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ślnie 1 . 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 .
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 prefiks 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 wartość domyślna to manifest.target-level , jeśli nie występuje. Musi być większa lub równa manifest.target-level . Zobacz zasady dopasowania jądra, aby uzyskać szczegółowe informacje.