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

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

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

تم طرح حزمة تطوير البرامج (NDK) الخاصة بالمورّد في نظام Android 8.0 لتوفير واجهات برمجة تطبيقات بين إطار العمل ورمز المورّد. على الرغم من أنّ VNDK تم استخدامه بنجاح لسنوات عديدة، إلا أنّه يتضمّن بعض العيوب، وهي:
  • مساحة التخزين
    • تحتوي حزمة APEX واحدة من VNDK على جميع مكتبات VNDK، سواء تم استخدامها من الجهاز أم لا.
    • تحتوي GSI على إصدارات متعددة من حِزم VNDK APEX لدعم إصدارات متعددة من صور المورّد.
  • قابلية التحديث
    • يصعب تحديث حِزم APEX الخاصة بـ VNDK بشكل منفصل عن تحديث النظام الأساسي.
    • يتم تحديث صور المورّد بشكل متكرر عبر شبكة غير سلكية (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)

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

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

المكتبات التالية هي طبقات تجريد الأجهزة الخاصة بموفّر الخدمة (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 (Renderscript)

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

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

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