کیت توسعه بومی فروشنده (VNDK) برای تفکیک دغدغههای بین فروشنده و سیستم، نیاز به چندین تغییر در کدبیس دارد. از راهنمای زیر برای فعالسازی VNDK در کدبیس فروشنده/OEM استفاده کنید.
ساخت کتابخانههای سیستم
سیستم ساخت شامل انواع مختلفی از اشیاء از جمله کتابخانهها (مشترک، استاتیک یا هدر) و فایلهای باینری است.

شکل ۱. ساخت کتابخانههای سیستم.
- کتابخانههای
coreتوسط تصویر سیستم، روی تصویر سیستم، استفاده میشوند. این کتابخانهها نمیتوانند توسط کتابخانههایvendor،vendor_available،vndkیاvndk-spاستفاده شوند.cc_library { name: "libThatIsCore", ... }
- کتابخانههای
vendor-only(یاproprietary) توسط تصویر فروشنده، روی تصویر فروشنده، استفاده میشوند.cc_library { name: "libThatIsVendorOnly", proprietary: true, # or: vendor: true, # (for things in AOSP) ... }
- کتابخانههای
vendor_availableتوسط تصویر فروشنده، روی تصویر فروشنده (ممکن است حاوی نسخههای تکراری ازcoreباشد) استفاده میشوند.cc_library { name: "libThatIsVendorAvailable", vendor_available: true, ... }
- کتابخانههای
vndkتوسط ایمیج فروشنده، روی ایمیج سیستم، استفاده میشوند.cc_library { name: "libThatIsVndk", vendor_available: true, vndk: { enabled: true, } ... }
- کتابخانههای
vndk-spتوسط ایمیج فروشنده و همچنین به طور غیرمستقیم توسط ایمیج سیستم استفاده میشوند.cc_library { name: "libThatIsVndkSp", vendor_available: true, vndk: { enabled: true, support_system_process: true, } ... }
- کتابخانههای
llndkهم توسط سیستم و هم توسط ایمیجهای فروشنده استفاده میشوند.cc_library { name: "libThatIsLlndk", llndk: { symbol_file: "libthatisllndk.map.txt" } ... }
وقتی یک کتابخانه به صورت vendor_available:true علامتگذاری میشود، دو بار ساخته میشود:
- یک بار برای پلتفرم (و بنابراین در
/system/libنصب شد) - یک بار برای فروشنده (و بنابراین در
/vendor/libیا VNDK APEX نصب میشود)
نسخههای فروشندهی کتابخانهها با -D__ANDROID_VNDK__ ساخته شدهاند. اجزای سیستم خصوصی که ممکن است در نسخههای آیندهی اندروید به طور قابل توجهی تغییر کنند، با این پرچم غیرفعال میشوند. علاوه بر این، کتابخانههای مختلف مجموعهی متفاوتی از هدرها را صادر میکنند (مانند liblog ). گزینههای خاص برای یک نوع فروشنده از یک هدف را میتوان در یک فایل Android.bp در مسیر زیر مشخص کرد:
target: { vendor: { … } }فعال کردن VNDK برای یک کدبیس
برای فعال کردن VNDK برای یک کدبیس:
- با محاسبه اندازههای مورد نیاز پارتیشنهای
vendor.imgوsystem.img، واجد شرایط بودن را تعیین کنید. - فعال کردن
BOARD_VNDK_VERSION=current. میتوانید بهBoardConfig.mkاضافه کنید یا مستقیماً با آن کامپوننت بسازید (برای مثال،m -j BOARD_VNDK_VERSION=current MY-LIB).
پس از فعال کردن BOARD_VNDK_VERSION=current ، سیستم ساخت، الزامات وابستگی و هدر زیر را اعمال میکند.
مدیریت وابستگیها
یک شیء vendor که به یک جزء core وابسته است که در vndk یا به عنوان یک شیء vendor وجود ندارد، باید با استفاده از یکی از گزینههای زیر حل شود:
- وابستگی را میتوان از بین برد.
- اگر کامپوننت
coreمتعلق بهvendorباشد، میتواند به صورتvendor_availableیاvendorعلامتگذاری شود. - تغییری که شیء اصلی را به بخشی از
vndkتبدیل میکند، ممکن است به گوگل اطلاع داده شود.
علاوه بر این، اگر یک کامپوننت core به یک کامپوننت vendor وابستگی داشته باشد، کامپوننت vendor باید به یک کامپوننت core تبدیل شود یا وابستگی باید به روش دیگری حذف شود (مثلاً با حذف وابستگی یا با انتقال وابستگی به یک کامپوننت vendor ).
مدیریت سربرگها
وابستگیهای سراسری سرآیند باید حذف شوند تا سیستم ساخت بتواند تشخیص دهد که آیا سرآیندها را با -D__ANDROID_VNDK__ بسازد یا بدون آن. برای مثال، سرآیندهای libutils مانند utils/StrongPointer.h همچنان میتوانند با استفاده از کتابخانه سرآیند libutils_headers قابل دسترسی باشند.
برخی از هدرها (مانند unistd.h ) دیگر نمیتوانند به صورت انتقالی گنجانده شوند، اما میتوانند به صورت محلی گنجانده شوند.
در نهایت، بخش عمومی private/android_filesystem_config.h به cutils/android_filesystem_config.h منتقل شده است. برای مدیریت این هدرها، یکی از موارد زیر را انجام دهید:
- در صورت امکان، با جایگزینی تمام ماکروهای
AID_*با فراخوانیهایgetgrnam/getpwnam، وابستگی بهprivate/android_filesystem_config.hرا حذف کنید. برای مثال:-
(uid_t)AID_WIFIتبدیل میشود بهgetpwnam("wifi")->pw_uid. -
(gid_t)AID_SDCARD_Rتبدیل میشود بهgetgrnam("sdcard_r")->gr_gid.
private/android_filesystem_config.hمراجعه کنید. -
- برای AIS با کدنویسی سخت،
cutils/android_filesystem_config.hرا اضافه کنید.