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

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

منسوخ شدن

Vendor NDK در Android 8.0 برای ارائه API بین چارچوب و کد فروشنده معرفی شد. در حالی که VNDK سال هاست با موفقیت مورد استفاده قرار می گیرد، دارای معایبی است:
  • ذخیره سازی
    • یک VNDK APEX تمام کتابخانه های VNDK را بسته بندی می کند، خواه از دستگاه استفاده شده باشند یا نه.
    • GSI حاوی چندین نسخه از VNDK APEX ها برای پشتیبانی از چندین نسخه از تصاویر فروشنده است.
  • قابلیت به روز رسانی
    • به روز رسانی VNDK APEX ها جدا از به روز رسانی پلتفرم دشوار است.
    • تصاویر فروشنده اغلب از طریق هوا (OTA) به روز می شوند و از مزایای بسته بندی VNDK در تصویر سیستم می کاهد.
بر اساس این مسائل، تصمیم گرفتیم VNDK را با شروع اندروید 15 منسوخ کنیم.

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

تمام کتابخانه های VNDK در VNDK APEX بسته بندی شده و در تصویر سیستم (-ext) نصب می شوند. با منسوخ شدن VNDK، کتابخانه های قبلی VNDK در تصویر فروشنده (یا محصول) نصب می شوند، مانند سایر کتابخانه های موجود توسط فروشنده. این ویژگی ها همراه با منسوخ شدن VNDK حذف می شوند:
  • VNDK APEX برای اندروید 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 به‌روزرسانی‌های فقط چارچوب را می‌دهد که در آن پارتیشن سیستم را می‌توان به آخرین نسخه چارچوب ارتقا داد در حالی که پارتیشن فروشنده بدون تغییر باقی می‌ماند. با وجود اینکه در زمان‌های مختلف ساخته می‌شوند، باینری‌ها در هر پارتیشن باید بتوانند با یکدیگر کار کنند.

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

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

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

شرایط خاص VNDK

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

مفاهیم VNDK

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

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

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

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

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

  1. ABIs/APIهای کتابخانه های مشترک چارچوب را تثبیت کنید . ماژول‌های فریمورک جدید و ماژول‌های فروشنده قدیمی می‌توانند از یک کتابخانه مشترک برای کاهش ردپای حافظه و اندازه ذخیره‌سازی استفاده کنند. یک کتابخانه مشترک منحصر به فرد همچنین از چندین مشکل بارگذاری مضاعف جلوگیری می کند. با این حال، هزینه توسعه برای حفظ ABI/APIهای پایدار بالا است و تثبیت همه ABI/APIهای صادر شده توسط هر کتابخانه مشترک چارچوب غیر واقعی است.
  2. کتابخانه های مشترک چارچوب قدیمی را کپی کنید . همراه با محدودیت قوی در برابر کانال های جانبی، به عنوان همه مکانیسم ها برای برقراری ارتباط بین ماژول های چارچوب و ماژول های فروشنده، از جمله (اما نه محدود به) بایندر، سوکت، لوله، حافظه مشترک، فایل مشترک، و ویژگی های سیستم تعریف شده است. هیچ ارتباطی نباید وجود داشته باشد مگر اینکه پروتکل ارتباطی ثابت و ثابت باشد (به عنوان مثال 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)

Same-Process 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 vndk: { support_system_process: true } را در فایل‌های Android.bp خود مشخص می‌کنند. اگر 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 متکی هستند.