يتطلب 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" } ... }
عندما يتم وضع علامة على lib على أنه vendor_available:true
، يتم إنشاؤه مرتين:
- مرة واحدة للنظام الأساسي (وبالتالي تم تثبيته على
/system/lib
) - مرة واحدة للبائع (وبالتالي تم تثبيته على
/vendor/lib
أو VNDK APEX)
تم إنشاء إصدارات البائعين من libs باستخدام -D__ANDROID_VNDK__
. يتم تعطيل مكونات النظام الخاصة التي قد تتغير بشكل كبير في الإصدارات المستقبلية من Android باستخدام هذه العلامة. بالإضافة إلى ذلك، تقوم المكتبات المختلفة بتصدير مجموعة مختلفة من الرؤوس (مثل 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
.