Application.mk

يوضّح هذا المستند ملف إصدار Application.mk الذي يستخدمه ndk-build.

ننصحك بقراءة صفحة المفاهيم قبل هذا التاريخ. واحد.

نظرة عامة

تحدِّد Application.mk الإعدادات على مستوى المشروع في ndk-build. بشكل افتراضي، موجودة في jni/Application.mk، في دليل مشروع التطبيق.

ملاحظة: لدى العديد من هذه المعلَمات أيضًا مكافئ لكل وحدة. على سبيل المثال: APP_CFLAGS يتجاوب مع LOCAL_CFLAGS. في كل حالة، إن النموذج الخاص بالوحدة على الخيار على مستوى التطبيق. بالنسبة إلى العلامات، يتم ولكن العلامات الخاصة بالوحدة ستظهر لاحقًا في سطر الأوامر بحيث قد يلغي ذلك الإعدادات على مستوى المشروع.

المتغيّرات

APP_ABI

ينشئ نظام إصدار NDK تلقائيًا رمزًا لجميع واجهات التطبيق الثنائية (ABI) التي لم يتم إيقافها نهائيًا. إِنْتَ استخدام الإعداد APP_ABI لإنشاء رمز لواجهات تطبيقات ثنائية (ABI) محدّدة. يظهر الجدول 1 إعدادات APP_ABI لمجموعات التعليمات المختلفة.

الجدول 1: إعدادات "APP_ABI" لمجموعات التعليمات المختلفة

مجموعة التعليمات	القيمة
ARMv7 32 بت	APP_ABI := armeabi-v7a
64-bit ARMv8 (AArch64)	APP_ABI := arm64-v8a
×86	APP_ABI := x86
X86- 64	APP_ABI := x86_64
جميع واجهات التطبيق الثنائية (ABI) المتوافقة (تلقائيًا)	APP_ABI := all

يمكنك أيضًا تحديد قيم متعددة بوضعها على نفس السطر، محدد باستخدام المسافات. مثلاً:

APP_ABI := armeabi-v7a arm64-v8a x86

ملاحظة: يتم تجاهل APP_ABI من خلال externalNativeBuild مخطَّط Gradle. بدلاً من ذلك، استخدم حظر abiFilters أو (في حال استخدام "حِزم APK متعددة") حظر abi داخل حظر "splits"

للحصول على قائمة بجميع واجهات ABI المتوافقة والتفاصيل حول استخدامها يُرجى الرجوع إلى واجهات التطبيق الثنائية (ABI) في Android.

تطبيقات_ASFLAGS

العلامات التي يجب تمريرها إلى المجمّع لكل ملف مصدر تجميع (.s .S ملف) في المشروع.

ملاحظة: يختلف الاسم ASFLAGS عن ASMFLAGS. ينطبق هذا الأخير تحديدًا على ملفات مصدر YASM (راجِع القسم حول APP_ASMFLAGS)

التطبيق_ASMFLAGS

يجب تمرير علامات إلى YASM في حال كانت جميع ملفات مصدر YASM (.asm وx86/x86_64 فقط).

APP_BUILD_script

بشكل تلقائي، يفترض ndk-build أن ملف Android.mk موجود على jni/Android.mk بالنسبة إلى جذر المشروع.

لتحميل ملف Android.mk من موقع مختلف، اضبط APP_BUILD_SCRIPT. إلى المسار المطلق لملف Android.mk.

ملاحظة: ستهيئ externalNativeBuild التابعة لـ Gradle هذه تلقائيًا استنادًا إلى متغيّر externalNativeBuild.ndkBuild.path.

التطبيقات_CFLAGS

علامات يجب تمريرها لجميع عمليات التجميع بلغة C/C++ في المشروع.

ملاحظة: يجب أن تستخدم المسارات "LOCAL_C_INCLUDES" بدلاً من "-I" الفاضح. بلاغات.

راجِع أيضًا: APP_CONLYFLAGS وAPP_CPPFLAGS.

APP_Cالعربية_TIDY

يمكنك الضبط على true لتفعيل ميزة clang tidy لجميع الوحدات في المشروع. تم الإيقاف من قِبل الافتراضي.

APP_Cالعربية_TIDY_FLAGS

علامات يجب تمريرها لجميع عمليات التنفيذ المرتبة في المشروع.

أعلام APP_CONLYFLAGS

