از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
پسوندهای VNDK
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
سازندگان دستگاه های اندرویدی کد منبع کتابخانه های AOSP را به دلایل مختلف تغییر می دهند. برخی از فروشندگان توابع را در کتابخانه های AOSP برای افزایش عملکرد مجدداً پیاده سازی می کنند در حالی که سایر فروشندگان قلاب های جدید، API های جدید یا عملکردهای جدید را به کتابخانه های AOSP اضافه می کنند. این بخش دستورالعمل هایی را برای گسترش کتابخانه های AOSP به گونه ای ارائه می دهد که CTS/VTS را خراب نکند.
جایگزینی کشویی
همه کتابخانه‌های اشتراک‌گذاری شده اصلاح‌شده باید با همتای AOSP خود سازگار باینری باشند. همه کاربران AOSP موجود باید بتوانند از کتابخانه اشتراکی اصلاح شده بدون کامپایل مجدد استفاده کنند. این الزام متضمن موارد زیر است:
- توابع AOSP نباید حذف شوند.
- اگر این سازه ها در معرض دید کاربرانشان قرار می گیرند، سازه ها نباید تغییر کنند.
- پیش شرط توابع نباید تقویت شود.
- توابع باید عملکردهای معادل را ارائه دهند.
- وضعیت پس از توابع نباید تضعیف شود.
طبقه بندی ماژول های توسعه یافته
ماژول ها را بر اساس عملکردهایی که تعریف و استفاده می کنند طبقه بندی کنید.
توجه : در اینجا از Functionalities به جای API/ABI استفاده می شود، زیرا امکان افزودن عملکرد بدون تغییر API/ABI وجود دارد.
بسته به عملکردهای تعریف شده در یک ماژول، ماژول ها را می توان به DA-Module و DX-Module طبقه بندی کرد:
- ماژول‌های فقط تعریف AOSP (DA-Module) قابلیت‌های جدیدی را که در همتای AOSP نبودند، تعریف نمی‌کنند.
- مثال 1. یک کتابخانه AOSP دست نخورده اصلاح نشده یک DA-Module است.
- مثال 2. اگر فروشنده ای توابع را در
libcrypto.so با دستورالعمل های SIMD بازنویسی کند (بدون افزودن توابع جدید)، آنگاه libcrypto.so اصلاح شده یک DA-Module خواهد بود.
- ماژول‌های تعریف افزودنی (DX-Module) یا قابلیت‌های جدیدی را تعریف می‌کنند یا مشابه AOSP ندارند.
- مثال 1. اگر فروشنده‌ای برای دسترسی به برخی داده‌های داخلی، تابع کمکی را به
libjpeg.so اضافه کند، libjpeg.so اصلاح‌شده یک DX-Lib و تابع تازه اضافه‌شده بخش توسعه‌یافته کتابخانه خواهد بود. - مثال 2. اگر فروشنده ای یک کتابخانه غیر AOSP به نام
libfoo.so تعریف کند، libfoo.so یک DX-Lib خواهد بود.
بسته به عملکردهای مورد استفاده توسط یک ماژول، ماژول ها را می توان به UA-Module و UX-Module طبقه بندی کرد.
- Using-only-AOSP Module (UA-Module) فقط از عملکردهای AOSP در پیاده سازی خود استفاده می کند. آنها به هیچ برنامه افزودنی غیر AOSP متکی نیستند.
- مثال 1. یک کتابخانه AOSP دست نخورده اصلاح نشده یک UA-Module است.
- مثال 2. اگر یک کتابخانه اشتراکی اصلاح شده
libjpeg.so فقط به دیگر AOSP های AOSP متکی باشد، آنگاه یک UA-Module خواهد بود.
- ماژول های با استفاده از افزونه (UX-Module) در پیاده سازی خود به برخی از عملکردهای غیر AOSP متکی هستند.
- مثال 1. اگر یک
libjpeg.so اصلاح شده به کتابخانه غیر AOSP دیگری به نام libjpeg_turbo2.so متکی باشد، آنگاه libjpeg.so اصلاح شده یک UX-Module خواهد بود. - مثال 2. اگر فروشنده یک تابع جدید به
libexif.so اصلاح شده خود اضافه کند و libjpeg.so اصلاح شده خود از تابع جدید اضافه شده از libexif.so استفاده کند، آنگاه libjpeg.so اصلاح شده او یک UX-Module خواهد بود.
تعاریف و کاربردها مستقل از یکدیگر هستند:
| عملکردهای مورد استفاده |
|---|
| فقط AOSP (UA) | توسعه یافته (UX) |
| کارکردهای تعریف شده | فقط AOSP (DA) | DAUA | DAUX |
|---|
| تمدید شده (DX) | DXUA | DXUX |
مکانیسم گسترش VNDK
ماژول‌های فروشنده‌ای که به قابلیت‌های توسعه‌یافته متکی هستند، کار نمی‌کنند، زیرا کتابخانه AOSP با همین نام، عملکرد توسعه‌یافته را ندارد. اگر ماژول‌های فروشنده به طور مستقیم یا غیرمستقیم به قابلیت‌های توسعه‌یافته وابسته هستند، فروشندگان باید کتابخانه‌های مشترک DAUX، DXUA و DXUX را در پارتیشن فروشنده کپی کنند (فرایندهای فروشنده همیشه ابتدا به دنبال کتابخانه‌های مشترک در پارتیشن فروشنده می‌گردند). با این حال، کتابخانه های LL-NDK نباید کپی شوند، بنابراین ماژول های فروشنده نباید به قابلیت های توسعه یافته تعریف شده توسط کتابخانه های LL-NDK اصلاح شده تکیه کنند.
کتابخانه‌های مشترک DAUA می‌توانند در پارتیشن سیستم باقی بمانند، اگر کتابخانه AOSP مربوطه بتواند همان عملکرد را ارائه دهد و زمانی که پارتیشن سیستم توسط یک تصویر سیستم عمومی (GSI) بازنویسی شود، ماژول‌های فروشنده به کار خود ادامه می‌دهند.
جایگزینی Drop-in مهم است زیرا کتابخانه‌های VNDK اصلاح نشده در GSI در هنگام برخورد نام با کتابخانه‌های اشتراک‌گذاری شده اصلاح‌شده مرتبط می‌شوند. اگر کتابخانه‌های AOSP به شیوه‌ای ناسازگار با API/ABI اصلاح شوند، ممکن است کتابخانه‌های AOSP در GSI نتوانند پیوند داده شوند یا منجر به رفتارهای نامشخص شوند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
