کیت توسعه بومی فروشنده (VNDK) به چندین تغییر در یک پایگاه کد نیاز دارد تا نگرانیهای بین فروشنده و سیستم را جدا کند. از راهنمای زیر برای فعال کردن VNDK در پایگاه کد فروشنده/OEM استفاده کنید.
ساخت کتابخانه های سیستمی
سیستم ساخت شامل چندین نوع شی از جمله کتابخانه ها (اشتراک گذاری شده، ایستا یا هدر) و باینری است.
شکل 1. ساخت کتابخانه های سیستم.
- کتابخانه های
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" } ... }
وقتی یک lib به عنوان vendor_available:true
علامت گذاری می شود، دو بار ساخته می شود:
- یک بار برای پلتفرم (و بنابراین در
/system/lib
نصب می شود) - یک بار برای فروشنده (و بنابراین در
/vendor/lib
یا VNDK APEX نصب می شود)
نسخههای فروشنده libs با -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
باشد، ممکن است به Google منتقل شود.
علاوه بر این، اگر یک مؤلفه 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
منتقل شد. برای مدیریت این هدرها یکی از موارد زیر را انجام دهید:
- در صورت امکان، وابستگی به
private/android_filesystem_config.h
را با جایگزین کردن همه ماکروهایAID_*
با تماسهایgetgrnam
/getpwnam
حذف کنید. به عنوان مثال:-
(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
را وارد کنید.