نظرة عامة على مجموعة تطوير البرامج الأصلية للمورّدين (VNDK)

مجموعة تطوير أصلية للمورّدين (VNDK) هي مجموعة من المكتبات التي تستخدمها مكتبات أو برامج ثنائية أخرى في قسم المورّد أو المنتج أثناء وقت التشغيل من أجل dlopen.

الإيقاف النهائي

تم طرح Vendor NDK في نظام Android 8.0 لتوفير واجهات برمجة تطبيقات بين إطار العمل ورمز المورّد. على الرغم من أنّ VNDK تم استخدامه بنجاح لسنوات عديدة، إلا أنّه يتضمّن بعض العيوب، وهي:

• مساحة التخزين
• تحتوي حزمة APEX واحدة من VNDK على جميع مكتبات VNDK، سواء تم استخدامها من الجهاز أم لا.
• تحتوي GSI على إصدارات متعددة من حِزم VNDK APEX لدعم إصدارات متعددة من صور المورّد.
• قابلية التحديث
• يصعب تحديث حِزم VNDK APEX بشكل منفصل عن تحديث النظام الأساسي.
• يتم تحديث صور المورِّدين بشكل متكرّر عبر شبكة غير سلكية (OTA)، ما يقلّل من مزايا تضمين VNDK في صورة النظام.

استنادًا إلى هذه المشاكل، قرّرنا إيقاف VNDK نهائيًا بدءًا من Android 15.

تفاصيل حول إيقاف مجموعة تطوير أصلية للمورّدين (VNDK) نهائيًا

يتم تجميع جميع مكتبات VNDK في حزمة VNDK APEX وتثبيتها في صورة النظام (-ext). مع إيقاف VNDK نهائيًا، يتم تثبيت مكتبات VNDK السابقة في صورة المورّد (أو المنتج)، تمامًا مثل المكتبات الأخرى المتاحة للمورّد. تتم إزالة هذه الميزات مع إيقاف VNDK نهائيًا:

• حزمة VNDK APEX لنظام التشغيل Android 15
• تتم إزالة خصائص النظام التي تشير إلى إصدار VNDK المستهدف إذا تم إنشاء أقسام المورّد أو المنتج لنظام التشغيل Android 15:
  • ro.vndk.version
  • ro.product.vndk.version
• لن تتوفّر تحسينات VNDK لأنّه لا يتوفّر VNDK:
  • TARGET_VNDK_USING_CORE_VARIANT لأجهزة Android Go
  • ‫use_vndk_as_stable لحِزم APEX الخاصة بالمورّدين
• لقطة المورّد، التي تعتمد بشكل كبير على VNDK

استثناءات الإيقاف النهائي

لن تتغيّر هذه الميزات عند إيقاف VNDK نهائيًا:

• حِزم VNDK APEX التي تتضمّن الإصدار 14 أو إصدارًا أقدم من VNDK، وهي مطلوبة لتوفير الدعم لصور المورّد الحالية
• لا يشكّل LL-NDK جزءًا من VNDK.

لماذا VNDK؟

يسمح مشروع AOSP بتحديثات الإطار فقط، حيث يمكن ترقية قسم النظام إلى أحدث إصدار من الإطار بدون تغيير قسم المورّد. على الرغم من إنشاء الثنائيات في أوقات مختلفة، يجب أن تكون الثنائيات في كل قسم قادرة على العمل مع بعضها البعض.

تشمل التحديثات التي تتضمّن إطار العمل فقط التحديات التالية:

• الاعتمادية بين وحدات إطار العمل ووحدات المورّد قبل الإصدار Android 8.0، كان بإمكان الوحدات في قسمَي المورّد والنظام الربط مع بعضها البعض. ومع ذلك، فرضت التبعيات من وحدات المورّد قيودًا غير مرغوب فيها على تطوير وحدات إطار العمل.
• إضافات إلى مكتبات AOSP يشترط نظام التشغيل Android أن تجتاز جميع أجهزة Android مجموعة أدوات اختبار التوافق (CTS) عند استبدال قسم النظام بصورة نظام عامة (GSI) عادية. ومع ذلك، عندما يوسّع المورّدون مكتبات AOSP لتعزيز الأداء أو لإضافة وظائف إضافية إلى عمليات تنفيذ HIDL، قد يؤدي نقل قسم النظام باستخدام حزمة GSI عادية إلى إيقاف عملية تنفيذ HIDL الخاصة بالمورّد. للحصول على إرشادات حول منع حدوث مثل هذه المشاكل، راجِع إضافات VNDK.

