فضای نام برای کتابخانه های بومی

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

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 COMPANYNAME.so نامیده شوند، برای مثال libFoo.awesome.company.so . به عبارت دیگر، libFoo.so بدون پسوند نام شرکت نباید عمومی شود. COMPANYNAME در نام فایل کتابخانه باید با COMPANYNAME در نام فایل txt که نام کتابخانه در آن فهرست شده است مطابقت داشته باشد.

کتابخانه های بومی که بخشی از AOSP هستند نباید عمومی شوند (به جز کتابخانه های بومی عمومی استاندارد که به طور پیش فرض عمومی هستند). فقط کتابخانه‌های اضافی اضافه‌شده توسط فروشندگان سیلیکون یا سازندگان دستگاه‌ها را می‌توان در دسترس برنامه‌ها قرار داد.

از Android 8.0، کتابخانه‌های عمومی فروشنده محدودیت‌های اضافی و تنظیمات لازم زیر را دارند:

  1. کتابخانه بومی در فروشنده باید به درستی برچسب گذاری شده باشد تا برای برنامه ها قابل دسترسی باشد. اگر برای هر برنامه ای (از جمله برنامه های شخص ثالث) به دسترسی نیاز باشد، کتابخانه باید به عنوان same_process_hal_file در فایل file_contexts خاص فروشنده به صورت زیر برچسب گذاری شود:
    /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
    که در آن libnative.so نام کتابخانه بومی است.
  2. کتابخانه، چه به طور مستقیم یا گذرا از طریق وابستگی های خود، نباید به کتابخانه های سیستمی به جز کتابخانه های VNDK-SP و LLNDK وابسته باشد. لیست کتابخانه های VNDK-SP و LLNDK را در development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv .

به روز رسانی برنامه ها برای استفاده نکردن از کتابخانه های بومی غیر عمومی

این ویژگی فقط برای برنامه هایی فعال است که SDK نسخه 24 یا بالاتر را هدف قرار می دهند. برای سازگاری با عقب، به جدول 1 مراجعه کنید. اگر برنامه شما در برابر کتابخانه‌های بومی خصوصی پیوند می‌یابد چه انتظاری باید داشت . فهرست کتابخانه‌های بومی Android قابل دسترسی برای برنامه‌ها (همچنین به عنوان کتابخانه‌های بومی عمومی شناخته می‌شوند) در بخش CDD 3.1.1 فهرست شده است. برنامه هایی که 24 یا بالاتر را هدف قرار می دهند و از کتابخانه های غیر عمومی استفاده می کنند باید به روز شوند. برای جزئیات بیشتر، پیوند برنامه‌های NDK به کتابخانه‌های پلتفرم را ببینید.

به روز رسانی برنامه ها برای وابستگی های کتابخانه بومی آنها

برنامه‌هایی که SDK نسخه 31 (Android 12) یا بالاتر را هدف قرار می‌دهند، باید وابستگی‌های کتابخانه مشترک بومی خود را با استفاده از <uses-native-library> در مانیفست برنامه به صراحت مشخص کنند. اگر بخشی از کتابخانه درخواستی در دستگاه وجود نداشته باشد، برنامه نصب نمی‌شود. وقتی برنامه‌ها نصب می‌شوند، فقط کتابخانه‌های مشترک بومی که درخواست کرده‌اند در اختیارشان قرار می‌گیرد. این بدان معناست که برنامه‌ها نمی‌توانند به کتابخانه‌های مشترک بومی که در مانیفست برنامه ظاهر نمی‌شوند دسترسی داشته باشند.