نظرة عامة على "حزمة تطوير البرامج الأصلية للمورّدين" (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 والأجهزة مجلد.

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

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

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

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

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

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

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

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

HAL-عملية مماثلة (SP-HAL) هي مجموعة من HALs المحددة مسبقًا. التنفيذ باعتباره المكتبات المشتركة للمورّدين وتحميلها في إطار العمل العمليات. يتم عزل رموز SP-HAL بواسطة مساحة اسم رابط (تتحكم في المكتبات والرموز المرئية للمكتبات المشتركة). يجب أن تكون عناصر 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 (نص العرض)
  • 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 المؤهلة.