حزمة تطوير البرامج الأصلية للمورّدين (VNDK) هي مجموعة من المكتبات التي تستخدمها المكتبات أو البرامج الثنائية الأخرى في قسم المنتج أو المورّد في وقت تشغيل dlopen.
الإيقاف النهائي
تم طرح حزمة NDK الخاصة بالمطوّرين في الإصدار 8.0 من Android لتوفير واجهات برمجة تطبيقات بين الإطار الأساسي ورمز المطوّر. على الرغم من أنّه تم استخدام حزمة VNDK بنجاح لعدة سنوات، إلا أنّ لها بعض العيوب:- مساحة التخزين
- حزمة VNDK APEX واحدة تضم جميع مكتبات VNDK، سواء كانت مستخدَمة من الجهاز أم لا.
- يحتوي GSI على إصدارات متعددة من VNDK APEXes للتوافق مع إصدارات متعددة من صور المصنّعين.
- قابلية التعديل
- من الصعب تحديث حِزم VNDK APEX بشكل منفصل عن تحديث النظام الأساسي.
- يتم تحديث صور المورّدين بشكل متكرّر عبر شبكة غير سلكية (OTA)، ما يقلل من مزايا توفّر حِزمة VNDK ضمن صورة النظام.
تفاصيل حول إيقاف VNDK نهائيًا
يتم تجميع جميع مكتبات VNDK في حزمة VNDK APEX، ويتم تثبيتها في صورة النظام (-ext). مع إيقاف حزمة VNDK نهائيًا، يتم تثبيت مكتبات VNDK السابقة في صورة المورّد (أو المنتج)، تمامًا مثل المكتبات الأخرى المتاحة للمورّد. تتم إزالة هذه الميزات مع إيقاف استخدام حزمة تطوير البرامج (VNDK) نهائيًا:- حزمة VNDK APEX لنظام التشغيل Android 15
- تتم إزالة سمات النظام التي تشير إلى إصدار حزمة VNDK المستهدَفة إذا تم إنشاء أقسام المورّد أو المنتج لنظام التشغيل Android 15:
ro.vndk.version
ro.product.vndk.version
- لن تتوفّر تحسينات مجموعة تطوير البرامج الأصلية للمورّدين (VNDK) بسبب عدم توفّر مجموعة تطوير البرامج الأصلية للمورّدين:
TARGET_VNDK_USING_CORE_VARIANT
لأجهزة Android Gouse_vndk_as_stable
لبرامج APEX الخاصة بالمورّدين
- لقطة المورّد التي تعتمد بشكل كبير على حزمة تطوير البرامج (VNDK)
استثناءات من الإيقاف النهائي
لن تتغيّر الميزات التالية عند إيقاف VNDK نهائيًا:- حِزم VNDK ذات الإصدار 14 من VNDK أو الإصدارات الأقدم، والمطلوبة لإتاحة صور المورّدين الحاليين
- لا يُعدّ LL-NDK جزءًا من VNDK.
ما سبب اختيار شركة VNDK؟
يتيح AOSP إجراء تحديثات إطار العمل فقط التي يمكن من خلالها ترقية قسم النظام إلى أحدث إصدار من إطار العمل مع عدم تغيير قسم المورِّد. على الرغم من أنّه يتم إنشاء الملفات الثنائية في كل قسم في أوقات مختلفة، يجب أن تكون قادرة على العمل مع بعضها.
تشمل التحديثات المتعلقة بالإطار فقط التحديات التالية:
- الاعتماد بين وحدات إطار العمل ووحدات المورّدين قبل الإصدار 8.0 من Android، كان بإمكان الوحدات في قسمَي المورّد والنظام الربط ببعضها. ومع ذلك، فرضت التبعيات من وحدات الموردين قيودًا غير مرغوب فيها على تطوير وحدات إطار العمل.
- الإضافات إلى مكتبات AOSP يتطلب نظام Android اجتياز جميع أجهزة Android لاختبار CTS عند استبدال قسم النظام بصورة نظام عامة عادية (GSI). ومع ذلك، عندما يُضيف المصنّعون مكتبات AOSP لتعزيز الأداء أو لإضافة وظائف إضافية لعمليات تنفيذ HIDL ، قد يؤدي فلاش قسم النظام باستخدام ملف GSI عادي إلى إيقاف تنفيذ HIDL لدى المصنّع. للحصول على إرشادات حول تجنُّب حدوث هذه الأعطال، يُرجى الاطّلاع على إضافات VNDK.
لمواجهة هذه التحديات، يحتوي Android على عدة ميزات، مثل VNDK (الموضّح في هذا القسم)، HIDL وhwbinder، تداخل شجرة الجهاز، وتداخل سياسة الأمان.
البنود الخاصة بـ VNDK
تستخدم المستندات ذات الصلة بـ VNDK المصطلحات التالية:- تشير الوحدات إلى المكتبات المشتركة أو الملفات التنفيذية. تُنشئ الوحدات تبعيات أثناء وقت الإنشاء.
- العمليات هي مهام نظام التشغيل التي يتم إنشاؤها من ملفات تنفيذية. تُنشئ العمليات تبعيات وقت التشغيل.
- ترتبط المصطلحات المؤهَّلة للإطار بتقسيم
system
: - تشير ملفّات Framework التنفيذية إلى الملفّات التنفيذية في
/system/bin
أو/system/xbin
. - تشير المكتبات المشتركة للإطار إلى المكتبات المشتركة ضمن
/system/lib[64]
. - تشير وحدات إطار العمل إلى كلّ من مكتبات إطار العمل المشترَكة وملفات إطار العمل القابلة للتنفيذ.
- عمليات إطار العمل هي عمليات يتم إنشاؤها من ملفات executible الخاصة بإطار العمل، مثل
/system/bin/app_process
. - ترتبط الأحكام المؤهّلة للمورّد بفواصل
vendor
: - تشير ملفّات التشغيل الخاصة بالمورّد إلى ملفات التشغيل في
/vendor/bin
- تشير المكتبات المشتركة الخاصة بالمورّدين إلى المكتبات المشتركة ضمن
/vendor/lib[64]
. - تشير وحدات المورّدين إلى كلّ من ملفات التشغيل الخاصة بالمورّدين والمكتبات المشتركة الخاصة بالمورّدين.
- عمليات المورّد هي عمليات تنشأ من "الملفات التنفيذية للمورّدين"، مثل
/vendor/bin/android.hardware.camera.provider@2.4-service
.
مفاهيم VNDK
في الإصدار المثالي من Android 8.0 والإصدارات الأحدث، لا تحمِّل عمليات إطار العمل المكتبات المشتركة الخاصة بالمورّدين، ولا تحمِّل جميع عمليات المورّدين سوى المكتبات المشتركة الخاصة بالمورّدين (وجزء من المكتبات المشتركة لإطار العمل)، ويخضع التواصل بين عمليات إطار العمل وعمليات المورّدين لـ HIDL ومكتبة ربط الأجهزة.
ويشمل هذا العالم إمكانية أن تكون واجهات برمجة التطبيقات العلنية والثابتة من مكتبات الإطارات المشترَكة قد لا تكون كافية لمطوّري وحدات المورّدين (على الرغم من أنّ واجهات برمجة التطبيقات يمكن أن تتغيّر بين إصدارات Android)، ما يتطلّب أن يكون جزءًا من مكتبات الإطارات المشترَكة متاحًا لعمليات المورّدين. بالإضافة إلى ذلك، وبما أنّ متطلبات الأداء قد تؤدي إلى مشاكل، يجب التعامل مع بعض أنواع HALs الحرجة في وقت الاستجابة على نحو مختلف.
توضِّح الأقسام التالية بالتفصيل كيفية تعامل حزمة VNDK مع المكتبات المشتركة للإطار الأساسي لأجل المورّدين وواجهات برمجة التطبيقات لوحدة HAL في العملية نفسها (SP-HAL).
المكتبات المشتركة للإطار الأساسي للمورّد
يصف هذا القسم معايير تصنيف المكتبات المشتركة التي يمكن لعمليات المورّدين الوصول إليها. هناك طريقتان لدعم وحدات البائعين عبر إصدارات Android المتعددة:
- استقرار واجهات برمجة التطبيقات أو واجهات برمجة التطبيقات لنظام التشغيل لإطار العمل المشترَك يمكن أن تستخدم وحدات إطار العمل الجديدة ووحدات المورّدين القديمة المكتبة المشتركة نفسها لمحاولة تقليل مساحة الذاكرة وحجم مساحة التخزين. وتتجنّب المكتبة المشتركة الفريدة أيضًا العديد من مشاكل التحميل المزدوج. ومع ذلك، فإنّ تكلفة التطوير للحفاظ على ثبات IDE/واجهات برمجة التطبيقات مرتفعة، ومن غير الواقعي ضمان ثبات جميع IDE/واجهات برمجة التطبيقات التي يتم تصديرها من IDE/كل مكتبة مشترَكة للإطار.
- نسخ المكتبات المشتركة لإطار العمل القديم ينطبق عليه قيد قوي ضد القنوات الجانبية، والتي يتم تعريفها على أنّها جميع آليات التواصل بين وحدات إطار العمل ووحدات المورّدين، بما في ذلك (على سبيل المثال لا الحصر) الرابط ووحدة الجلسة وقناة النقل والذاكرة المشتركة والملف المشترَك وخصائص النظام. يجب عدم السماح بالاتصال إلا إذا كان بروتوكول الاتصال مجمّدًا ومستقرًا (مثل HIDL من خلال hwbinder). قد يؤدي التحميل المزدوج للمكتبات المشتركة إلى حدوث مشاكل أيضًا؛ فعلى سبيل المثال، إذا تم تمرير كائن أنشأته المكتبة الجديدة إلى الدوال من المكتبة القديمة، فقد يحدث خطأ حيث قد تفسّر هذه المكتبات الكائن بشكل مختلف.
يتم استخدام طرق مختلفة استنادًا إلى خصائص مكتبات المشترَكة. ونتيجةً لذلك، يتم تصنيف المكتبات المشتركة للإطارات في ثلاث فئات فرعية:
- مكتبات LL-NDK هي مكتبات إطار عمل مشتركة
معروفة بأنها مستقرة. ويلتزم المطوّرون بصيانة
استقرار واجهات برمجة التطبيقات/البرامج الأساسية.
- تتضمّن 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
.
- تتضمّن LL-NDK المكتبات التالية:
- مكتبات VNDK المؤهَّلة (VNDK) هي مكتبات
مشترَكة للإطار يمكن نسخها مرتين بأمان. يمكن لوحدات إطار العمل ووحدات المورّدين الربط بنُسخها الخاصة. لا يمكن أن تصبح مكتبة مشاركة
لإطار عمل مكتبة VNDK مؤهَّلة إلا إذا كانت تستوفي المعايير التالية:
- ولا يرسل/يتلقّى طلبات IPC من/إلى الإطار.
- ولا يرتبط هذا الخطأ بالجهاز الافتراضي ART.
- لا يمكن قراءة أو كتابة الملفات أو الأقسام التي تستخدم تنسيقات ملفات غير مستقرة.
- لا يتضمّن ترخيصًا خاصًا للبرامج يتطلّب إجراء مراجعات قانونية.
- لا يعترض مالك الرمز على استخدامات المورّدين.
- المكتبات المخصّصة لإطار العمل فقط (FWK-ONLY) هي مكتبات
مشترَكة لإطار العمل لا تنتمي إلى الفئات المذكورة أعلاه. المكتبات التالية:
- تُعتبر تفاصيل التنفيذ الداخلي لإطار العمل.
- يجب ألا يتم الوصول إليها بواسطة وحدات الموردين.
- أن تكون واجهات برمجة التطبيقات أو معرّفات ABI غير مستقرة ولا تتوفّر أي ضمانات لتوافق واجهات برمجة التطبيقات أو معرّفات ABI
- لا يتم نسخها.
HAL لعملية واحدة (SP-HAL)
HAL في العملية نفسها (SP-HAL) هو مجموعة من واجهات HAL مُحدَّدة مسبقًا يتم تنفيذها كـ مكتبات مشترَكة لمورّدي البرامج ويتم تحميلها في عمليات إطار العمل. يتم عزل واجهات برمجة التطبيقات لنظام التشغيل (SP-HAL) من خلال مساحة اسم الرابط (التي تتحكّم في المكتبات والرموز الظاهرة للمكتبات المشتركة). يجب أن تعتمد واجهات برمجة التطبيقات لمستوى الحِزم الأساسي (SP-HAL) فقط على LL-NDK وVNDK-SP.
VNDK-SP هي مجموعة فرعية محدّدة مسبقًا من مكتبات VNDK المؤهّلة. تتم مراجعة مكتبات VNDK-SP بعناية لضمان ألا يتسبب التحميل المزدوج لمكتبات VNDK-SP في عمليات إطار العمل في حدوث مشاكل. تحدِّد شركة Google واجهات برمجة التطبيقات 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
(نص العرض)
إصدارات مجموعة تطوير البرامج الأصلية للمورّدين (VNDK)
يتم تحديد إصدارات لمكتبات VNDK المشتركة:
- تتم إضافة سمة النظام
ro.vndk.version
تلقائيًا إلى/vendor/default.prop
. - يتم تثبيت المكتبات المشتركة الخاصة بكل من VNDK وVNDK-SP على أنها واجهة VNDK
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
) على سمة ro.vndk.version
لتحميل مجموعات بيانات مكتبات VNDK المؤهَّلة المطابقة.