این سند فایل ساخت 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 به ترتیب ترجیحی نزولی استفاده می کند:
- نسخه پلتفرم مطابق با
APP_PLATFORM
. - سطح API موجود بعدی زیر
APP_PLATFORM
. برای مثال،android-19
زمانی استفاده میشود کهAPP_PLATFORM
android-20
باشد، زیرا هیچ API بومی جدیدی در android-20 وجود ندارد. - حداقل سطح 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