تجلی می کند

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

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

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

• مانیفست فروشنده HAL ها، نسخه های خط مشی SELinux و غیره را که در یک SoC مشترک هستند مشخص می کند. توصیه می شود در درخت منبع 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. مانیفست ODM اختیاری
     4. قطعات مانیفست ODM اختیاری
  2. در غیر این صورت، اگر مانیفست ODM وجود دارد، مانیفست ODM را با قطعات مانیفست ODM اختیاری ترکیب کنید.
  3. /vendor/manifest.xml (میراث، بدون قطعه)
  4. در نهایت، قطعات مانیفست را از هر APEXهای فروشنده ترکیب کنید.

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

  • در دستگاه های قدیمی، مانیفست فروشنده قدیمی و مانیفست 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؛
  • نسخه SDK سیستم.

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

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

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

تکه های آشکار

در اندروید 10 و بالاتر، می‌توانید ورودی مانیفست را با ماژول HAL در سیستم ساخت مرتبط کنید. این کار گنجاندن ماژول HAL را به صورت مشروط در سیستم ساخت آسان تر می کند.

مثال

در فایل Android.bp یا Android.mk خود، vintf_fragments به هر ماژول اضافه کنید. برای مثال، می‌توانید با پیاده‌سازی 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 نصب شده است، به جای type device از type 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 را شرح می دهد. برخی از تگ‌های "الزامی" ممکن است در فایل منبع در درخت منبع اندروید وجود نداشته باشند و در زمان ساخت توسط 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 . فقط در مانیفست متا نسخه 2.0 و بالاتر معتبر است.
• 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 استفاده شود.

manifest.hal.transport.arch

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

• 32 : حالت 32 بیتی
• 64 : حالت 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‌های بومی ممکن است از چندین فیلد نسخه استفاده کنند تا زمانی که نسخه‌های اصلی مجزا را نشان دهند، با تنها یک نسخه فرعی در هر نسخه اصلی ارائه شده است. به عنوان مثال، 3.1 و 3.2 نمی توانند با هم وجود داشته باشند، اما 1.0 و 3.4 می توانند. این برای همه عناصر hal با نام یکسان اعمال می شود، مگر اینکه override="true" . مقادیر <version> با <fqname> مرتبط نیستند زیرا <fqname> دارای یک نسخه است.

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

manifest.hal.interface

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

manifest.hal.interface.name

مورد نیاز. نام رابط.

manifest.hal.interface.instance

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

manifest.hal.fqname

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

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

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

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

manifest.kernel

اختیاری. اطلاعات ایستا در مورد کرنل را شرح می دهد.

manifest.kernel.target-level

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