Application.mk

این سند فایل ساخت Application.mk مورد استفاده توسط ndk-build توضیح می دهد.

توصیه می کنیم قبل از این صفحه مفاهیم را بخوانید.

نمای کلی

Application.mk تنظیمات کل پروژه را برای ndk-build مشخص می کند. به طور پیش فرض، در jni/Application.mk ، در فهرست پروژه برنامه شما قرار دارد.

متغیرها

APP_ABI

به طور پیش فرض، سیستم ساخت NDK کدی را برای همه ABI های منسوخ نشده تولید می کند. می توانید از تنظیمات APP_ABI برای تولید کد برای ABI های خاص استفاده کنید. جدول 1 تنظیمات APP_ABI را برای مجموعه های مختلف دستورالعمل نشان می دهد.

جدول 1. تنظیمات APP_ABI برای مجموعه دستورالعمل های مختلف.

مجموعه دستورالعمل ارزش
32 بیت ARMv7 APP_ABI := armeabi-v7a
64 بیتی ARMv8 (AAarch64) APP_ABI := arm64-v8a
x86 APP_ABI := x86
x86-64 APP_ABI := x86_64
همه ABI های پشتیبانی شده (پیش فرض) APP_ABI := all

شما همچنین می توانید چندین مقدار را با قرار دادن آنها در یک خط مشخص کنید که با فاصله مشخص شده اند. به عنوان مثال:

APP_ABI := armeabi-v7a arm64-v8a x86

برای لیست همه ABI های پشتیبانی شده و جزئیات استفاده و محدودیت های آنها، به ABI های Android مراجعه کنید.

APP_ASFLAGS

پرچم‌هایی که باید برای هر فایل منبع اسمبلی (فایل‌های .s و .S ) در پروژه به اسمبلر ارسال شوند.

APP_ASMFLAGS

پرچم‌هایی که برای همه فایل‌های منبع YASM (فقط .asm ، x86/x86_64) به YASM منتقل می‌شوند.

APP_BUILD_SCRIPT

به طور پیش فرض، ndk-build فرض می کند که فایل Android.mk در jni/Android.mk نسبت به ریشه پروژه قرار دارد.

برای بارگیری یک فایل Android.mk از مکان دیگری، APP_BUILD_SCRIPT را روی مسیر مطلق فایل Android.mk تنظیم کنید.

APP_CFLAGS

پرچم هایی که باید برای همه کامپایل های C/C++ در پروژه ارسال شوند.

همچنین ببینید: APP_CONLYFLAGS ، APP_CPPFLAGS .

APP_CLANG_TIDY

برای فعال کردن clang-tidy برای همه ماژول های پروژه روی true تنظیم کنید. به طور پیش فرض غیرفعال است.

APP_CLANG_TIDY_FLAGS

پرچم هایی که برای همه اجراهای مرتب در پروژه به صدا در می آیند.

APP_CONLYFLAGS

پرچم هایی که باید برای همه کامپایل های C در پروژه ارسال شوند. این پرچم ها برای کد ++C استفاده نمی شوند.

همچنین ببینید: APP_CFLAGS ، APP_CPPFLAGS .

APP_CPPFLAGS

پرچم هایی که باید برای همه کامپایل های C++ در پروژه ارسال شوند. این پرچم ها برای کد C استفاده نمی شوند.

همچنین ببینید: APP_CFLAGS ، APP_CONLYFLAGS .

APP_CXXFLAGS

مشابه APP_CPPFLAGS است، اما بعد از APP_CPPFLAGS در دستور کامپایل ظاهر می شود. به عنوان مثال:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

پیکربندی بالا منجر به یک دستور کامپایل مشابه با clang++ -DFOO -DBAR به جای clang++ -DBAR -DFOO می‌شود.

APP_DEBUG

برای ساختن یک اپلیکیشن قابل اشکال زدایی روی true تنظیم کنید.

APP_LDFLAGS

پرچم هایی که باید هنگام پیوند دادن فایل های اجرایی و کتابخانه های مشترک ارسال شوند.

APP_MANIFEST

مسیر مطلق به یک فایل AndroidManifest.xml.

به‌طور پیش‌فرض، $(APP_PROJECT_PATH)/AndroidManifest.xml) در صورت وجود استفاده می‌شود.

APP_MODULES

یک لیست صریح از ماژول ها برای ساخت. عناصر این لیست، نام ماژول‌هایی است که در LOCAL_MODULE در فایل Android.mk ظاهر می‌شوند.

به طور پیش فرض، ndk-build تمام کتابخانه های مشترک، فایل های اجرایی و وابستگی های آنها را می سازد. کتابخانه‌های استاتیک تنها در صورتی ساخته می‌شوند که توسط پروژه استفاده شوند، پروژه فقط شامل کتابخانه‌های ثابت باشد، یا اگر در APP_MODULES نامگذاری شده باشند.

APP_OPTIM

این متغیر اختیاری را به صورت release یا debug تعریف کنید. باینری های انتشار به طور پیش فرض ساخته می شوند.