ولمواجهة هذه التحديات، يتضمّن نظام التشغيل Android العديد من الميزات، مثل VNDK (الموضّحة في هذا القسم) وHIDL وhwbinder وتراكب شجرة الأجهزة وتراكب sepolicy.

مصطلحات خاصة بمجموعة تطوير أصلية للمورّدين (VNDK)

تستخدم المستندات ذات الصلة بـ VNDK المصطلحات التالية:

• تشير الوحدات إلى المكتبات المشتركة أو الملفات التنفيذية. تنشئ الوحدات تبعيات في وقت الإنشاء.
• العمليات هي مهام نظام التشغيل التي يتم إنشاؤها من الملفات التنفيذية. تنشئ العمليات تبعيات وقت التشغيل.
• المصطلحات المؤهَّلة لإطار العمل مرتبطة بالقسم system:
• تشير ملفات إطار العمل التنفيذية إلى الملفات التنفيذية في /system/bin أو /system/xbin.
• تشير مكتبات إطار العمل المشتركة إلى المكتبات المشتركة ضمن /system/lib[64].
• تشير وحدات إطار العمل إلى كل من مكتبات إطار العمل المشتركة وملفات إطار العمل التنفيذية.
• عمليات إطار العمل هي عمليات يتم إنشاؤها من ملفات تنفيذية خاصة بإطار العمل، مثل /system/bin/app_process.
• تتعلّق عبارات المورِّد المؤهَّلة بأقسام vendor:
• تشير ملفات التنفيذ الخاصة بالمورِّدين إلى ملفات التنفيذ في /vendor/bin
• تشير المكتبات المشترَكة الخاصة بالمورّدين إلى المكتبات المشترَكة ضمن /vendor/lib[64].
• تشير وحدات البائعين إلى كل من ملفات البائعين التنفيذية ومكتبات البائعين المشترَكة.
• عمليات المورّد هي عمليات يتم إنشاؤها من ملفات المورّد التنفيذية، مثل /vendor/bin/android.hardware.camera.provider@2.4-service.

مفاهيم مجموعة تطوير أصلية للمورّدين (VNDK)

في نظام التشغيل Android 8.0 والإصدارات الأحدث، لا تحمّل عمليات إطار العمل المكتبات المشتركة الخاصة بالمورّد، ولا تحمّل جميع عمليات المورّد سوى المكتبات المشتركة الخاصة بالمورّد (وجزء من المكتبات المشتركة الخاصة بإطار العمل)، ويتم تنظيم عمليات التواصل بين عمليات إطار العمل وعمليات المورّد من خلال HIDL وhardware binder.

يتضمّن هذا العالم إمكانية عدم كفاية واجهات برمجة التطبيقات العامة الثابتة من مكتبات إطار العمل المشترَكة لمطوّري وحدات البائعين (على الرغم من إمكانية تغيير واجهات برمجة التطبيقات بين إصدارات Android)، ما يتطلّب إتاحة الوصول إلى جزء من مكتبات إطار العمل المشترَكة لعمليات البائعين. بالإضافة إلى ذلك، بما أنّ متطلبات الأداء يمكن أن تؤدي إلى تسوية، يجب التعامل بشكل مختلف مع بعض طبقات تجريد الأجهزة (HAL) التي تتطلّب استجابة سريعة.

توضّح الأقسام التالية بالتفصيل كيفية تعامل VNDK مع المكتبات المشترَكة للإطار المخصّصة للمورّدين وواجهات HAL التي تعمل في العملية نفسها (SP-HAL).

مكتبات مشتركة لإطار العمل خاصة بالمورّد

يصف هذا القسم معايير تصنيف المكتبات المشتركة التي يمكن أن تصل إليها عمليات المورّد. هناك طريقتان لتوفير الدعم لوحدات البائعين النمطية في إصدارات Android المتعددة:

1. تثبيت واجهات التطبيق الثنائية (ABI) وواجهات برمجة التطبيقات (API) لمكتبات إطار العمل المشتركة: يمكن لوحدات إطار العمل الجديدة ووحدات المورّد القديمة استخدام المكتبة المشترَكة نفسها لتقليل مساحة الذاكرة وحجم التخزين. تتجنّب المكتبة المشتركة الفريدة أيضًا العديد من المشاكل المتعلّقة بالتحميل المزدوج. ومع ذلك، فإنّ تكلفة التطوير اللازمة للحفاظ على ثبات واجهات التطبيق الثنائية (ABI) وواجهات برمجة التطبيقات (API) مرتفعة، ومن غير الواقعي تثبيت جميع واجهات التطبيق الثنائية وواجهات برمجة التطبيقات التي يتم تصديرها من خلال كل مكتبة مشترَكة في إطار العمل.
2. نسخ المكتبات المشتركة القديمة لإطار العمل يأتي مع قيود صارمة ضد القنوات الجانبية، والتي يتم تعريفها على أنّها جميع آليات التواصل بين وحدات إطار العمل ووحدات المورّد، بما في ذلك (على سبيل المثال لا الحصر) binder وsocket وpipe والذاكرة المشتركة والملف المشترك وخصائص النظام. يجب ألا يكون هناك أي اتصال إلا إذا كان بروتوكول الاتصال مجمّدًا وثابتًا (مثل 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
• مكتبات VNDK المؤهَّلة (VNDK) هي مكتبات مشتركة في إطار العمل يمكن نسخها مرتين بدون أي مشاكل. يمكن ربط وحدات إطار العمل ووحدات المورّد بنسخها الخاصة. لا يمكن أن تصبح مكتبة إطار عمل مشتركة مكتبة VNDK مؤهَّلة إلا إذا استوفت المعايير التالية:
  • ولا يرسل/يتلقّى عمليات IPC من/إلى إطار العمل.
  • ولا يرتبط بالجهاز الافتراضي ART.
  • لا يمكنه قراءة/كتابة الملفات/الأقسام بتنسيقات ملفات غير ثابتة.
  • لا يتضمّن ترخيصًا خاصًا للبرامج يتطلّب مراجعات قانونية.
  • لا يعترض مالك الرمز على استخدامات المورّد.
• المكتبات التي تتضمّن إطار عمل فقط (FWK-ONLY) هي مكتبات مشتركة تتضمّن إطار عمل لا تنتمي إلى الفئات المذكورة أعلاه. تتضمّن هذه المكتبات ما يلي:
  • تُعدّ تفاصيل التنفيذ الداخلية للإطار.
  • يجب ألا تصل إليها وحدات المورّد.
  • أن تتضمّن واجهات ثنائية/واجهات برمجة تطبيقات غير مستقرة ولا تتضمّن ضمانات توافق مع واجهات برمجة التطبيقات/الواجهات الثنائية
  • لا يتم نسخها.

طبقة تجريد الأجهزة (HAL) التي تعمل في العملية نفسها (SP-HAL)

طبقة تجريد الأجهزة (HAL) التي تعمل في العملية نفسها (SP-HAL) هي مجموعة من طبقات تجريد الأجهزة المحدّدة مسبقًا والتي يتم تنفيذها على شكل مكتبات مشتركة خاصة بالمورّدين ويتم تحميلها في عمليات إطار العمل. يتم عزل حزم SP-HAL من خلال مساحة اسم الرابط (التي تتحكّم في المكتبات والرموز المرئية للمكتبات المشتركة). يجب أن تعتمد طبقات تجريد الأجهزة (HAL) الخاصة بمورّد النظام الأساسي على LL-NDK وVNDK-SP فقط.

‫VNDK-SP هي مجموعة فرعية محدَّدة مسبقًا من مكتبات VNDK المؤهَّلة. تتم مراجعة مكتبات VNDK-SP بعناية لضمان عدم حدوث مشاكل عند تحميل مكتبات VNDK-SP بشكل مزدوج في عمليات إطار العمل. تحدّد Google كلاً من SP-HAL وVNDK-SP.

المكتبات التالية هي طبقات تجريد أجهزة الاستشعار المعتمَدة:

• 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 (Renderscript)

إصدارات مجموعة تطوير أصلية للمورّدين (VNDK)

تتضمّن المكتبات المشتركة في VNDK معلومات الإصدار:

• تتم إضافة سمة النظام ro.vndk.version تلقائيًا إلى /vendor/default.prop.
• يتم تثبيت المكتبات المشتركة الخاصة بـ VNDK وVNDK-SP كحزمة apex خاصة بـ 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)

تتطلّب "مجموعة اختبارات المورّدين" (VTS) في Android توفّر السمة ro.vndk.version غير الفارغة. يجب أن تحدّد كل من الأجهزة التي تم إطلاقها حديثًا والأجهزة التي يتم ترقيتها ro.vndk.version. تعتمد بعض حالات اختبار VNDK (مثل VtsVndkFilesTest وVtsVndkDependencyTest) على السمة ro.vndk.version لتحميل مجموعات بيانات مكتبات VNDK المؤهَّلة المطابقة.