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

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

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

چرا VNDK؟

Android 8.0 و بالاتر به‌روزرسانی‌های چارچوبی را فعال می‌کند که در آن پارتیشن سیستم را می‌توان به آخرین نسخه ارتقا داد در حالی که پارتیشن‌های فروشنده بدون تغییر باقی می‌مانند. این بدان معناست که باینری های ساخته شده در زمان های مختلف باید بتوانند با یکدیگر کار کنند. VNDK تغییرات API/ABI را در نسخه‌های اندروید پوشش می‌دهد.

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

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

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

منابع VNDK

این بخش شامل منابع VNDK زیر است:

  • مفاهیم VNDK (در زیر) کتابخانه‌های مشترک چارچوب، HAL‌های یک فرآیند (SP-HALs) و اصطلاحات VNDK را توصیف می‌کند.
  • برنامه های افزودنی VNDK تغییرات خاص فروشنده را به دسته ها طبقه بندی می کند. به عنوان مثال، کتابخانه‌هایی با قابلیت‌های توسعه‌یافته که ماژول‌های فروشنده بر آن‌ها تکیه دارند، باید در پارتیشن فروشنده کپی شوند، اما تغییرات ناسازگار با ABI ممنوع هستند.
  • VNDK Build System Support پیکربندی های سیستم ساخت و نحوهای تعریف ماژول را که به VNDK مربوط می شوند را توصیف می کند.
  • ابزار تعریف VNDK به انتقال درخت منبع شما به اندروید 8.0 و بالاتر کمک می کند.
  • Linker Namespace کنترل دقیقی بر پیوندهای کتابخانه مشترک فراهم می کند.
  • فهرست راهنماها، قوانین، و سیاست ساختار فهرست راهنمای دستگاه‌های دارای Android نسخه 8.0 و بالاتر، قوانین VNDK و قوانین مرتبط با آن را تعریف می‌کند.
  • ارائه طراحی VNDK مفاهیم اساسی VDNK مورد استفاده در اندروید 8.0 و بالاتر را نشان می دهد.

مفاهیم VNDK

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

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

بخش‌های زیر نحوه مدیریت کتابخانه‌های به اشتراک‌گذاشته‌شده چارچوب را برای فروشندگان و 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 خود مشخص می‌کنند. اگر vendor_available: false نیز مشخص شده باشد، این کتابخانه ها VNDK-SP-Private نامیده می شوند و برای SP-HALS نامرئی هستند.

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

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

اصطلاحات VNDK

  • ماژول ها به کتابخانه های مشترک یا فایل های اجرایی اشاره دارند.
  • فرآیندها وظایف سیستم عامل هستند که از Executable ها ایجاد می شوند.
  • اصطلاحات واجد شرایط چارچوب به مفاهیم مربوط به پارتیشن سیستم اشاره دارد.
  • اصطلاحات واجد شرایط فروشنده به مفاهیم مربوط به پارتیشن های فروشنده اشاره دارد.

مثلا:

  • Framework Executable ها به فایل های اجرایی در /system/bin یا /system/xbin اطلاق می شود.
  • Framework Shared Libraries به کتابخانه های مشترک تحت /system/lib[64] اشاره دارد.
  • ماژول های چارچوب هم به کتابخانه های مشترک چارچوب و هم به فایل های اجرایی چارچوب اشاره دارند.
  • فرآيندهاي چارچوب، فرآيندهايي هستند كه از فايلهاي اجرايي چارچوب (به عنوان مثال /system/bin/app_process ) ايجاد مي شوند.
  • فایل های اجرایی Vendor به فایل های اجرایی در /vendor/bin اشاره دارد
  • کتابخانه های اشتراکی فروشنده به کتابخانه های مشترک در زیر /vendor/lib[64] اشاره دارد.
  • ماژول های فروشنده هم به فایل های اجرایی فروشنده و هم به کتابخانه های اشتراکی فروشنده اشاره می کنند.
  • فرآیندهای فروشنده، فرآیندهایی هستند که از فایل های اجرایی فروشنده (مثلاً
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

نسخه VNDK

در اندروید 9، کتابخانه های مشترک VNDK نسخه شده است:

  • ویژگی ro.vndk.version سیستم به طور خودکار به /vendor/default.prop اضافه می شود.
  • کتابخانه های مشترک VNDK در /system/lib[64]/vndk-${ro.vndk.version} نصب می شوند.
  • کتابخانه های مشترک VNDK-SP در /system/lib[64]/vndk-sp-${ro.vndk.version} نصب می شوند.
  • فایل پیکربندی پیوند دهنده پویا در /system/etc/ld.config.${ro.vndk.version}.txt نصب شده است.

مقدار 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 ) استفاده کنید.

