سازندگان دستگاه Android کد منبع کتابخانههای AOSP را به دلایل مختلف تغییر میدهند. برخیاز فروشندگان برای تقویت عملکرد، توابع را در کتابخانههای AOSP مجدداً پیادهسازی میکنند، درحالیکه فروشندگان دیگر قلابهای جدید، میاناهای برنامهسازی کاربردی جدید، یا عملکردهای جدید به کتابخانههای AOSP اضافه میکنند. این بخش دستورالعملهایی برای گسترش کتابخانههای AOSP به روشی که باعث ازکارافتادن CTS/VTS نشود ارائه میدهد.
جایگزین آماده نصب
همه کتابخانههای مشترک اصلاحشده باید با همتای AOSP خود سازگار باینری و جایگزینهای آماده باشند. همه کاربران فعلی AOSP باید بتوانند از کتابخانه مشترک اصلاحشده بدون بازهمگردانی استفاده کنند. این الزام به این معنی است که:
- توابع AOSP نباید برداشته شوند.
- اگر ساختارها درمعرض دید کاربران قرار میگیرند، نباید تغییر کنند.
- پیششرط توابع نباید تقویت شود.
- توابع باید عملکردهای معادل ارائه دهند.
- شرط پساز تابعها نباید تضعیف شود.
طبقهبندیهای واحد توسعهیافته
واحدها را براساس عملکردهایی که تعریف میکنند و استفاده میکنند طبقهبندی کنید.
توجه: در اینجا بهجای API/ABI از عملکردها استفاده میشود زیرا امکان افزودن عملکرد بدون تغییر دادن API/ABI وجود دارد.
بسته به کارکردهای تعریفشده در یک واحد، واحدها میتوانند به واحد DA و واحد DX طبقهبندی شوند:
-
«واحدهای فقط تعریفکننده AOSP» (DA-Module) کارکردهای جدیدی که در همتای AOSP وجود نداشته است تعریف نمیکنند.
- نمونه ۱. کتابخانه AOSP دستنخورده و بدون تغییر یک «واحد DA» است.
- مثال ۲. اگر فروشندهای توابع را در
libcrypto.soبا دستورالعملهای SIMD بازنویسی کند (بدون افزودن توابع جدید)،libcrypto.soاصلاحشده یک DA-Module خواهد بود.
-
واحدهای افزونه تعریفکننده (DX-Module) یا کارکردهای جدیدی را تعریف میکنند یا معادل AOSP ندارند.
- مثال ۱. اگر فروشندهای تابع کمکی به
libjpeg.soاضافه کند تا به برخیاز دادههای داخلی دسترسی پیدا کند،libjpeg.soاصلاحشده یک DX-Lib خواهد بود و تابع تازه اضافه شده بخش توسعهیافته کتابخانه خواهد بود. - مثال ۲. اگر فروشندهای کتابخانه غیر-AOSP با نام
libfoo.soتعریف کند،libfoo.soیک DX-Lib خواهد بود.
- مثال ۱. اگر فروشندهای تابع کمکی به
بسته به عملکردهای استفادهشده توسط یک واحد، واحدها میتوانند به UA-Module و UX-Module طبقهبندی شوند.
-
ماژولهای فقط استفادهکننده از AOSP (UA-Module) فقط از عملکردهای AOSP
در پیادهسازیهایشان استفاده میکنند. آنها به هیچ افزونه غیرAOSP متکی نیستند.
- نمونه ۱. کتابخانه AOSP دستنخورده و بدون تغییر یک «واحد کاربر» است.
- نمونه ۲. اگر کتابخانه مشترک اصلاحشده
libjpeg.soفقط به دیگر «میاناهای برنامهسازی کاربردی AOSP» متکی باشد، «واحد UA» خواهد بود.
-
استفاده از واحدهای افزایه (UX-Module) در پیادهسازیهایشان به برخیاز کارکردهای غیر AOSP متکی هستند.
- نمونه ۱. اگر
libjpeg.soاصلاحشده به کتابخانه غیر-AOSP دیگری بهنامlibjpeg_turbo2.soمتکی باشد،libjpeg.soاصلاحشده یک UX-Module خواهد بود. - مثال ۲. اگر فروشندهای عملکرد جدیدی به
libexif.soاصلاحشده خود اضافه کند وlibjpeg.soاصلاحشده او از عملکرد جدید اضافهشده ازlibexif.soاستفاده کند،libjpeg.soاصلاحشده او «واحد تجربه کاربری» خواهد بود.
- نمونه ۱. اگر
تعاریف و کاربردها مستقل از یکدیگر هستند:
| کارکردهای استفادهشده | |||
|---|---|---|---|
| فقط AOSP (UA) | گسترشیافته (UX) | ||
| کارکردهای تعریفشده | فقط AOSP (DA) | DAUA | DAUX |
| گسترشیافته (DX) | DXUA | DXUX | |
سازوکار افزونه VNDK
واحدهای فروشنده که به عملکردهای گسترده متکی هستند کار نخواهند کرد زیرا کتابخانه AOSP با همان نام عملکرد گسترده را ندارد. اگر واحدهای فروشنده بهطور مستقیم یا غیرمستقیم به عملکردهای توسعهیافته وابسته باشند، فروشندگان باید کتابخانههای مشترک DAUX، DXUA، و DXUX را در پارتیشن فروشنده کپی کنند (فرایندهای فروشنده همیشه ابتدا در پارتیشن فروشنده بهدنبال کتابخانههای مشترک میگردند). بااینحال، کتابخانههای LL-NDK نباید کپی شوند، بنابراین مدولهای فروشنده نباید به عملکردهای گسترشیافته تعریفشده توسط کتابخانههای LL-NDK اصلاحشده متکی باشند.
اگر کتابخانه AOSP مربوطه بتواند همان عملکرد را ارائه دهد و واحدهای فروشنده پساز بازنویسی پارتیشن سیستم با «تصویر سیستم عمومی» (GSI) همچنان کار کنند، کتابخانههای مشترک DAUA میتوانند در پارتیشن سیستم باقی بمانند.
جایگزینی همزمان مهم است زیرا کتابخانههای VNDK بدون تغییر در GSI با کتابخانههای مشترک تغییریافته در تصادم نام پیوند خواهند داشت. اگر کتابخانههای AOSP به روشی ناسازگار با API/ABI اصلاح شوند، کتابخانههای AOSP در GSI ممکن است پیوند نخورند یا منجر به رفتارهای تعریفنشده شوند.