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

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

لماذا 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 والأجهزة الموثق.

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

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

إطار المكتبات المشتركة للبائع

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

  1. استقرار واجهات برمجة التطبيقات/واجهات برمجة التطبيقات للمكتبات المشتركة لإطار العمل . يمكن لوحدات إطار العمل الجديدة ووحدات البائع القديمة استخدام نفس المكتبة المشتركة لتقليل أثر الذاكرة وحجم التخزين. تتجنب المكتبة المشتركة الفريدة أيضًا العديد من مشكلات التحميل المزدوج. ومع ذلك، فإن تكلفة التطوير للحفاظ على واجهات برمجة التطبيقات/واجهات برمجة التطبيقات المستقرة عالية ومن غير الواقعي تثبيت جميع واجهات برمجة التطبيقات/واجهات برمجة التطبيقات المصدرة بواسطة كل مكتبة إطار عمل مشتركة.
  2. انسخ المكتبات المشتركة للإطار القديم . يأتي مع قيود قوية على القنوات الجانبية، التي تم تعريفها على أنها جميع آليات التواصل بين وحدات إطار العمل ووحدات البائع، بما في ذلك (على سبيل المثال لا الحصر) الموثق والمقبس والأنبوب والذاكرة المشتركة والملف المشترك وخصائص النظام. يجب ألا يكون هناك أي اتصال إلا إذا كان بروتوكول الاتصال متجمدًا ومستقرًا (على سبيل المثال، HIDL عبر hwbinder). قد يتسبب التحميل المزدوج للمكتبات المشتركة في حدوث مشكلات أيضًا؛ على سبيل المثال، إذا تم تمرير كائن تم إنشاؤه بواسطة المكتبة الجديدة إلى الوظائف من المكتبة القديمة، فقد يحدث خطأ لأن هذه المكتبات قد تفسر الكائن بشكل مختلف.

يتم استخدام أساليب مختلفة اعتمادًا على خصائص المكتبات المشتركة. ونتيجة لذلك، يتم تصنيف مكتبات الإطار المشتركة إلى ثلاث فئات فرعية:

  • مكتبات LL-NDK هي مكتبات إطارية مشتركة معروفة بأنها مستقرة. يلتزم مطوروها بالحفاظ على استقرار API/ABI الخاص بهم.
    • يتضمن 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 مؤهلة فقط إذا كانت تستوفي المعايير التالية:
    • لا يرسل/يستقبل IPCs من/إلى الإطار.
    • لا يرتبط بالجهاز الظاهري ART.
    • لا يقرأ/يكتب الملفات/الأقسام بتنسيقات ملفات غير مستقرة.
    • ليس لديها ترخيص برمجيات خاص يتطلب مراجعات قانونية.
    • ليس لدى مالك الكود الخاص به اعتراضات على استخدامات البائع.
  • مكتبات إطار العمل فقط (FWK-ONLY) هي مكتبات إطار عمل مشتركة لا تنتمي إلى الفئات المذكورة أعلاه. هذه المكتبات:
    • تعتبر تفاصيل التنفيذ الداخلي للإطار.
    • يجب ألا يتم الوصول إليها بواسطة وحدات البائع.
    • لديك واجهات ABI/API غير مستقرة ولا توجد ضمانات لتوافق API/ABI.
    • لا يتم نسخها.

نفس العملية HAL (SP-HAL)

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

VNDK-SP هي مجموعة فرعية محددة مسبقًا من مكتبات VNDK المؤهلة. تتم مراجعة مكتبات VNDK-SP بعناية للتأكد من أن التحميل المزدوج لمكتبات VNDK-SP في عمليات إطار العمل لا يسبب مشاكل. يتم تعريف كل من SP-HALs وVNDK-SPs بواسطة 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)

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