یک شی VINTF داده ها را از فایل های مانیفست دستگاه و فایل های مانیفست چارچوب (XML) جمع می کند. هر دو مانیفست یک قالب مشترک دارند، اگرچه همه عناصر برای هر دو اعمال نمی شوند (برای جزئیات در مورد طرح، به طرحواره فایل Manifest مراجعه کنید).
مانیفست دستگاه
مانیفست دستگاه (ارائه شده توسط دستگاه) از مانیفست فروشنده و مانیفست ODM تشکیل شده است.
- مانیفست فروشنده HAL ها، نسخه های خط مشی SELinux و غیره را که در یک SoC مشترک هستند مشخص می کند. توصیه می شود در درخت منبع Android در
device/ VENDOR / DEVICE /manifest.xml
قرار داده شود، اما می توان از چندین فایل قطعه استفاده کرد. برای جزئیات، به قطعات آشکار و ایجاد DM از قطعات مراجعه کنید. - مانیفست ODM HAL های مخصوص محصول را در پارتیشن ODM فهرست می کند. شی VINTF مانیفست ODM را به ترتیب بارگیری می کند:
- اگر
SKU
تعریف شده باشد (که در آنSKU
مقدار ویژگیro.boot.product.hardware.sku
است)،/odm/etc/vintf/manifest_ SKU .xml
-
/odm/etc/vintf/manifest.xml
- اگر
SKU
تعریف شده است،/odm/etc/manifest_ SKU .xml
-
/odm/etc/manifest.xml
- اگر
- مانیفست فروشنده HAL های مخصوص محصول را در پارتیشن فروشنده لیست می کند. شی VINTF مانیفست فروشنده را به ترتیب بارگیری می کند:
- اگر
SKU
تعریف شده باشد (که در آنSKU
مقدار ویژگیro.boot.product.vendor.sku
است)،/vendor/etc/vintf/manifest_ SKU .xml
-
/vendor/etc/vintf/manifest.xml
- اگر
- شی VINTF مانیفست دستگاه را به ترتیب بارگیری می کند:
- اگر مانیفست فروشنده وجود دارد، موارد زیر را ترکیب کنید:
- مانیفست فروشنده
- قطعات مانیفست فروشنده اختیاری
- مانیفست ODM اختیاری
- قطعات مانیفست ODM اختیاری
- در غیر این صورت، اگر مانیفست ODM وجود دارد، مانیفست ODM را با قطعات مانیفست ODM اختیاری ترکیب کنید.
-
/vendor/manifest.xml
(میراث، بدون قطعه) - در نهایت، قطعات مانیفست را از هر 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
: سوکت اینت
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
است.
- برای HIDL HAL، قالب
-
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
باشد. برای جزئیات بیشتر به قوانین تطبیق هسته مراجعه کنید.