مانیفست‌ها

یک شیء VINTF داده‌ها را از فایل‌های (XML) مانیفست دستگاه و مانیفست چارچوب جمع‌آوری می‌کند. هر دو مانیفست قالب مشترکی دارند، اگرچه همه عناصر برای هر دو اعمال نمی‌شوند (برای جزئیات مربوط به طرح‌واره، به طرح‌واره فایل مانیفست مراجعه کنید).

مانیفست دستگاه

مانیفست دستگاه (ارائه‌شده توسط دستگاه) شامل مانیفست فروشنده و مانیفست ODM است.

• مانیفست فروشنده «لایه‌های انتزاعی سخت‌افزار»، نسخه‌های خط‌مشی SELinux، و غیره را که در «سیستم روی تراشه» مشترک هستند مشخص می‌کند. توصیه می‌شود در درخت منبع Android در device/VENDOR/DEVICE/manifest.xml قرار داده شود، اما می‌توان از چندین فایل تکه‌تکه استفاده کرد. برای جزئیات، تکه‌های مانیفست و تولید DM از تکه‌ها را ببینید.
• مانیفست ODM، HALهای مختص محصول را در پارتیشن ODM فهرست می‌کند. شیء VINTF مانیفست ODM را به این ترتیب بار می‌کند:
  1. اگر SKU تعریف شده باشد (که SKU مقدار خصوصیت ro.boot.product.hardware.sku است)، /odm/etc/vintf/manifest_SKU.xml
  2. /odm/etc/vintf/manifest.xml
  3. اگر SKU تعریف شده باشد، /odm/etc/manifest_SKU.xml
  4. /odm/etc/manifest.xml
• مانیفست فروشنده «لایه‌های انتزاع سخت‌افزار» (HAL) مختص محصول را در پارتیشن فروشنده فهرست می‌کند. شیء VINTF مانیفست فروشنده را به این ترتیب بار می‌کند:
  1. اگر SKU تعریف شده باشد (که SKU مقدار خصوصیت ro.boot.product.vendor.sku است)، /vendor/etc/vintf/manifest_SKU.xml
  2. /vendor/etc/vintf/manifest.xml
• شیء VINTF مانیفست دستگاه را به این ترتیب بار می‌کند:
  1. اگر مانیفست فروشنده وجود دارد، موارد زیر را ترکیب کنید:
     1. فهرست فروشنده
     2. تکه‌های اختیاری مانیفست فروشنده
     3. مانیفست اختیاری سنجش درون‌دستگاهی
     4. تکه‌های اختیاری مانیفست ODM
  2. درغیراین‌صورت، اگر مانیفست ODM وجود دارد، مانیفست ODM را با تکه‌های مانیفست اختیاری ODM ترکیب کنید.
  3. ‫/vendor/manifest.xml (قدیمی، بدون تکه‌کد)
  4. درنهایت، تکه‌های مانیفست را از همه APEXهای فروشنده ترکیب کنید. تکه‌های مانیفست از دایرکتوری etc/vintf هر APEX (مثلاً /apex/<apex name>/etc/vintf) بار می‌شود.

  توجه داشته باشید که:

  • در دستگاه‌های قدیمی، از مانیفست فروشنده قدیمی و مانیفست ODM استفاده می‌شود. مانیفست ODM ممکن است مانیفست فروشنده قدیمی را کاملاً لغو کند.
  • در دستگاه‌هایی که با Android 9 راه‌اندازی شده‌اند، مانیفست ODM با مانیفست فروشنده ترکیب می‌شود.
  • هنگام ترکیب فهرستی از مانیفست‌ها، مانیفست‌هایی که در فهرست دیرتر ظاهر می‌شوند ممکن است برچسب‌های مانیفست‌هایی را که زودتر در فهرست ظاهر می‌شوند لغو کنند، مشروط بر اینکه برچسب‌های مانیفست بعدی دارای ویژگی override="true" باشند. برای مثال، مانیفست ODM ممکن است برخی‌از برچسب‌های <hal> را از مانیفست فروشنده لغو کند. اسناد مربوط به مشخصه override را در زیر ببینید.

این راه‌اندازی به چندین محصول با برد یکسان امکان می‌دهد تصویر فروشنده یکسانی را (که HALهای مشترک ارائه می‌دهد) هم‌رسانی کنند، اما تصاویر ODM متفاوتی داشته باشند (که HALهای مختص محصول را مشخص می‌کند).

