VNDK را فعال کنید

کیت توسعه بومی فروشنده (VNDK) برای تفکیک دغدغه‌های بین فروشنده و سیستم، نیاز به چندین تغییر در کدبیس دارد. از راهنمای زیر برای فعال‌سازی VNDK در کدبیس فروشنده/OEM استفاده کنید.

ساخت کتابخانه‌های سیستم

سیستم ساخت شامل انواع مختلفی از اشیاء از جمله کتابخانه‌ها (مشترک، استاتیک یا هدر) و فایل‌های باینری است.

ساخت کتابخانه‌های سیستم

شکل ۱. ساخت کتابخانه‌های سیستم.

  • کتابخانه‌های core توسط تصویر سیستم، روی تصویر سیستم، استفاده می‌شوند. این کتابخانه‌ها نمی‌توانند توسط کتابخانه‌های vendor ، vendor_available ، vndk یا vndk-sp استفاده شوند.
    cc_library {
        name: "libThatIsCore",
        ...
    }
  • کتابخانه‌های vendor-only (یا proprietary ) توسط تصویر فروشنده، روی تصویر فروشنده، استفاده می‌شوند.
    cc_library {
        name: "libThatIsVendorOnly",
        proprietary: true,
        # or: vendor: true, # (for things in AOSP)
        ...
    }
  • کتابخانه‌های vendor_available توسط تصویر فروشنده، روی تصویر فروشنده (ممکن است حاوی نسخه‌های تکراری از core باشد) استفاده می‌شوند.
    cc_library {
        name: "libThatIsVendorAvailable",
        vendor_available: true,
        ...
    }
  • کتابخانه‌های vndk توسط ایمیج فروشنده، روی ایمیج سیستم، استفاده می‌شوند.
    cc_library {
        name: "libThatIsVndk",
        vendor_available: true,
        vndk: {
            enabled: true,
        }
        ...
    }
  • کتابخانه‌های vndk-sp توسط ایمیج فروشنده و همچنین به طور غیرمستقیم توسط ایمیج سیستم استفاده می‌شوند.
    cc_library {
        name: "libThatIsVndkSp",
        vendor_available: true,
        vndk: {
            enabled: true,
            support_system_process: true,
        }
        ...
    }
  • کتابخانه‌های llndk هم توسط سیستم و هم توسط ایمیج‌های فروشنده استفاده می‌شوند.
    cc_library {
        name: "libThatIsLlndk",
        llndk: {
            symbol_file: "libthatisllndk.map.txt"
        }
        ...
    }

وقتی یک کتابخانه به صورت vendor_available:true علامت‌گذاری می‌شود، دو بار ساخته می‌شود:

  • یک بار برای پلتفرم (و بنابراین در /system/lib نصب شد)
  • یک بار برای فروشنده (و بنابراین در /vendor/lib یا VNDK APEX نصب می‌شود)

نسخه‌های فروشنده‌ی کتابخانه‌ها با -D__ANDROID_VNDK__ ساخته شده‌اند. اجزای سیستم خصوصی که ممکن است در نسخه‌های آینده‌ی اندروید به طور قابل توجهی تغییر کنند، با این پرچم غیرفعال می‌شوند. علاوه بر این، کتابخانه‌های مختلف مجموعه‌ی متفاوتی از هدرها را صادر می‌کنند (مانند liblog ). گزینه‌های خاص برای یک نوع فروشنده از یک هدف را می‌توان در یک فایل Android.bp در مسیر زیر مشخص کرد:

target: { vendor: { … } }

فعال کردن VNDK برای یک کدبیس

برای فعال کردن VNDK برای یک کدبیس:

  1. با محاسبه اندازه‌های مورد نیاز پارتیشن‌های vendor.img و system.img ، واجد شرایط بودن را تعیین کنید.
  2. فعال کردن BOARD_VNDK_VERSION=current . می‌توانید به BoardConfig.mk اضافه کنید یا مستقیماً با آن کامپوننت بسازید (برای مثال، m -j BOARD_VNDK_VERSION=current MY-LIB ).

پس از فعال کردن BOARD_VNDK_VERSION=current ، سیستم ساخت، الزامات وابستگی و هدر زیر را اعمال می‌کند.

مدیریت وابستگی‌ها

یک شیء vendor که به یک جزء core وابسته است که در vndk یا به عنوان یک شیء vendor وجود ندارد، باید با استفاده از یکی از گزینه‌های زیر حل شود:

  • وابستگی را می‌توان از بین برد.
  • اگر کامپوننت core متعلق به vendor باشد، می‌تواند به صورت vendor_available یا vendor علامت‌گذاری شود.
  • تغییری که شیء اصلی را به بخشی از vndk تبدیل می‌کند، ممکن است به گوگل اطلاع داده شود.

علاوه بر این، اگر یک کامپوننت core به یک کامپوننت vendor وابستگی داشته باشد، کامپوننت vendor باید به یک کامپوننت core تبدیل شود یا وابستگی باید به روش دیگری حذف شود (مثلاً با حذف وابستگی یا با انتقال وابستگی به یک کامپوننت vendor ).

مدیریت سربرگ‌ها

وابستگی‌های سراسری سرآیند باید حذف شوند تا سیستم ساخت بتواند تشخیص دهد که آیا سرآیندها را با -D__ANDROID_VNDK__ بسازد یا بدون آن. برای مثال، سرآیندهای libutils مانند utils/StrongPointer.h همچنان می‌توانند با استفاده از کتابخانه سرآیند libutils_headers قابل دسترسی باشند.

برخی از هدرها (مانند unistd.h ) دیگر نمی‌توانند به صورت انتقالی گنجانده شوند، اما می‌توانند به صورت محلی گنجانده شوند.

در نهایت، بخش عمومی private/android_filesystem_config.h به cutils/android_filesystem_config.h منتقل شده است. برای مدیریت این هدرها، یکی از موارد زیر را انجام دهید:

  • در صورت امکان، با جایگزینی تمام ماکروهای AID_* با فراخوانی‌های getgrnam / getpwnam ، وابستگی به private/android_filesystem_config.h را حذف کنید. برای مثال:
    • (uid_t)AID_WIFI تبدیل می‌شود به getpwnam("wifi")->pw_uid .
    • (gid_t)AID_SDCARD_R تبدیل می‌شود به getgrnam("sdcard_r")->gr_gid .
    برای جزئیات بیشتر، به private/android_filesystem_config.h مراجعه کنید.
  • برای AIS با کدنویسی سخت، cutils/android_filesystem_config.h را اضافه کنید.