نمای کلی «کیت توسعه بومی فروشنده» (VNDK)

کیت توسعه بومی پیمانکاران (VNDK) مجموعه‌ای از کتابخانه‌ها است که توسط دیگر کتابخانه‌ها یا فایل‌های اجرایی در پارتیشن پیمانکار یا محصول در زمان اجرا برای dlopen استفاده می‌شود.

منسوخ شدن

NDK فروشنده در Android 8.0 معرفی شد تا APIهایی بین چارچوب و کد فروشنده ارائه دهد. اگرچه سال‌ها است که از VNDK با موفقیت استفاده می‌شود، اما این فناوری معایبی دارد:

• فضای ذخیره‌سازی
• یک VNDK APEX تکی همه کتابخانه‌های VNDK را بسته‌بندی می‌کند، چه از دستگاه استفاده شوند یا نه.
• GSI حاوی چندین نسخه از VNDK APEX است تا از چندین نسخه از تصاویر فروشنده پشتیبانی کند.
• قابلیت به‌روزشدن
• به‌روزرسانی جداگانه VNDK APEX از به‌روزرسانی پلاتفرم دشوار است.
• تصاویر فروشنده اغلب ازطریق هوا (OTA) به‌روزرسانی می‌شوند و مزایای بسته‌بندی VNDK در تصویر سیستم را کاهش می‌دهند.

براساس این مشکلات، تصمیم گرفتیم VNDK را از Android 15 منسوخ کنیم.

جزئیات درباره منسوخ شدن VNDK

همه کتابخانه‌های VNDK در VNDK APEX بسته‌بندی می‌شوند و در تصویر سیستم (-ext) نصب می‌شوند. با منسوخ شدن VNDK، کتابخانه‌های VNDK قبلی در تصویر فروشنده (یا محصول) نصب می‌شوند، همانند سایر کتابخانه‌های دردسترس فروشنده. این ویژگی‌ها همراه با منسوخ شدن VNDK برداشته می‌شوند:

• ‫VNDK APEX برای Android 15
• اگر پارتیشن‌های فروشنده یا محصول برای Android 15 ساخته شده باشند، دارایی‌های سیستم که نسخه VNDK هدف را نشان می‌دهند برداشته می‌شوند:
  • ro.vndk.version
  • ro.product.vndk.version
• بهینه‌سازی‌های VNDK دردسترس نخواهد بود زیرا VNDK وجود ندارد:
  • ‫TARGET_VNDK_USING_CORE_VARIANT برای دستگاه‌های Android Go
  • use_vndk_as_stable برای APEXهای فروشنده
• تصویر کلی فروشنده که به‌شدت به VNDK وابسته است

استثنائات مربوط به منسوخ شدن

این ویژگی‌ها با منسوخ شدن VNDK تغییر نخواهند کرد:

• ‫VNDK APEX با نسخه VNDK 14 یا پایین‌تر که برای پشتیبانی از تصاویر فروشنده موجود لازم است.
• ‫LL-NDK بخشی از VNDK نیست.

چرا VNDK؟

AOSP به‌روزرسانی‌های فقط چارچوب را مجاز می‌کند که در آن بخش سیستم می‌تواند به جدیدترین نسخه چارچوب ارتقا یابد، درحالی‌که بخش فروشنده بدون تغییر باقی می‌ماند. باوجود اینکه در زمان‌های مختلف ساخته شده‌اند، دودویی‌های هر بخش باید بتوانند با یکدیگر کار کنند.

به‌روزرسانی‌های فقط چارچوب شامل چالش‌های زیر است:

• وابستگی بین واحدهای چارچوب و واحدهای فروشنده. قبل‌از Android 8.0، واحدها در پارتیشن فروشنده و سیستم می‌توانستند با یکدیگر پیوند برقرار کنند. بااین‌حال، وابستگی‌های پیمانه‌های فروشنده محدودیت‌های ناخواسته‌ای را بر توسعه پیمانه‌های چارچوب تحمیل می‌کرد.
• افزونه‌های کتابخانه‌های AOSP. Android همه دستگاه‌های Android را ملزم می‌کند که وقتی بخش سیستم با «تصویر سیستم عمومی» (GSI) استاندارد جایگزین می‌شود، «مجموعه آزمون سازگاری» را بگذرانند. بااین‌حال، ازآنجایی‌که فروشندگان کتابخانه‌های AOSP را برای تقویت عملکرد یا افزودن قابلیت‌های اضافی به پیاده‌سازی‌های HIDL خود گسترش می‌دهند، فلش کردن پارتیشن سیستم با GSI استاندارد ممکن است پیاده‌سازی HIDL فروشنده را مختل کند. برای دستورالعمل‌های مربوط به جلوگیری از چنین خرابی‌هایی، به افزونه‌های VNDK مراجعه کنید.

برای پرداختن به این چالش‌ها، Android شامل چندین ویژگی مانند VNDK (توضیح داده‌شده در این بخش)، HIDL، hwbinder، رونهاد درخت دستگاه، و رونهاد sepolicy است.

اصطلاحات خاص VNDK

اسناد مربوط به VNDK از اصطلاحات زیر استفاده می‌کنند:

• واحدها به کتابخانه‌های مشترک یا فایل‌های اجرایی اشاره دارند. پیمانه‌ها وابستگی‌های زمان ساخت ایجاد می‌کنند.
• فرایندها وظایف سیستم‌عامل هستند که از فایل‌های اجرایی ایجاد می‌شوند. فرایندها وابستگی‌های زمان اجرا ایجاد می‌کنند.
• عبارت‌های واجدشرایط چارچوب به بخش system مربوط می‌شوند:
• اجرایی‌های چارچوب به اجرایی‌های موجود در /system/bin یا /system/xbin اشاره دارد.
• کتابخانه‌های مشترک چارچوب به کتابخانه‌های مشترک تحت /system/lib[64] اشاره دارد.
• مدول‌های چارچوب به کتابخانه‌های مشترک چارچوب و فایل‌های اجرایی چارچوب اشاره دارد.
• فرایندهای چارچوب فرایندهایی هستند که از فایل‌های اجرایی چارچوب، مانند /system/bin/app_process، منشعب می‌شوند.
• عبارت‌های واجدشرایط فروشنده مربوط به vendor بخش است:
• فایل‌های اجرایی فروشنده به فایل‌های اجرایی در /vendor/bin اشاره دارد
• کتابخانه‌های مشترک فروشنده به کتابخانه‌های مشترک تحت /vendor/lib[64] اشاره دارد.
• واحدهای فروشنده به هر دو فایل اجرایی فروشنده و کتابخانه‌های مشترک فروشنده اشاره دارد.
• فرایندهای فروشنده فرایندهایی هستند که از «فایل‌های اجرایی فروشنده» مانند /vendor/bin/android.hardware.camera.provider@2.4-service منشعب می‌شوند.

مفاهیم VNDK

در دنیای ایده‌آل Android 8.0 و بالاتر، فرایندهای چارچوب، کتابخانه‌های مشترک فروشنده را بار نمی‌کنند، همه فرایندهای فروشنده فقط کتابخانه‌های مشترک فروشنده (و بخشی از کتابخانه‌های مشترک چارچوب) را بار می‌کنند، و ارتباطات بین فرایندهای چارچوب و فرایندهای فروشنده توسط HIDL و بایندر سخت‌افزار کنترل می‌شود.

چنین دنیایی شامل این امکان است که میاناهای برنامه‌سازی کاربردی عمومی و پایدار از کتابخانه‌های مشترک چارچوب ممکن است برای توسعه‌دهندگان واحد فروشنده کافی نباشد (اگرچه میاناهای برنامه‌سازی کاربردی می‌توانند بین نسخه‌های Android تغییر کنند)، و لازم است بخشی از کتابخانه‌های مشترک چارچوب برای فرایندهای فروشنده دردسترس باشد. علاوه‌براین، ازآنجایی‌که الزامات عملکرد می‌تواند منجر به مصالحه شود، برخی‌از HALهای حساس به زمان پاسخ باید به‌صورت متفاوت مدیریت شوند.