در اینجا نمونه‌ای از مانیفست فروشنده آورده شده است.

<?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>

در اینجا نمونه‌ای از مانیفست 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>

در اینجا نمونه‌ای از مانیفست دستگاه در بسته 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>

برای جزئیات بیشتر، به توسعه مانیفست دستگاه مراجعه کنید.

مانیفست چارچوب

فایل مانیفست چارچوب شامل مانیفست سیستم، مانیفست محصول، و مانیفست system_ext است.

• مانیفست سیستم (ارائه‌شده توسط Google) به‌صورت دستی تولید می‌شود و در درخت منبع Android در /system/libhidl/manifest.xml قرار دارد.
• مانیفست محصول (ارائه‌شده توسط دستگاه) فهرست HALهایی را که توسط واحدهای نصب‌شده در پارتیشن محصول ارائه می‌شوند نشان می‌دهد.
• مانیفست system_ext (ارائه‌شده توسط دستگاه) موارد زیر را فهرست می‌کند:
  • ‫HALهایی که توسط واحدهای نصب‌شده در پارتیشن system_ext ارائه می‌شوند؛
  • نسخه‌های VNDK؛
  • نسخه «کیت توسعه نرم‌افزار سیستم».

مشابه مانیفست دستگاه، می‌توان از چندین فایل قطعه استفاده کرد. برای جزئیات، به تکه‌کدهای مانیفست مراجعه کنید.

در اینجا یک مانیفست چارچوب نمونه آورده شده است.

<?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>

قطعه‌های مانیفست

در Android 10 و نسخه‌های بالاتر، می‌توانید ورودی مانیفست را با واحد HAL در سیستم ساخت مرتبط کنید. این کار باعث می‌شود افزودن مشروط واحد HAL در سیستم ساخت آسان‌تر شود.

مثال

در فایل Android.bp یا Android.mk، vintf_fragments را به هر واحدی که به‌طور صریح در دستگاه نصب شده است، مثل cc_binary یا rust_binary، اضافه کنید. برای مثال، می‌توانید واحد را با پیاده‌سازی خودتان از HAL (my.package.foo@1.0-service-bar) اصلاح کنید.

... {
    ...
    vintf_fragments: ["manifest_foo.xml"],
    ...
}

LOCAL_MODULE := ...
LOCAL_VINTF_FRAGMENTS := manifest_foo.xml

در فایلی به‌نام manifest_foo.xml، مانیفست این ماژول را ایجاد کنید. در زمان ساخت، این مانیفست به دستگاه اضافه می‌شود. افزودن ورودی در اینجا همانند افزودن ورودی در مانیفست اصلی دستگاه است. این کار به مشتریان امکان می‌دهد از میانای کاربری استفاده کنند و به VTS امکان می‌دهد پیاده‌سازی‌های HAL موجود در دستگاه را شناسایی کند. هر کاری که مانیفست معمولی انجام می‌دهد، این مانیفست هم انجام می‌دهد.

مثال زیر android.hardware.foo@1.0::IFoo/default را پیاده‌سازی می‌کند که در بخش vendor یا odm نصب می‌شود. اگر در پارتیشن system،‏ product، یا system_ext نصب شده است، به‌جای نوع device، از نوع framework استفاده کنید.

<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>

اگر یک ماژول HAL در یک APEX فروشنده بسته‌بندی شده است، قطعات VINTF مرتبط با آن را در همان APEX با prebuilt_etc بسته‌بندی کنید، همان‌طور که در قطعات VINTF توضیح داده شده است.

طرح‌واره فایل مانیفست

این بخش معنی این برچسب‌های XML را شرح می‌دهد. برخی‌از برچسب‌های «الزامی» می‌توانند در فایل منبع در درخت منبع Android وجود نداشته باشند و توسط assemble_vintf در زمان ساخت نوشته شوند. برچسب‌های الزامی باید در فایل‌های مربوطه در دستگاه وجود داشته باشند.

?xml

اختیاری. فقط اطلاعات را به تجزیه‌کننده XML ارائه می‌دهد.

manifest.version

‫

الزامی. نسخه فراداده‌ای این مانیفست . عناصر موردانتظار در مانیفست را توصیف می‌کند. غیرمرتبط با نسخه XML.

