اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
إضافات مجموعة تطوير البرامج الأصلية للمورّدين (VNDK)
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تغيّر الشركات المصنّعة لأجهزة Android رمز المصدر لمكتبات AOSP لأسباب
مختلفة. يعيد بعض المورّدين تنفيذ الدوال في مكتبات AOSP لتحسين الأداء، في حين يضيف مورّدون آخرون عناصر ربط جديدة أو واجهات برمجة تطبيقات جديدة أو وظائف جديدة إلى مكتبات AOSP. يوفّر هذا القسم إرشادات بشأن
توسيع نطاق مكتبات AOSP بطريقة لا تؤدي إلى إيقاف CTS/VTS.
الاستبدال الفوري
يجب أن تكون جميع المكتبات المشتركة المعدَّلة متوافقة مع الثنائيات،
وكذلك أن تكون بدائل قابلة للاستبدال لتلك المضمّنة في AOSP. يجب أن يتمكّن جميع مستخدمي AOSP الحاليين من استخدام المكتبة المشترَكة المعدَّلة بدون الحاجة إلى إعادة الترجمة. يشير هذا الشرط إلى ما يلي:
- يجب عدم إزالة وظائف AOSP.
- يجب عدم تغيير البنى إذا كانت هذه البنى ظاهرة
للمستخدمين.
- يجب عدم تعزيز الشرط المسبق للوظائف.
- يجب أن توفّر الدوال وظائف مماثلة.
- يجب عدم إضعاف الشرط اللاحق للدوالّ.
تصنيفات الوحدات الموسّعة
يمكنك تصنيف الوحدات حسب الوظائف التي تحدّدها و
تستخدمها.
ملاحظة: يتم استخدام الوظائف هنا بدلاً من واجهة برمجة التطبيقات/المعيار الأساسي للبرامج (ABI) لأنّه من الممكن إضافة وظائف بدون تغيير
أي واجهة برمجة تطبيقات/معيار أساسي للبرامج.
استنادًا إلى الوظائف المحدّدة في الوحدة، يمكن
تصنيف الوحدات إلى وحدة DA ووحدة DX:
-
لا تحدِّد وحدات تحديد AOSP فقط (DA-Module) وظائف
جديدة لم تكن متوفّرة في نظيرها في AOSP.
- المثال 1: مكتبة AOSP سليمة وغير معدَّلة هي
وحدة DA.
- المثال 2: إذا أعاد أحد المورّدين كتابة الدوالّ في
libcrypto.so
باستخدام تعليمات SIMD (بدون إضافة وظائف
جديدة)، سيكون libcrypto.so
المعدَّل وحدة DA.
-
وحدات التعريف والإضافات (DX-Module): تحدِّد هذه الوحدات وظائف
جديدة أو لا تتضمّن نظيرًا في AOSP.
- المثال 1: إذا أضاف مورّد دالة مساعدة إلى
libjpeg.so
للوصول إلى بعض البيانات الداخلية، ستكون
libjpeg.so
المعدّلة هي مكتبة DX-Lib، وستكون الدالة المُضافة حديثًا هي
الجزء الموسّع من المكتبة.
- المثال 2: إذا عرَّف أحد المورّدين مكتبة غير تابعة لمشروع AOSP باسم
libfoo.so
، ستكون libfoo.so
مكتبة DX-Lib.
استنادًا إلى الوظائف التي تستخدمها الوحدة، يمكن تصنيف الوحدات
إلى وحدة تجربة المستخدم ووحدة تحليل الأداء.
-
استخدام وحدات AOSP فقط (UA-Module): لا تستخدم هذه الوحدات سوى وظائف AOSP
في عمليات التنفيذ. ولا تعتمد هذه التطبيقات على أي إضافات غير تابعة لمشروع AOSP.
- المثال 1: مكتبة AOSP سليمة وغير معدَّلة هي
وحدة UA.
- المثال 2: إذا كانت مكتبة مشتركة معدَّلة
libjpeg.so
تعتمد فقط على واجهات برمجة تطبيقات AOSP الأخرى، ستكون وحدة UA.
-
تعتمد وحدات الاستخدام الموسّع (UX-Module) على بعض الوظائف غير المضمّنة في إطار عمل AOSP عند تنفيذها.
- المثال 1: إذا كان
libjpeg.so
معدَّلاً يعتمد على
مكتبة أخرى غير تابعة لمشروع AOSP باسم libjpeg_turbo2.so
، سيكون
libjpeg.so
المعدَّل وحدة تجربة مستخدم.
- المثال 2: إذا أضاف المورّد دالة جديدة إلى
libexif.so
المعدَّلة واستخدم
libjpeg.so
المعدَّلة الدالة المُضافة حديثًا من libexif.so
، ستكون
libjpeg.so
المعدَّلة وحدة تجربة مستخدم.
التعريفات وطريقة الاستخدام مستقلّة عن بعضها:
|
الوظائف المستخدَمة |
AOSP فقط (UA) |
موسّع (تجربة المستخدم) |
الوظائف المحدّدة |
AOSP فقط (DA) |
DAUA |
DAUX |
موسّع (DX) |
DXUA |
DXUX |
آلية إضافة مجموعة تطوير أصلية للمورّدين (VNDK)
لن تعمل وحدات المورّدين التي تعتمد على وظائف موسّعة لأنّ مكتبة AOSP التي تحمل الاسم نفسه لا تتضمّن الوظائف الموسّعة. إذا كانت
وحدات المورّد تعتمد بشكل مباشر أو غير مباشر على وظائف موسّعة،
على المورّدين نسخ المكتبات المشتركة DAUX وDXUA وDXUX إلى ملف التمهيد
للمورّد (تبحث عمليات المورّد دائمًا عن المكتبات المشتركة في ملف التمهيد
للمورّد أولاً). ومع ذلك، يجب عدم نسخ مكتبات LL-NDK، لذا يجب ألا تعتمد وحدات المورّد
على الوظائف الموسّعة التي تحدّدها مكتبات LL-NDK المعدَّلة.
يمكن أن تظل المكتبات المشتركة لـ DAUA في قسم النظام إذا كانت مكتبة AOSP المقابلة يمكنها توفير الوظائف نفسها واستمر عمل وحدات التصنيع عند استبدال قسم النظام بـ Generic System Image (GSI).
من المهم إجراء الاستبدال الفوري لأنّ مكتبات VNDK غير المعدَّلة في
مجموعة أدوات GSI سترتبط بالمكتبات المشتركة المعدَّلة عند تعارض الأسماء. في حال تعديل مكتبات AOSP بطريقة غير متوافقة مع واجهة برمجة التطبيقات أو مع ABI، قد يتعذّر ربط مكتبات AOSP في GSI أو قد تؤدي إلى سلوكيات غير محدّدة.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# VNDK extensions\n\nAndroid device manufacturers change the source code of AOSP libraries for\nvarious reasons. Some vendors reimplement functions in AOSP libraries to\nboost the performance while other vendors add new hooks, new APIs, or new\nfunctionalities to AOSP libraries. This section provides guidelines for\nextending AOSP libraries in a way that does not break CTS/VTS.\n\nDrop-in replacement\n-------------------\n\nAll modified shared libraries must be **binary-compatible** ,\n**drop-in replacements** of their AOSP counterpart. All existing\nAOSP users must be able to use the modified shared library without\nrecompilations. This requirement implies the following:\n\n- AOSP functions must not be removed.\n- Structures must not be altered if such structures are exposed to their users.\n- Pre-condition of functions must not be strengthened.\n- Functions must provide equivalent functionalities.\n- Post-condition of functions must not be weakened.\n\nExtended module classifications\n-------------------------------\n\nClassify modules by the functionalities they **define** and\n**use**.\n\n**Note** : *Functionalities* is used here\ninstead of API/ABI because it is possible to add functionality without changing\nany API/ABI.\n\nDepending on the functionalities defined in a module, modules can be\nclassified into **DA-Module** and **DX-Module**:\n\n- *Defining-only-AOSP Modules (DA-Module)* do not define new functionalities which were not in the AOSP counterpart.\n - *Example 1.* An intact unmodified AOSP library is a DA-Module.\n - *Example 2.* If a vendor rewrites the functions in `libcrypto.so` with SIMD instructions (without adding new functions), then the modified `libcrypto.so` will be a DA-Module.\n- *Defining-Extension Modules (DX-Module)* either define new functionalities or do not have an AOSP counterpart.\n - *Example 1.* If a vendor adds a helper function to `libjpeg.so` to access some internal data, then the modified `libjpeg.so` will be a DX-Lib and the newly added function will be the extended portion of the library.\n - *Example 2.* If a vendor defines a non-AOSP library named `libfoo.so`, then `libfoo.so` will be a DX-Lib.\n\nDepending on the functionalities used by a module, modules can be classified\ninto **UA-Module** and **UX-Module**.\n\n- *Using-only-AOSP Modules (UA-Module)* only use AOSP functionalities in their implementations. They do not rely on any non-AOSP extensions.\n - *Example 1.* An intact unmodified AOSP library is an UA-Module.\n - *Example 2.* If a modified shared library `libjpeg.so` only relies on other AOSP APIs, then it will be an UA-Module.\n- *Using-Extension Modules (UX-Module)* rely on some non-AOSP functionalities in their implementations.\n - *Example 1.* If a modified `libjpeg.so` relies on another non-AOSP library named `libjpeg_turbo2.so`, then the modified `libjpeg.so` will be an UX-Module.\n - *Example 2.* If a vendor adds a new function to their modified `libexif.so` and their modified `libjpeg.so` uses the newly added function from `libexif.so`, then their modified `libjpeg.so` will be an UX-Module.\n\nDefinitions and usages are independent from each other:\n\n|---------------|------|----------------|---------------|\n| || Used Functionalities ||\n| || Only AOSP (UA) | Extended (UX) |\n| Extended (DX) | DXUA | DXUX |\n\nVNDK extension mechanism\n------------------------\n\nVendor modules that rely on extended functionalities won't work because the\nAOSP library with the same name does not have the extended functionality. If\nvendor modules directly or indirectly depend on extended functionalities,\nvendors should copy DAUX, DXUA, and DXUX shared libraries to the vendor\npartition (vendor processes always look for shared libraries in the vendor\npartition first). However, LL-NDK libraries must not be copied, so vendor\nmodules must not rely on the extended functionalities defined by the modified\nLL-NDK libraries.\n\nDAUA shared libraries can remain on the system partition if the\ncorresponding AOSP library can provide the same functionality and vendor\nmodules continue to work when the system partition is overwritten by a Generic\nSystem Image (GSI).\n\nDrop-in replacement is important because the unmodified VNDK libraries in\nthe GSI will link with the modified shared libraries on name collision. If the\nAOSP libraries are modified in an API/ABI incompatible manner, the AOSP\nlibraries in the GSI might fail to link or result in undefined behaviors."]]