پسوندهای 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 خواهد بود.

تعاریف و کاربردها مستقل از یکدیگر هستند:

مکانیسم گسترش VNDK

ماژول‌های فروشنده‌ای که به قابلیت‌های توسعه‌یافته متکی هستند، کار نمی‌کنند، زیرا کتابخانه AOSP با همین نام، عملکرد توسعه‌یافته را ندارد. اگر ماژول‌های فروشنده به طور مستقیم یا غیرمستقیم به قابلیت‌های توسعه‌یافته وابسته هستند، فروشندگان باید کتابخانه‌های مشترک DAUX، DXUA و DXUX را در پارتیشن فروشنده کپی کنند (فرایندهای فروشنده همیشه ابتدا به دنبال کتابخانه‌های مشترک در پارتیشن فروشنده می‌گردند). با این حال، کتابخانه های LL-NDK نباید کپی شوند، بنابراین ماژول های فروشنده نباید به قابلیت های توسعه یافته تعریف شده توسط کتابخانه های LL-NDK اصلاح شده تکیه کنند.

کتابخانه‌های مشترک DAUA می‌توانند در پارتیشن سیستم باقی بمانند، اگر کتابخانه AOSP مربوطه بتواند همان عملکرد را ارائه دهد و زمانی که پارتیشن سیستم توسط یک تصویر سیستم عمومی (GSI) بازنویسی شود، ماژول‌های فروشنده به کار خود ادامه می‌دهند.

جایگزینی Drop-in مهم است زیرا کتابخانه‌های VNDK اصلاح نشده در GSI در هنگام برخورد نام با کتابخانه‌های اشتراک‌گذاری شده اصلاح‌شده مرتبط می‌شوند. اگر کتابخانه‌های AOSP به شیوه‌ای ناسازگار با API/ABI اصلاح شوند، ممکن است کتابخانه‌های AOSP در GSI نتوانند پیوند داده شوند یا منجر به رفتارهای نامشخص شوند.