Android 7.0 فضاهای نامی را برای کتابخانه‌های بومی معرفی کرد تا دید API داخلی را محدود کند و موقعیت‌هایی را که برنامه‌ها به طور تصادفی از کتابخانه‌های پلتفرم استفاده می‌کنند، حل کند. برای تغییرات خاص برنامه، به بهبود پایداری با محدودیت‌های نماد C/C++ خصوصی در وبلاگ Android 7.0 Android Developers مراجعه کنید.
معماری
در اندروید 7.0 و بالاتر، کتابخانه‌های سیستم از کتابخانه‌های برنامه جدا می‌شوند.
شکل 1. فضای نام برای کتابخانه های بومی.
فضای نام برای کتابخانه های بومی مانع از استفاده برنامه ها از API های بومی پلتفرم خصوصی می شود (همانطور که با OpenSSL انجام شد). همچنین موقعیت‌هایی را که برنامه‌ها به‌طور تصادفی از کتابخانه‌های پلتفرم به جای کتابخانه خودشان استفاده می‌کنند، حذف می‌کند (همانطور که در libpng مشاهده شد). استفاده تصادفی از کتابخانه های سیستم داخلی برای کتابخانه های برنامه دشوار است (و بالعکس).
کتابخانه های بومی اضافی اضافه کنید
علاوه بر کتابخانه‌های بومی عمومی استاندارد، فروشندگان سیلیکون (از Android 7.0 شروع می‌شوند) و تولیدکنندگان دستگاه (شروع از Android 9) ممکن است با قرار دادن آنها در زیر پوشه‌های کتابخانه مربوطه و فهرست کردن صریح آنها در txt. کتابخانه‌های بومی دیگری را برای دسترسی به برنامه‌ها ارائه کنند. فایل ها
پوشه های کتابخانه عبارتند از:
-
/vendor/lib(برای 32 بیت) و/vendor/lib64(برای 64 بیت) برای کتابخانه‌های تولیدکنندگان سیلیکون -
/system/lib(برای 32 بیت) و/system/lib64(برای 64 بیت) برای کتابخانه‌های تولیدکنندگان دستگاه
فایل های txt عبارتند از:
-
/vendor/etc/public.libraries.txtبرای کتابخانه های فروشندگان سیلیکون -
/system/etc/public.libraries-COMPANYNAME.txtبرای کتابخانه‌های تولیدکنندگان دستگاه، که در آنCOMPANYNAMEبه نام سازنده اشاره می‌کند (مانندawesome.company).COMPANYNAMEباید با[A-Za-z0-9_.-]+مطابقت داشته باشد. کاراکترهای الفبایی، _، . (نقطه) و -. اگر برخی از کتابخانه ها از ارائه دهندگان راه حل خارجی باشند، می توان چندین فایل از این قبیل .txt را در یک دستگاه داشت.
کتابخانه‌های بومی در پارتیشن system که توسط سازندگان دستگاه عمومی می‌شوند، باید lib*COMPANYNAME.so نامیده شوند، برای مثال libFoo.awesome.company.so . به عبارت دیگر، libFoo.so بدون پسوند نام شرکت نباید عمومی شود. COMPANYNAME در نام فایل کتابخانه باید با COMPANYNAME در نام فایل txt که نام کتابخانه در آن فهرست شده است مطابقت داشته باشد.
کتابخانه های بومی که بخشی از AOSP هستند نباید عمومی شوند (به جز کتابخانه های بومی عمومی استاندارد که به طور پیش فرض عمومی هستند). فقط کتابخانه‌های اضافی اضافه‌شده توسط فروشندگان سیلیکون یا سازندگان دستگاه‌ها را می‌توان در دسترس برنامه‌ها قرار داد.
از Android 8.0، کتابخانه‌های عمومی فروشنده محدودیت‌های اضافی و تنظیمات لازم زیر را دارند:
- کتابخانه بومی در فروشنده باید به درستی برچسب گذاری شده باشد تا برای برنامه ها قابل دسترسی باشد. اگر برای هر برنامه ای (از جمله برنامه های شخص ثالث) به دسترسی نیاز باشد، کتابخانه باید به صورت
same_process_hal_fileدر فایلfile_contextsخاص فروشنده به صورت زیر برچسب گذاری شود:/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
libnative.soنام کتابخانه بومی است. - کتابخانه، چه به طور مستقیم یا گذرا از طریق وابستگی های خود، نباید به کتابخانه های سیستمی غیر از کتابخانه های VNDK-SP و LLNDK وابسته باشد. لیست کتابخانه های VNDK-SP و LLNDK را در
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csvبیابید.
با شروع از Android 15، کتابخانه های عمومی فروشنده را می توان در یک فروشنده APEX قرار داد. هنگامی که در یک فروشنده APEX بسته بندی می شود، کتابخانه ها را در یک ویژگی provideNativeLibs در مانیفست APEX فهرست کنید.
برنامه ها را به روز کنید تا از کتابخانه های بومی غیرعمومی استفاده نکنید
این ویژگی فقط برای برنامه هایی فعال است که SDK نسخه 24 یا بالاتر را هدف قرار می دهند. برای سازگاری با عقب، به جدول 1 مراجعه کنید. اگر برنامه شما در برابر کتابخانه‌های بومی خصوصی پیوند می‌یابد چه انتظاری باید داشت . فهرست کتابخانه‌های بومی Android قابل دسترسی برای برنامه‌ها (همچنین به عنوان کتابخانه‌های بومی عمومی شناخته می‌شوند) در بخش CDD 3.1.1 فهرست شده است. برنامه هایی که 24 یا بالاتر را هدف قرار می دهند و از کتابخانه های غیر عمومی استفاده می کنند باید به روز شوند. برای جزئیات بیشتر، پیوند برنامه‌های NDK به کتابخانه‌های پلتفرم را ببینید.
برنامه ها را برای وابستگی های کتابخانه بومی آنها به روز کنید
برنامه‌هایی که SDK نسخه 31 (Android 12) یا بالاتر را هدف قرار می‌دهند، باید وابستگی‌های کتابخانه مشترک بومی خود را با استفاده از برچسب <uses-native-library> در مانیفست برنامه به صراحت مشخص کنند . اگر بخشی از کتابخانه درخواستی در دستگاه وجود نداشته باشد، برنامه نصب نمی‌شود. وقتی برنامه‌ها نصب می‌شوند، فقط کتابخانه‌های مشترک بومی که درخواست کرده‌اند در اختیارشان قرار می‌گیرد. این بدان معناست که برنامه‌ها نمی‌توانند به کتابخانه‌های مشترک بومی که در مانیفست برنامه ظاهر نمی‌شوند دسترسی داشته باشند.