بخش‌های زیر جزئیات نحوه مدیریت کتابخانه‌های مشترک چارچوب توسط VNDK برای فروشندگان و «لایه انتزاع سخت‌افزار هم‌روند» (SP-HAL) را شرح می‌دهد.

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

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

1. پایدار کردن ABI/API کتابخانه‌های مشترک چارچوب. واحدهای چارچوب جدید و واحدهای فروشنده قدیمی می‌توانند از کتابخانه مشترک یکسانی برای کاهش ردپای حافظه و اندازه فضای ذخیره‌سازی استفاده کنند. کتابخانه مشترک یکتا همچنین از چندین مشکل بارگیری مضاعف جلوگیری می‌کند. بااین‌حال، هزینه توسعه برای حفظ پایداری ABI/API بالا است و پایدار کردن همه ABI/API صادرشده توسط هر کتابخانه مشترک چارچوب غیرواقعی است.
2. کپی کردن کتابخانه‌های مشترک چارچوب قدیمی. با محدودیت شدید دربرابر کانال‌های جانبی ارائه می‌شود که به‌عنوان همه سازوکارهای ارتباطی بین ماژول‌های چارچوب و ماژول‌های فروشنده تعریف شده‌اند، ازجمله (اما نه محدود به) binder، سوکت، لوله، حافظه مشترک، فایل مشترک، و ویژگی‌های سیستم. نباید هیچ ارتباطی وجود داشته باشد، مگراینکه پروتکل ارتباطی ثابت و پایدار باشد (برای نمونه، HIDL ازطریق hwbinder). بار کردن دوگانه کتابخانه‌های مشترک نیز ممکن است مشکلاتی ایجاد کند؛ برای مثال، اگر شیء ایجادشده توسط کتابخانه جدید به توابع کتابخانه قدیمی منتقل شود، ممکن است خطایی رخ دهد زیرا این کتابخانه‌ها ممکن است شیء را به‌طور متفاوتی تفسیر کنند.

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

• کتابخانه‌های LL-NDK کتابخانه‌های مشترک چارچوب هستند که به‌عنوان کتابخانه‌های پایدار شناخته می‌شوند. توسعه‌دهندگان آن‌ها متعهد به حفظ ثبات میانای برنامه‌سازی کاربردی/میانای برنامه‌سازی کاربردی باینری هستند.
  • ‫LL-NDK شامل کتابخانه‌های زیر است: libEGL.so،‏ libGLESv1_CM.so، libGLESv2.so،‏ libGLESv3.so، libandroid_net.so،‏ libc.so،‏ libdl.so، liblog.so،‏ libm.so،‏ libnativewindow.so، libneuralnetworks.so،‏ libsync.so، libvndksupport.so، و libvulkan.so،
• کتابخانه‌های VNDK واجدشرایط (VNDK) کتابخانه‌های مشترک چارچوب هستند که کپی کردن آن‌ها دو بار ایمن است. واحد چارچوب و واحد فروشنده می‌توانند با نسخه‌های خودشان پیوند برقرار کنند. کتابخانه چارچوب مشترک فقط درصورتی می‌تواند به کتابخانه VNDK واجدشرایط تبدیل شود که معیارهای زیر را برآورده کند:
  • این سرویس IPC را به/از چارچوب ارسال/دریافت نمی‌کند.
  • این خطا به ماشین مجازی ART مربوط نیست.
  • فایل‌ها/پارتیشن‌ها را با قالب‌های فایل ناپایدار نمی‌خواند/نمی‌نویسد.
  • این محتوا پروانه نرم‌افزار ویژه که نیاز به بررسی‌های قانونی داشته باشد ندارد.
  • مالک کد آن اعتراضی به استفاده‌های فروشنده ندارد.
• کتابخانه‌های فقط چارچوب (FWK-ONLY) کتابخانه‌های مشترک چارچوب هستند که به دسته‌های ذکرشده در بالا تعلق ندارند. این کتابخانه‌ها:
  • جزئیات پیاده‌سازی داخلی چارچوب درنظر گرفته می‌شوند.
  • نباید توسط واحدهای فروشنده قابل‌دسترسی باشد.
  • دارای میاناهای برنامه‌سازی کاربردی (API) و میاناهای دودویی برنامه (ABI) ناپایدار هستند و هیچ تضمینی برای سازگاری API/ABI وجود ندارد.
  • کپی نمی‌شوند.