حالت انتشار بهینه‌سازی‌ها را فعال می‌کند و ممکن است باینری‌هایی تولید کند که با اشکال‌زدا قابل استفاده نباشند. حالت Debug بهینه‌سازی را غیرفعال می‌کند تا از اشکال‌زدایی‌ها استفاده شود.

توجه داشته باشید که می‌توانید باینری‌های انتشار یا اشکال‌زدایی را اشکال‌زدایی کنید. با این حال، باینری‌های انتشار اطلاعات کمتری را در حین اشکال‌زدایی ارائه می‌کنند. برای مثال، متغیرها ممکن است بهینه شوند و از بازرسی جلوگیری کنند. همچنین، مرتب سازی مجدد کد می تواند گام برداشتن در کد را دشوارتر کند. ردیابی پشته ممکن است قابل اعتماد نباشد.

اعلام android:debuggable در تگ <application> مانیفست برنامه شما باعث می شود که این متغیر به جای release به طور پیش فرض debug . با تنظیم APP_OPTIM برای release ، این مقدار پیش‌فرض را لغو کنید.

APP_PLATFORM

APP_PLATFORM سطح API Android را اعلام می کند که این برنامه بر اساس آن ساخته شده است و مطابق با minSdkVersion برنامه است.

اگر مشخص نشده باشد، ndk-build حداقل سطح API پشتیبانی شده توسط NDK را هدف قرار می دهد. حداقل سطح API پشتیبانی شده توسط آخرین NDK همیشه به اندازه کافی پایین خواهد بود که تقریباً از همه دستگاه های فعال پشتیبانی کند.

برای مثال، مقدار android-16 مشخص می‌کند که کتابخانه شما از APIهایی استفاده می‌کند که زیر Android 4.1 (سطح API 16) موجود نیستند و نمی‌توانند در دستگاه‌هایی که نسخه پلتفرم پایین‌تری دارند استفاده شود. برای فهرست کاملی از نام‌های پلتفرم و تصاویر مربوط به سیستم Android، APIهای اصلی Android NDK را ببینید.

هنگام استفاده از Gradle و externalNativeBuild ، این پارامتر نباید مستقیماً تنظیم شود. در عوض، ویژگی minSdkVersion را در بلوک های defaultConfig یا productFlavors فایل build.gradle سطح ماژول خود تنظیم کنید. این اطمینان حاصل می‌کند که کتابخانه شما فقط توسط برنامه‌های نصب شده روی دستگاه‌هایی که دارای نسخه کافی Android هستند استفاده می‌شود.

توجه داشته باشید که NDK شامل کتابخانه‌هایی برای هر سطح API اندروید نیست. نسخه‌هایی که شامل APIهای بومی جدید نیستند، برای صرفه‌جویی در فضا در NDK حذف می‌شوند. ndk-build به ترتیب ترجیحی نزولی استفاده می کند:

  1. نسخه پلتفرم مطابق با APP_PLATFORM .
  2. سطح API موجود بعدی زیر APP_PLATFORM . برای مثال، android-19 زمانی استفاده می‌شود که APP_PLATFORM android-20 باشد، زیرا هیچ API بومی جدیدی در android-20 وجود ندارد.
  3. حداقل سطح API پشتیبانی شده توسط NDK.

APP_PROJECT_PATH

مسیر مطلق دایرکتوری ریشه پروژه.

APP_SHORT_COMMANDS

معادل LOCAL_SHORT_COMMANDS در کل پروژه. برای اطلاعات بیشتر، به مستندات LOCAL_SHORT_COMMANDS در Android.mk مراجعه کنید.

APP_STL

کتابخانه استاندارد C++ برای استفاده برای این برنامه.

system STL به طور پیش فرض استفاده می شود. گزینه های دیگر عبارتند از c++_shared ، c++_static ، و none . زمان‌ها و ویژگی‌های NDK C++ را ببینید.

APP_STRIP_MODE

آرگومانی که باید به strip برای ماژول های این برنامه منتقل شود. پیش‌فرض‌ها به --strip-unneeded . برای جلوگیری از حذف همه باینری ها در ماژول، روی none تنظیم کنید. برای سایر حالت‌های نوار، به مستندات نوار مراجعه کنید.

APP_THIN_ARCHIVE

برای استفاده از آرشیوهای نازک برای همه کتابخانه های استاتیک در پروژه، روی true تنظیم کنید. برای اطلاعات بیشتر، به مستندات LOCAL_THIN_ARCHIVE در Android.mk مراجعه کنید.

APP_WRAP_SH

مسیر فایل wrap.sh که باید در این برنامه گنجانده شود.

یک نوع از این متغیر برای هر ABI وجود دارد، همانطور که یک نوع عمومی ABI نیز وجود دارد:

  • APP_WRAP_SH
  • APP_WRAP_SH_armeabi-v7a
  • APP_WRAP_SH_arm64-v8a
  • APP_WRAP_SH_x86
  • APP_WRAP_SH_x86_64