علامات يجب تمريرها لجميع مجموعات C في المشروع. لن يتم وصف هذه العلامات يُستخدم في تعليمة C++.

راجِع أيضًا: APP_CFLAGS وAPP_CPPFLAGS.

APP_CPPFLAGS

علامات يجب تمريرها لكل عمليات تجميع C++ في المشروع. لن يتم وصف هذه العلامات يُستخدم للترميز C.

راجِع أيضًا: APP_CFLAGS وAPP_CONLYFLAGS.

APP_CXXFLAGS

ملاحظة: يجب تفضيل APP_CPPFLAGS على APP_CXXFLAGS.

مماثلة لـ APP_CPPFLAGS، ولكنها ستظهر بعد APP_CPPFLAGS في التجميع الأمر. مثلاً:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

ستؤدي الإعدادات أعلاه إلى إنشاء أمر تجميع مماثل للرمز clang++ -DFOO -DBAR بدلاً من clang++ -DBAR -DFOO.

تطبيق_تصحيح الأخطاء

عليك الضبط على "صحيح" لإنشاء تطبيق يمكن تصحيح الأخطاء فيه.

APP_LDFLAGS

علامات يتم تمريرها عند ربط الملفات التنفيذية والمكتبات المشتركة

ملاحظة: ليس لهذه العلامات أي تأثير في المكتبات الثابتة. المكتبات الثابتة غير مرتبطة

بيان التطبيق

المسار المطلق لملف AndroidManifest.xml.

سيتم استخدام $(APP_PROJECT_PATH)/AndroidManifest.xml) تلقائيًا في حال: الموجودة.

ملاحظة: عند استخدام externalNativeBuild، لن يتم ضبط هذه القيمة بواسطة Gradle.

وحدات التطبيقات

تمثّل هذه السمة قائمة واضحة بالوحدات المطلوب إنشاؤها. عناصر هذه القائمة هي أسماء الوحدات كما تظهر في LOCAL_MODULE ضمن ملف Android.mk.

بشكل افتراضي، ستنشئ ndk-build جميع المكتبات والملفات التنفيذية و والتبعيات لديك. سيتم إنشاء المكتبات الثابتة فقط إذا تم استخدامها بواسطة قد يحتوي المشروع على مكتبات ثابتة فقط أو إذا كانت محددة في APP_MODULES