لایه انتزاع سخت‌افزار هم‌فرایندی (SP-HAL)

HAL هم‌فرایندی (SP-HAL) مجموعه‌ای از HALهای ازپیش تعیین‌شده است که به‌عنوان کتابخانه‌های مشترک فروشنده پیاده‌سازی شده‌اند و در فرایندهای چارچوب بار می‌شوند. ‫SP-HALها توسط فضای نام پیونددهنده جدا می‌شوند (کتابخانه‌ها و نشان‌هایی را که برای کتابخانه‌های مشترک نمایان هستند کنترل می‌کند). SP-HALها باید فقط به LL-NDK و VNDK-SP وابسته باشند.

‫VNDK-SP زیرمجموعه‌ای ازپیش‌تعریف‌شده از کتابخانه‌های واجدشرایط VNDK است. کتابخانه‌های VNDK-SP به‌دقت بازبینی می‌شوند تا اطمینان حاصل شود که بار کردن دوگانه کتابخانه‌های VNDK-SP در فرایندهای چارچوب مشکلی ایجاد نمی‌کند. هم SP-HAL و هم VNDK-SP توسط Google تعریف می‌شوند.

کتابخانه‌های زیر SP-HAL تأییدشده هستند:

• libGLESv1_CM_${driver}.so
• libGLESv2_${driver}.so
• libGLESv3_${driver}.so
• libEGL_${driver}.so
• vulkan.${driver}.so
• android.hardware.renderscript@1.0-impl.so
• android.hardware.graphics.mapper@2.0-impl.so

کتابخانه‌های VNDK-SP در فایل‌های Android.bp خود vndk: { support_system_process: true } را مشخص می‌کنند. اگر vndk: {private:true} نیز مشخص شده باشد، این کتابخانه‌ها VNDK-SP-Private نامیده می‌شوند و برای SP-HALS نامرئی هستند.

موارد زیر کتابخانه‌های فقط چارچوب با استثناهای RS (FWK-ONLY-RS) هستند:

• ‫libft2.so (Renderscript)
• ‫libmediandk.so (Renderscript)

نسخه‌بندی VNDK

کتابخانه‌های مشترک VNDK نسخه‌بندی شده‌اند:

• ویژگی سیستم ro.vndk.version به‌طور خودکار به /vendor/default.prop اضافه می‌شود.
• کتابخانه‌های مشترک VNDK و VNDK-SP به‌عنوان VNDK apex com.android.vndk.v${ro.vndk.version} نصب می‌شوند و به /apex/com.android.vndk.v${ro.vndk.version} نصب می‌شوند.

مقدار ro.vndk.version توسط الگوریتم زیر انتخاب می‌شود:

• اگر BOARD_VNDK_VERSION برابر با current نیست، از BOARD_VNDK_VERSION استفاده کنید.
• اگر BOARD_VNDK_VERSION برابر با current باشد:
• اگر PLATFORM_VERSION_CODENAME REL است، از PLATFORM_SDK_VERSION (برای نمونه 28) استفاده کنید.
• درغیراین‌صورت، از PLATFORM_VERSION_CODENAME استفاده کنید (مثلاً P).

مجموعه آزمون فروشنده (VTS)

«مجموعه آزمایش فروشنده Android» (VTS) الزام می‌کند که دارایی ro.vndk.version غیرخالی باشد. هر دو دستگاه‌های تازه راه‌اندازی‌شده و دستگاه‌های ارتقایافته باید ro.vndk.version را تعریف کنند. برخی‌از موارد آزمون VNDK (برای نمونه VtsVndkFilesTest و VtsVndkDependencyTest) برای بار کردن مجموعه‌های داده کتابخانه‌های VNDK واجدشرایط منطبق به دارایی ro.vndk.version متکی هستند.