ارتقاء دستگاه ها

اگر دستگاه Android 8.x با ساخت بدون BOARD_VNDK_VERSION ، اجرای زمان اجرا VNDK را غیرفعال کرد، ممکن است PRODUCT_USE_VNDK_OVERRIDE := false را در حین ارتقا به Android 9 به BoardConfig.mk اضافه کند.

اگر PRODUCT_USE_VNDK_OVERRIDE false ، ویژگی ro.vndk.lite به طور خودکار به /vendor/default.prop اضافه می شود و مقدار آن true خواهد بود. در نتیجه، پیوند دهنده پویا پیکربندی فضای نام پیوند دهنده را از /system/etc/ld.config.vndk_lite.txt بارگیری می کند، که فقط SP-HAL و VNDK-SP را ایزوله می کند.

برای ارتقاء دستگاه Android 7.0 یا پایین تر به Android 9، PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false را به BoardConfig.mk کنید.

مجموعه تست فروشنده (VTS)

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

اگر ویژگی ro.product.first_api_level بزرگتر از 27 باشد، ویژگی ro.vndk.lite نباید تعریف شود. اگر VtsTreblePlatformVersionTest در دستگاه اندروید 9 تازه راه اندازی شده تعریف شود، ro.vndk.lite ناموفق خواهد بود.

تاریخچه سند

این بخش تغییرات اسناد VNDK را دنبال می کند.

تغییرات اندروید 9

  • بخش نسخه‌سازی VNDK را اضافه کنید.
  • اضافه کردن بخش VTS
  • برخی از دسته های VNDK تغییر نام داده اند:
    • LL-NDK-Indirect به LL-NDK-Private تغییر نام داده است.
    • VNDK-Indirect به VNDK-Private تغییر نام داده است.
    • VNDK-SP-Indirect-Private به VNDK-SP-Private تغییر نام داده است.
    • VNDK-SP-Indirect حذف شده است.

تغییرات اندروید 8.1

  • کتابخانه های SP-NDK در کتابخانه های LL-NDK ادغام شده اند.
  • در قسمت namespace RS، libft2.so را با libui.so جایگزین کنید. libui.so یک خطا بود.
  • libGLESv3.so و libandroid_net.so را به کتابخانه های LL-NDK اضافه کنید.
  • libion.so را به کتابخانه های VNDK-SP اضافه کنید.
  • libstdc++.so از کتابخانه های LL-NDK حذف کنید. به جای آن از libc++.so استفاده کنید. برخی از نسخه‌های زنجیره‌های ابزار مستقل ممکن است -lstdc++ را به پرچم‌های پیوند دهنده پیش‌فرض اضافه کنند. برای غیرفعال کردن پیش‌فرض‌ها، -nodefaultlibs -lc -lm -ldl را به LDFLAGS اضافه کنید.
  • libz.so از LL-NDK به کتابخانه های VNDK-SP منتقل کنید. در برخی از تنظیمات، libz.so ممکن است همچنان LL-NDK باشد. با این حال، هیچ تفاوت قابل مشاهده ای نباید وجود داشته باشد.