manifest.type

‫

الزامی. نوع این مانیفست. این مقدار device را برای فایل مانیفست دستگاه و framework را برای فایل مانیفست چارچوب دارد.

manifest.target-level

برای مانیفست دستگاه لازم است. نسخه ماتریس سازگاری چارچوب (FCM) را مشخص می‌کند که این مانیفست دستگاه برای سازگاری با آن هدف‌گذاری شده است. به این نسخه، نسخه FCM ارسال دستگاه نیز گفته می‌شود.

manifest.hal

اختیاری، می‌تواند تکرار شود. یک HAL (HIDL یا بومی، مانند GL)، بسته به ویژگی format.

manifest.hal.format

‫

اختیاری. مقدار می‌تواند یکی از موارد زیر باشد:

• hidl: HIDL HALs. این گزینه پیش‌فرض است.
• ‫aidl: ‏ AIDL HALs. فقط در فراداده مانیفست نسخه ۲.۰ و بالاتر معتبر است.
• ‫native: HALهای بومی.

manifest.hal.max-level

اختیاری. فقط در مانیفست‌های چارچوب معتبر است. اگر تنظیم شده باشد، HALهایی با حداکثر سطح پایین‌تر از «نسخه FCM هدف» در مانیفست چارچوب غیرفعال می‌شوند.

manifest.hal.override

اختیاری. مقدار می‌تواند یکی از موارد زیر باشد:

• true: عناصر <hal> دیگر را با همان <name> و نسخه عمده لغو کنید. اگر هیچ <version> یا <fqname> در این عنصر <hal> وجود نداشته باشد، عنصر <hal> اعلام می‌کند که این HAL غیرفعال است.
• ‫false: عناصر <hal> دیگر با همان <name> و نسخه اصلی را ملغی نکنید.

manifest.hal.name

‫

الزامی. نام بسته کاملاً واجدشرایط HAL. چندین ورودی HAL می‌توانند از نام یکسانی استفاده کنند. مثال‌ها:

• ‫android.hardware.camera (HIDL یا AIDL HAL)
• GLES (HAL بومی، فقط به نام نیاز دارد)

manifest.hal.transport

وقتی manifest.hal.format == "hidl" الزامی است. درغیراین‌صورت نباید وجود داشته باشد. بیان می‌کند که وقتی میانایی از این بسته از مدیر سرویس درخواست می‌شود، از چه انتقالی استفاده می‌شود. مقدار می‌تواند یکی از این موارد باشد:

• ‫hwbinder: حالت Binderized
• ‫passthrough: حالت گذرگاه

وقتی manifest.hal.format == "aidl" اختیاری است. درغیراین‌صورت نباید حضور داشته باشد. مشخص می‌کند که هنگام ارائه رابط از راه دور از چه انتقالی استفاده می‌شود. مقدار باید:

• ‫inet: پریز Inet

باید از manifest.hal.transport.ip و manifest.hal.transport.port برای مشخص کردن بیشتر اطلاعات اتصال Inet استفاده شود.

manifest.hal.transport.arch

‫

برای passthrough الزامی است و نباید برای hwbinder وجود داشته باشد. تعداد بیت‌های سرویس عبوری ارائه‌شده را شرح می‌دهد. مقدار می‌تواند یکی از این موارد باشد:

• ‫32: حالت ۳۲ بیتی
• ‫64: حالت ۶۴ بیتی
• 32+64: هر دو

manifest.hal.transport.ip

برای inet الزامی است و درغیراین‌صورت نباید وجود داشته باشد. نشانی IP را که واسط راه دور از آن ارائه می‌شود شرح می‌دهد.

manifest.hal.transport.port

برای inet الزامی است و درغیراین‌صورت نباید وجود داشته باشد. درگاهی را که رابط از دور از آن ارائه می‌شود شرح می‌دهد.

manifest.hal.version

اختیاری، می‌تواند تکرار شود. نسخه‌ای برای برچسب‌های hal در مانیفست.

برای HIDL و HALهای بومی، قالب MAJOR.MINOR است. برای مثال، به hardware/interfaces، vendor/${VENDOR}/interfaces، frameworks/hardware/interfaces، یا system/hardware/interfaces مراجعه کنید.