ملاحظة: لن يتم إنشاء الوحدات المستوردة (المحدّدة في النصوص البرمجية للإصدار المستورَدة باستخدام $(call import-module) ما لم يتم الاعتماد عليها على وحدة سيتم إنشاؤها أو مدرجة في APP_MODULES.

APP_OPTIM

حدِّد هذا المتغيّر الاختياري على أنّه release أو debug. إصدار البرامج الثنائية سيتم إنشاءه افتراضيًا.

يعمل وضع الإصدار على تفعيل التحسينات وقد ينتج عنه برامج ثنائية غير قابلة للاستخدام باستخدام برنامج تصحيح الأخطاء. يوقف وضع تصحيح الأخطاء التحسينات بحيث قد تتم معالجة برامج تصحيح الأخطاء استخدام البيانات المختلفة.

لاحظ أنه يمكنك تصحيح أخطاء الإصدارات الثنائية أو تصحيح الأخطاء. إصدار البرامج الثنائية، قدِّم معلومات أقل أثناء تصحيح الأخطاء. على سبيل المثال، قد تحسينه، مما يمنع الفحص. ويمكن أن تؤدي إعادة ترتيب الرموز أيضًا إلى زيادة يصعب التنقل عبر التعليمات البرمجية؛ قد لا تكون عمليات تتبُّع تسلسل استدعاء الدوال البرمجية موثوقًا بها.

تعريف android:debuggable ضمن <application> في بيان التطبيق ستؤدي إلى ضبط هذا المتغير على الإعداد التلقائي debug بدلاً من release. يمكنك إلغاء هذه القيمة التلقائية من خلال ضبط APP_OPTIM على release.

ملاحظة: عند إنشاء الملفات باستخدام externalNativeBuild، سيضبط "استوديو Android" هذا وضَع علامة عليه بشكل مناسب استنادًا إلى نكهة تصميمك.

هذه المنصة

يُشير APP_PLATFORM إلى مستوى واجهة برمجة تطبيقات Android الذي تم إنشاء هذا التطبيق وفقًا له ويتوافق مع minSdkVersion في التطبيق.

في حال عدم تحديد هذا الخيار، ستستهدف ndk-build الحد الأدنى لمستوى واجهة برمجة التطبيقات الذي تتوافق معه NDK. سيكون دائمًا الحد الأدنى لمستوى واجهة برمجة التطبيقات المتوافق مع أحدث إصدار من NDK منخفضًا بما يكفي للتوافق مع جميع الأجهزة النشطة تقريبًا.

تحذير: ضبط APP_PLATFORM على قيمة أعلى من minSdkVersion للتطبيق إلى إنشاء تطبيق لن يعمل على الأجهزة القديمة. في معظم الحالات التي سيفشل فيها المكتبات في التحميل لأنها تشير إلى رموز غير متوفّرة على الأجهزة القديمة

على سبيل المثال، تشير القيمة android-16 إلى أنّ مكتبتك تستخدم واجهات برمجة تطبيقات لا تتوفّر هذه الميزة في إصدارات أقدم من Android 4.1 (المستوى 16 لواجهة برمجة التطبيقات) ولا يمكن استخدامها على الأجهزة. بتشغيل إصدار نظام أساسي منخفض. للحصول على قائمة كاملة بأسماء المنصات صور نظام Android المقابلة، يمكنك الاطّلاع على الإصدار الأصلي من Android NDK API.

عند استخدام Gradle وexternalNativeBuild، يجب عدم ضبط هذه المَعلمة مباشرةً. يمكنك بدلاً من ذلك ضبط السمة minSdkVersion في defaultConfig أو productFlavors جزء من ملف build.gradle على مستوى الوحدة. هذا النمط للتأكد من عدم استخدام مكتبتك إلا بواسطة التطبيقات المثبتة على الأجهزة التي تشغِّل إصدار ملائم من Android.

تجدر الإشارة إلى أنّ NDK لا يحتوي على مكتبات لكل مستوى من مستويات واجهة برمجة التطبيقات في Android. يتم حذف الإصدارات التي لا تتضمن واجهات برمجة تطبيقات أصلية جديدة لتوفير مساحة في NDK. استخدامات ndk-build، بترتيب تنازلي للتفضيل:

1. إصدار النظام الأساسي المطابق لـ APP_PLATFORM
2. المستوى التالي المتاح لواجهة برمجة التطبيقات ضِمن APP_PLATFORM. على سبيل المثال: android-19 سيتم استخدام عندما تكون قيمة الحقل "APP_PLATFORM" هي android-20، نظرًا لعدم توفّر معلومات جديدة واجهات برمجة التطبيقات الأصلية في android-20.
3. الحد الأدنى لمستوى واجهة برمجة التطبيقات المتوافق مع NDK.

مسار_المشروع_التطبيق

يشير ذلك المصطلح إلى المسار المطلق للدليل الجذري للمشروع.

APP_SHORT_CommandS

يعادل LOCAL_SHORT_COMMANDS على مستوى المشروع. لمزيد من المعلومات، يُرجى مراجعة مستندات LOCAL_SHORT_COMMANDS في Android.mk.

APP_STL

مكتبة C++ القياسية التي سيتم استخدامها لهذا التطبيق.

يتم استخدام STL system بشكل تلقائي. تشمل الخيارات الأخرى c++_shared، c++_static وnone راجع بيئات تشغيل NDK C++ الميزات.

وضع APP_STRIP_mode

يجب تمرير الوسيطة إلى strip للوحدات في هذا التطبيق. الإعدادات التلقائية إلى --strip-unneeded. لتجنب إزالة كل البرامج الثنائية في الوحدة، قم بالتعيين على none بالنسبة إلى أوضاع الشريط الأخرى، يمكنك الاطّلاع على الشريط ذات الصلة.

تطبيق_THIN_ARCHIVE

اضبط على "صحيح" لاستخدام الأرشيفات الرقيقة لجميع المكتبات الثابتة في المشروع. بالنسبة مزيد من المعلومات، راجِع المستندات الخاصة بـ 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

ملاحظة: قد لا يتم دمج APP_WRAP_SH_<abi> مع APP_WRAP_SH. في حال توفُّر أي واجهة ABI يستخدم wrap.sh خاص بـ ABI، فيجب أن يتم استخدام جميع واجهات ABI.