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

إن Vendor Native Development Kit (VNDK) عبارة عن مجموعة من المكتبات التي تستخدمها مكتبات أو ثنائيات أخرى ، في قسم البائع أو المنتج ، في وقت تشغيل dlopen.

لماذا VNDK؟

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

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

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

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

شروط خاصة بـ 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 والأجهزة الاتصالات بين عمليات إطار العمل وعمليات البائع الموثق.

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

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

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

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

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

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

  • مكتبات LL-NDK هي مكتبات إطار عمل مشتركة معروفة بأنها مستقرة. يلتزم مطوروها بالحفاظ على ثباتات API / ABI الخاصة بهم.
    • يتضمن LL-NDK المكتبات التالية: libEGL.so ، libGLESv1_CM.so ، libGLESv2.so ، libGLESv3.so ، libandroid_net.so ، libc.so ، libc.so ، libdl.so ، liblog.so ، libm.so ، libnativewindow.so ، libneuralnetworks.so ، libneuralnetworks.so ، libsync.so ، libvndksupport.so ، و libvulkan.so ،
  • مكتبات VNDK المؤهلة (VNDK) هي مكتبات إطار عمل مشتركة آمنة ليتم نسخها مرتين. يمكن ربط وحدات الإطار ووحدات البائع بنسخها الخاصة. يمكن أن تصبح مكتبة إطار العمل المشتركة مكتبة VNDK مؤهلة فقط إذا كانت تفي بالمعايير التالية:
    • لا يرسل / يستقبل IPCs إلى / من إطار العمل.
    • لا علاقة له بجهاز ART الظاهري.
    • لا يقرأ / يكتب الملفات / الأقسام بتنسيقات ملفات غير مستقرة.
    • ليس لديها ترخيص برنامج خاص يتطلب مراجعات قانونية.
    • ليس لدى مالك الرمز الخاص بها اعتراضات على استخدامات البائعين.
  • مكتبات الإطار فقط (FWK-ONLY) هي مكتبات إطار عمل مشتركة لا تنتمي إلى الفئات المذكورة أعلاه. هذه المكتبات:
    • تعتبر تفاصيل التنفيذ الداخلي لإطار العمل.
    • يجب ألا يتم الوصول إليها بواسطة وحدات البائعين.
    • احصل على واجهات برمجة تطبيقات / واجهات برمجة تطبيقات غير مستقرة ولا توجد ضمانات توافق API / ABI.
    • لا يتم نسخها.

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

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

VNDK-SP هي مجموعة فرعية محددة مسبقًا من مكتبات VNDK المؤهلة. تتم مراجعة مكتبات VNDK-SP بعناية للتأكد من أن التحميل المزدوج لمكتبات VNDK-SP في عمليات إطار العمل لا يسبب مشاكل. يتم تحديد كل من SP-HALs و VNDK-SPs بواسطة Google.

المكتبات التالية معتمدة من SP-HALs:

  • 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 المؤهلة المطابقة.