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

کیت توسعه بومی فروشنده (VNDK) مجموعه‌ای از کتابخانه‌ها است که توسط سایر کتابخانه‌ها یا فایل‌های باینری، در پارتیشن فروشنده یا محصول، در زمان اجرا برای dlopen استفاده می‌شود. منسوخ شدن Vendor NDK در اندروید ۸.۰ معرفی شد تا رابط‌های برنامه‌نویسی (API) بین چارچوب و کد فروشنده را فراهم کند. اگرچه VNDK سال‌هاست که با موفقیت مورد استفاده قرار می‌گیرد، اما دارای برخی معایب است:

  • ذخیره‌سازی
    • یک VNDK APEX واحد، تمام کتابخانه‌های VNDK را، چه از دستگاه استفاده شوند و چه نشوند، در خود جای داده است.
    • GSI شامل نسخه‌های متعددی از VNDK APEXes است تا از نسخه‌های متعدد تصاویر فروشندگان پشتیبانی کند.
  • قابلیت به‌روزرسانی
    • به‌روزرسانی VNDK APEXها جدا از به‌روزرسانی پلتفرم، دشوار است.
    • ایمیج‌های فروشنده اغلب از طریق بی‌سیم (OTA) به‌روزرسانی می‌شوند و مزایای بسته‌بندی VNDK در ایمیج سیستم را کاهش می‌دهند.
بر اساس این مشکلات، تصمیم گرفتیم VNDK را از اندروید ۱۵ به بعد منسوخ کنیم. جزئیات مربوط به منسوخ شدن VNDK تمام کتابخانه‌های VNDK در VNDK APEX بسته‌بندی شده و در ایمیج سیستم (-ext) نصب می‌شوند. با منسوخ شدن VNDK، کتابخانه‌های VNDK قبلی در ایمیج فروشنده (یا محصول) نصب می‌شوند، مانند سایر کتابخانه‌های موجود در فروشنده. این ویژگی‌ها همراه با منسوخ شدن VNDK حذف می‌شوند:
  • VNDK APEX برای اندروید ۱۵
  • ویژگی‌های سیستمی که نسخه VNDK هدف را نشان می‌دهند، در صورتی که پارتیشن‌های فروشنده یا محصول برای اندروید ۱۵ ساخته شده باشند، حذف می‌شوند:
    • ro.vndk.version
    • ro.product.vndk.version
  • بهینه‌سازی‌های VNDK در دسترس نخواهند بود زیرا VNDK وجود ندارد:
    • TARGET_VNDK_USING_CORE_VARIANT برای دستگاه‌های اندروید گو
    • use_vndk_as_stable برای APEX های فروشنده
  • اسنپ‌شات فروشنده، که وابستگی زیادی به VNDK دارد
استثنائات از منسوخ شدن این ویژگی‌ها با منسوخ شدن VNDK تغییر نخواهند کرد:
  • APEX های VNDK با نسخه VNDK 14 یا پایین تر، که برای پشتیبانی از تصاویر فروشندگان موجود مورد نیاز هستند.
  • LL-NDK بخشی از VNDK نیست.
چرا VNDK؟

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

به‌روزرسانی‌های صرفاً چارچوبی شامل چالش‌های زیر هستند:

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

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

اصطلاحات خاص 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

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

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

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

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

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

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

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

  • کتابخانه‌های LL-NDK، کتابخانه‌های مشترک فریم‌ورک هستند که به پایداری معروفند. توسعه‌دهندگان آنها متعهد به حفظ پایداری API/ABI خود هستند.
    • 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) کتابخانه‌های مشترک فریم‌ورک هستند که به دسته‌های ذکر شده در بالا تعلق ندارند. این کتابخانه‌ها:
    • جزئیات پیاده‌سازی داخلی چارچوب در نظر گرفته می‌شوند.
    • نباید توسط ماژول‌های فروشنده قابل دسترسی باشد.
    • ABI/API ناپایدار دارند و هیچ تضمینی برای سازگاری API/ABI وجود ندارد.
    • کپی نمی‌شوند.
HAL با فرآیند یکسان (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ها توسط گوگل تعریف شده‌اند.

کتابخانه‌های زیر 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 (رندراسکریپت)
  • libmediandk.so (رندراسکریپت)
نسخه‌بندی 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)

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