‫HIDL و HAL بومی می‌توانند از چندین فیلد نسخه استفاده کنند، به‌شرطی که نشان‌دهنده نسخه‌های اصلی متمایز باشند و فقط یک نسخه فرعی برای هر نسخه اصلی ارائه شود. برای مثال، نسخه ۳.۱ و ۳.۲ نمی‌توانند هم‌زمان وجود داشته باشند، اما نسخه ۱.۰ و ۳.۴ می‌توانند. این امر برای همه عناصر hal با نام یکسان اعمال می‌شود، مگر اینکه override="true". مقادیر <version> با <fqname> مرتبط نیستند زیرا <fqname> نسخه دارد.

برای AIDL HAL، <version> نباید در دستگاه‌های دارای Android 11 و پایین‌تر وجود داشته باشد. در دستگاه‌های دارای Android 12 و بالاتر، <version> باید عدد صحیح یکتایی باشد. باید حداکثر یک <version> برای هر چندتایی (package, interface, instance) وجود داشته باشد. اگر وجود ندارد، به‌طور پیش‌فرض روی 1 تنظیم می‌شود. مقدار <version> با همه <fqname> در همان <hal> مرتبط است زیرا <fqname> نسخه ندارد.

manifest.hal.interface

الزامی است، می‌تواند بدون تکرار تکرار شود. واسطی را در بسته که نام نمونه دارد بیان کنید. چندین عنصر <interface> می‌تواند در <hal> وجود داشته باشد؛ نام‌ها باید متمایز باشند.

manifest.hal.interface.name

‫

الزامی. نام میانای شبکه.

manifest.hal.interface.instance

‫

الزامی، می‌تواند تکرار شود. نام نمونه واسط. می‌تواند نمونه‌های متعددی برای یک میانای داشته باشد اما عناصر <instance> تکراری نداشته باشد.

manifest.hal.fqname

اختیاری، می‌تواند تکرار شود. روش جایگزینی برای مشخص کردن نمونه‌ای برای HAL با نام manifest.hal.name.

• برای HIDL HAL، قالب به‌صورت @MAJOR.MINOR::INTERFACE/INSTANCE است.
• برای AIDL HAL، قالب INTERFACE/INSTANCE است.

manifest.sepolicy

الزامی. شامل همه ورودی‌های مربوط به sepolicy است.

manifest.sepolicy.version

برای مانیفست دستگاه لازم است. نسخه SELinux را اعلام می‌کند. این فایل قالب SDK_INT.PLAT_INT را دارد.

manifest.vendor-ndk

‫

الزامی، می‌تواند تکرار شود؛ برای مانیفست چارچوب الزامی است. نباید در مانیفست دستگاه وجود داشته باشد. چندین ورودی <vendor-ndk> باید <version>های متفاوتی داشته باشند. مجموعه‌ای از تصاویر فوری VNDK ارائه‌شده توسط چارچوب را توصیف می‌کند.

manifest.vendor-ndk.version

‫

الزامی. این عدد صحیح مثبتی است که نشان‌دهنده نسخه نمونه فوری VNDK است.

manifest.vendor-ndk.library

اختیاری، می‌تواند تکرار شود، بدون موارد تکراری. مجموعه‌ای از کتابخانه‌های VNDK را که چارچوب برای این تصویر فوری فروشنده VNDK ارائه کرده است توصیف می‌کند. مقدار نام فایل کتابخانه است، برای نمونه libjpeg.so، شامل پیشوند lib و پسوند .so. هیچ مؤلفه مسیری مجاز نیست.

manifest.system-sdk.version

اختیاری، می‌تواند تکرار شود، بدون تکراری؛ فقط توسط چارچوب مانیفست استفاده می‌شود. مجموعه‌ای از نسخه‌های کیت توسعه نرم‌افزار سیستم را که چارچوب برای برنامه‌های فروشنده ارائه می‌دهد شرح می‌دهد.

manifest.kernel

‫

اختیاری. اطلاعات ایستا درباره هسته را شرح می‌دهد.

manifest.kernel.target-level

‫

اختیاری. شاخه هسته را توصیف می‌کند. اگر این عنصر وجود نداشته باشد، مقدار آن به‌طور پیش‌فرض روی manifest.target-level تنظیم می‌شود. باید بزرگ‌تر یا مساوی با manifest.target-level باشد. برای جزئیات، قوانین مطابقت هسته را ببینید.