Android.mk

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

نظرة عامة

يتوفّر ملف Android.mk في دليل فرعي من دليل jni/ الخاص بمشروعك، ويصف هذا الملف مصادرك والمكتبات المشتركة لنظام الإنشاء. وهو في الواقع جزء صغير من ملف makefile في GNU يفكّكه نظام الإنشاء مرة واحدة أو أكثر. يُعد ملف Android.mk مفيدًا لتحديد الإعدادات على مستوى المشروع التي يتبقى Application.mk ونظام التصميم ومتغيرات البيئة. غير محددة. ويمكنها أيضًا إلغاء الإعدادات على مستوى المشروع للوحدات المحدّدة.

تتيح لك بنية Android.mk تجميع مصادرك في وحدات. الوحدة هي إما مكتبة ثابتة أو مكتبة مشتركة أو ملف تنفيذي مستقل. يمكنك تحديد وحدة واحدة أو أكثر في كل ملف Android.mk، ويمكنك استخدام ملف المصدر نفسه في وحدات متعددة. نظام التصميم فقط تضع المكتبات المشتركة في حزمة التطبيق الخاصة بك. بالإضافة إلى ذلك، يمكن للمكتبات إنشاء مكتبات مشتركة.

بالإضافة إلى حزم المكتبات، يعالج نظام الإنشاء مجموعة متنوعة من التفاصيل الأخرى نيابةً عنك. على سبيل المثال، لا تحتاج إلى إدراج ملفات الرأس أو التبعيات الواضحة بين الملفات التي تم إنشاؤها في ملف Android.mk. يحسب نظام إنشاء NDK هذه العلاقات تلقائيًا نيابةً عنك. نتيجةً لذلك، من المفترض أن تتمكّن من الاستفادة من التوافق الجديد مع سلسلة الأدوات أو النظام الأساسي في الإصدارات القادمة من NDK بدون الحاجة إلى تعديل ملف Android.mk.

تشبه بنية هذا الملف إلى حد كبير البنية المستخدَمة في ملفات Android.mk الموزَّعة مع مشروع Android Open Source Project الكامل. على الرغم من أنّ نظام الإنشاء الذي يستخدمهما مختلف، إلا أنّ تشابههما هو قرار intentional تصميمي يهدف إلى تسهيل إعادة استخدام الرمز المصدر للمكتبات الخارجية من قِبل مطوّري التطبيقات.

الأساسيات

قبل استكشاف بناء الجملة بالتفصيل، من المفيد البدء بفهم أساسيات محتوى ملف Android.mk. يستخدم هذا القسم Android.mk في نموذج Hello-JNI نحو تلك النهاية، لتوضيح الدور يتم تشغيل كل سطر في الملف فيه.

يجب أن يبدأ ملف Android.mk بتحديد المتغيّر LOCAL_PATH:

LOCAL_PATH := $(call my-dir)

يشير هذا المتغيّر إلى موقع الملفات المصدر في شجرة التطوير. في هذه الحالة، تُرجع دالة الماكرو my-dir، التي يوفّرها نظام الإنشاء، مسار الدليل الحالي (الدليل الذي يحتوي على ملفAndroid.mk نفسه).

يعرِض السطر التالي المتغيّر CLEAR_VARS الذي يقدّم نظام الإنشاء قيمته.

include $(CLEAR_VARS)

يشير المتغير CLEAR_VARS إلى ملف GNU Makefile خاص يحذف العديد متغيرات LOCAL_XXX لك، مثل LOCAL_MODULE وLOCAL_SRC_FILES و LOCAL_STATIC_LIBRARIES يُرجى العِلم أنّه لا يتم محو LOCAL_PATH. هذا النمط يجب أن يحتفظ المتغير بقيمته لأن النظام يحلل جميع ملفات التحكم في الإصدار في سياق تنفيذ GNU واحد تكون فيه جميع المتغيرات عمومية. يجب (إعادة) تعريف هذا المتغيّر قبل وصف كل وحدة.

بعد ذلك، يخزن المتغير LOCAL_MODULE اسم الوحدة التي تريد استخدم هذا المتغير مرة واحدة لكل وحدة في التطبيق.

LOCAL_MODULE := hello-jni

يجب أن يكون اسم كل وحدة فريدًا وألا يحتوي على أي مسافات. يعتمد نظام التصميم، عند إنشاء ملف المكتبة المشتركة النهائي، يضيف تلقائيًا بادئة ولاحقة إلى الاسم الذي تحدّده للسمة LOCAL_MODULE. على سبيل المثال، يؤدي المثال الذي يظهر أعلاه إلى إنشاء مكتبة باسم libhello-jni.so.

يسرد السطر التالي ملفات المصدر، مع ترك مسافات بين ملفات متعددة:

LOCAL_SRC_FILES := hello-jni.c

يجب أن يحتوي المتغيّر LOCAL_SRC_FILES على قائمة بملفات المصدر C و/أو C++. لتضمينها في وحدة.

يساعد السطر الأخير النظام في ربط كل شيء معًا:

include $(BUILD_SHARED_LIBRARY)

يشير المتغيّر BUILD_SHARED_LIBRARY إلى نص برمجي لملف GNU Makefile يجمع جميع المعلومات التي حدّدتها في متغيّرات LOCAL_XXX منذinclude الأكثر حداثة. يحدّد هذا النص البرمجي ما يجب إنشائه وكيفية تنفيذه.

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

المتغيّرات ووحدات الماكرو

يوفّر نظام التصميم العديد من المتغيرات المحتمَلة لاستخدامها في ملف Android.mk. وتأتي العديد من هذه المتغيّرات مع قيم محدّدة مسبقًا. أما العناصر الأخرى، فيمكنك تحديدها بنفسك.

بالإضافة إلى هذه المتغيّرات، يمكنك أيضًا تحديد المتغيّرات العشوائية الخاصة بك. إذا قمت بذلك، ضع مع الأخذ في الاعتبار أن نظام إصدار NDK يحتفظ بأسماء المتغيرات التالية:

  • الأسماء التي تبدأ بـ LOCAL_، مثل LOCAL_MODULE
  • الأسماء التي تبدأ بـ PRIVATE_ أو NDK_ أو APP يستخدم نظام الإنشاء هذه الإعدادات داخليًا.
  • الأسماء المكتوبة بأحرف صغيرة، مثل my-dir. ويستخدم نظام التصميم هذه الميزات داخليًا، حيث أيضًا.

إذا كنت بحاجة إلى تحديد متغيّرات تسهيل الاستخدام في ملف Android.mk، ننصحك بprepending MY_ إلى أسمائها.

متغيّرات تضمين محدّدة من NDK

يتناول هذا القسم متغيّرات GNU Make التي يحدّدها نظام الإنشاء قبل تحليل ملف Android.mk. في ظل ظروف معينة، يتراجع NDK قد يحلّل ملف Android.mk الخاص بك عدّة مرات باستخدام تعريف مختلف. لبعض هذه المتغيرات في كل مرة.

محو

يشير هذا المتغيّر إلى نص برمجي للإنشاء يلغِي تحديد جميع متغيّرات LOCAL_XXX تقريبًا المدرَجة في قسم "المتغيّرات التي يحدّدها المطوّر" أدناه. استخدام هذه المسودة لتضمين هذا البرنامج النصي قبل وصف وحدة جديدة. بناء الجملة يتم استخدامها وهي:

include $(CLEAR_VARS)

إنشاء_قابلة للتنفيذ

يشير هذا المتغير إلى نص برمجي للإنشاء يجمع كل المعلومات حول الوحدة التي وفّرتها في متغيّرات LOCAL_XXX، وتحدّد كيفية إنشاء هدف قابل للتنفيذ من المصادر التي أدرجتها. يُرجى العِلم أنّ استخدام هذا الرمز المبرمَج يتطلّب منك تحديد قيم للمتغيّرينLOCAL_MODULE و LOCAL_SRC_FILES على الأقل (لمزيد من المعلومات عن هذين المتغيّرين، يُرجى الاطّلاع على متغيّرات وصف الوحدة).

بناء الجملة لاستخدام هذا المتغير هو:

include $(BUILD_EXECUTABLE)

BUILD_SHARED_LIBRARY

يشير هذا المتغيّر إلى نص برمجي للإنشاء يجمع كل المعلومات عن الوحدة التي قدّمتها في متغيّرات LOCAL_XXX، ويحدّد كيفية إنشاء مكتبة مشترَكة مستهدَفة من المصادر التي أدرجتها. يُرجى العِلم أنّ استخدام هذا الرمز المبرمَج يتطلّب منك تحديد قيم للمتغيّرينLOCAL_MODULE و LOCAL_SRC_FILES على الأقل (لمزيد من المعلومات عن هذين المتغيّرين، يُرجى الاطّلاع على متغيّرات وصف الوحدة).

بناء الجملة لاستخدام هذا المتغيّر هو:

include $(BUILD_SHARED_LIBRARY)

يؤدي متغيّر المكتبة المشتركة إلى أن ينشئ نظام الإنشاء ملف مكتبة بإضافة .so.

BUILD_STATIC_LIBRARY

تمثّل هذه السمة صيغة من BUILD_SHARED_LIBRARY تُستخدم لإنشاء مكتبة ثابتة. لا ينسخ نظام الإنشاء المكتبات الثابتة إلى مشروعك/حِزمك، ولكن يمكنه استخدامها لإنشاء مكتبات مشترَكة (راجِع LOCAL_STATIC_LIBRARIES و LOCAL_WHOLE_STATIC_LIBRARIES أدناه). بناء الجملة لاستخدام هذا المتغير هو:

include $(BUILD_STATIC_LIBRARY)

يتسبب متغير المكتبة الثابتة في إنشاء نظام التصميم لمكتبة باستخدام الإضافة ".a".

PREBUILT_SHARED_LIBRARY

يشير إلى نص برمجي للإنشاء يُستخدَم لتحديد مكتبة مشتركة مُجمَّعة مسبقًا. إلغاء الإعجاب في حالة BUILD_SHARED_LIBRARY وBUILD_STATIC_LIBRARY، تكون هنا قيمة لا يمكن أن يكون LOCAL_SRC_FILES ملف مصدر. بدلاً من ذلك، يجب أن يكون مسارًا واحدًا مكتبة مشتركة تم إنشاؤها مسبقًا، مثل foo/libfoo.so. بناء جملة استخدام هذا المتغيّر هو:

include $(PREBUILT_SHARED_LIBRARY)

يمكنك أيضًا الرجوع إلى مكتبة تم إنشاؤها مسبقًا في وحدة أخرى باستخدام متغيّر "LOCAL_PREBUILTS" لمزيد من المعلومات عن استخدام الوحدات المُسبقة الإنشاء، راجِع مقالة استخدام المكتبات المُسبقة الإنشاء.

PREBUILT_STATIC_LIBRARY

يُرجى الاطّلاع على PREBUILT_SHARED_LIBRARY، ولكن بالنسبة إلى مكتبة ثابتة مُسبقة الإنشاء. لمزيد من المعلومات عن استخدام الوحدات المُسبقة الإنشاء، يُرجى الاطّلاع على استخدام المكتبات المُسبقة الإنشاء.

متغيّرات المعلومات المستهدفة

يحلّل نظام الإنشاء Android.mk مرة واحدة لكل ABI محدّد من خلال المتغيّر APP_ABI ، والذي يتم تحديده عادةً في ملف Application.mk. إذا APP_ABI تساوي all، ثم يحلّل نظام التصميم Android.mk مرة واحدة لكل ABI وNDK. والدعم. يصف هذا القسم المتغيرات التي يحددها نظام الإصدار في كل مرة وتحلّل Android.mk.

TARGET_ARCH

مجموعة وحدة المعالجة المركزية التي يستهدفها نظام التصميم أثناء تحليله لجهاز Android.mk هذا الملف. سيكون هذا المتغيّر أحد القيم التالية: arm أو arm64 أو x86 أو x86_64.

المنصة المستهدفة

رقم مستوى واجهة برمجة تطبيقات Android الذي يستهدفه نظام التصميم أثناء تحليل ملف Android.mk هذا. على سبيل المثال، تتوافق صور نظام Android 5.1 مع مستوى واجهة برمجة التطبيقات 22 لنظام Android: android-22. للحصول على قائمة كاملة بأسماء المنصات صور نظام Android المقابلة، يمكنك الاطّلاع على واجهات برمجة التطبيقات الأصلية. يوضِّح المثال التالي بنية استخدام هذا المتغيّر:

ifeq ($(TARGET_PLATFORM),android-22)
    # ... do something ...
endif

TARGET_ARCH_ABI

واجهة برمجة التطبيقات التي يستهدفها نظام التصميم أثناء تحليل ملف Android.mk هذا. يعرض الجدول 1 إعدادات ABI المُستخدَمة لكل وحدة معالجة مركزية (CPU) وبنية متوافقة.

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

وحدة المعالجة المركزية (CPU) والبنية الأساسية الإعدادات
معالج ARMv7 armeabi-v7a
ARMv8 AArch64 arm64-v8a
i686 x86
X86- 64 x86_64

يوضّح المثال التالي كيفية التحقّق من ARMv8 AArch64 كمجموعة ملف تعريف ABI ووحدة المعالجة المركزية المستهدفة:

ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
  # ... do something ...
endif

لمزيد من التفاصيل حول واجهات ABI للبنية ومشاكل التوافق المرتبطة بها، يُرجى الاطّلاع على واجهات ABI لنظام Android.

ستتضمّن ABIs المستهدَفة الجديدة في المستقبل قيمًا مختلفة.

TARGET_ABI

تسلسل لمستوى واجهة برمجة التطبيقات المستهدَف لنظام التشغيل Android وواجهة ABI إنها مفيدة بشكل خاص عندما تريد الاختبار على صورة نظام مستهدفة محددة لجهاز حقيقي. على سبيل المثال، للتحقّق من توفّر جهاز ARM بسعة 64 بت يعمل بالمستوى 22 من واجهة برمجة تطبيقات Android:

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
  # ... do something ...
endif

متغيّرات وصف الوحدة

تصف المتغيرات الواردة في هذا القسم الوحدة الخاصة بك بنظام الإصدار. يجب أن يتّبع كل وصف للوحدة الخطوات الأساسية التالية:

  1. قم بتهيئة أو إلغاء تحديد المتغيرات المرتبطة بالوحدة، باستخدام متغيّر "CLEAR_VARS"
  2. حدِّد قيمًا للمتغيّرات المستخدَمة لوصف الوحدة.
  3. اضبط نظام إنشاء NDK لاستخدام نصّ البرمجة المناسب لإنشاء الوحدة، باستخدام المتغيّر BUILD_XXX.

المسار المحلي

يُستخدَم هذا المتغيّر لتحديد مسار الملف الحالي. يجب تحديده في بداية ملف Android.mk. يوضح المثال التالي كيفية القيام لذلك:

LOCAL_PATH := $(call my-dir)

لا يؤدي النص البرمجي الذي يشير إليه CLEAR_VARS إلى محو هذا المتغيّر. ولذلك، ما عليك سوى تحديده مرة واحدة، حتى إذا كان ملفك Android.mk يصف وحدات متعددة.

الوحدة المحلية

يُخزِّن هذا المتغيّر اسم وحدتك. يجب أن يكون فريدًا بين جميع الوحدات أسماء، ويجب ألا يحتوي على أي مسافات. يجب تحديدها قبل تضمين أي نصوص برمجية (باستثناء النص البرمجي المخصّص لـ CLEAR_VARS). لست بحاجة إلى إضافة البادئة lib أو إضافة امتداد الملف .so أو .a، لأنّ نظام الإنشاء يُجري هذه التعديلات تلقائيًا. في ملفّي Android.mk وApplication.mk ، يمكنك الإشارة إلى وحدتك باسمها غير المعدَّل. على سبيل المثال، يؤدي السطر التالي إلى إنشاء وحدة مكتبة مشتركة باسم libfoo.so:

LOCAL_MODULE := "foo"

إذا أردت أن يكون للوحدة التي تم إنشاؤها اسم غير lib + قيمة LOCAL_MODULE، يمكنك استخدام المتغير LOCAL_MODULE_FILENAME لتحديد التي تم إنشاؤها كاسم من اختيارك، بدلاً من ذلك.

LOCAL_MODULE_FILENAME

يتيح لك هذا المتغيّر الاختياري إلغاء الأسماء التي يستخدمها نظام الإنشاء تلقائيًا للملفات التي ينشئها. على سبيل المثال، إذا كان اسم LOCAL_MODULE هو foo، يمكنك إجبار النظام على استدعاء الملف الذي ينشئه libnewfoo. يوضّح المثال التالي كيفية تحقيق ذلك:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

بالنسبة إلى وحدة مكتبة مشتركة، سينشئ هذا المثال ملفًا يسمى libnewfoo.so

LOCAL_SRC_FILES

يحتوي هذا المتغير على قائمة بملفات المصدر التي يستخدمها نظام الإصدار لإنشاء الوحدة. لا تُدرِج سوى الملفات التي ينقلها نظام الإنشاء فعليًا إلى المُجمِّع، لأنّ نظام الإنشاء يحسب تلقائيًا أي تبعيات مرتبطة . يُرجى العلم أنّه يمكنك استخدام كلّ من المسارات النسبية (بالنسبة إلى LOCAL_PATH) ومسارات الملفات المطلقة.

نوصي بتجنب مسارات الملفات المطلقة؛ تؤدي المسارات النسبية إلى جعل Android.mk بشكل أكثر سهولة.

LOCAL_CPP_امتداد

يمكنك استخدام هذا المتغير الاختياري للإشارة إلى امتداد ملف بخلاف .cpp لملفات مصدر C++. على سبيل المثال، يغيِّر السطر التالي دالة الرسم الإضافة إلى .cxx. (يجب أن يتضمّن الإعداد النقطة).

LOCAL_CPP_EXTENSION := .cxx

يمكنك استخدام هذا المتغيّر لتحديد عدة إضافات. على سبيل المثال:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

يمكنك استخدام هذا المتغير الاختياري للإشارة إلى أن التعليمات البرمجية تعتمد على بيانات محددة ميزات C++. ويعمل على تفعيل علامات المُجمِّع والرابط الصحيحة أثناء عملية الإنشاء. بالنسبة إلى الملفات الثنائية التي تم إنشاؤها مسبقًا، يعلن هذا المتغير أيضًا عن الميزات البرنامج الثنائي على هذا الأساس، مما يساعد على ضمان عمل الربط النهائي بشكل صحيح. أر ننصحك باستخدام هذا المتغيّر بدلاً من تفعيل السمة -frtti -fexceptions في تعريف LOCAL_CPPFLAGS مباشرةً.

يتيح استخدام هذا المتغير لنظام الإصدار استخدام العلامات المناسبة لكل وحدة. استخدام LOCAL_CPPFLAGS يجعل المحول البرمجي يستخدم كل ما هو محدد لجميع الوحدات، بصرف النظر عن الحاجة الفعلية.

على سبيل المثال، للإشارة إلى استخدام الرمز البرمجي "RTTI" (معلومات نوع وقت التشغيل)، كتابة: 

LOCAL_CPP_FEATURES := rtti

للإشارة إلى أن التعليمات البرمجية تستخدم استثناءات C++، اكتب:

LOCAL_CPP_FEATURES := exceptions

يمكنك أيضًا تحديد قيم متعددة لهذا المتغيّر. مثلاً:

LOCAL_CPP_FEATURES := rtti features

ولا يهمّ الترتيب الذي تصف به القيم.

LOCAL_C_INCLUDES

يمكنك استخدام هذا المتغيّر الاختياري لتحديد قائمة بالمسارات، بالنسبة إلى ملف root في NDK، لإضافتها إلى مسار البحث عن الضمائم عند تجميع كل المصادر (C وC++ وAssembly). مثلاً: 

LOCAL_C_INCLUDES := sources/foo

أو حتى: 

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo

حدِّد هذا المتغيّر قبل ضبط أيّ علامات تضمين مقابلة من خلال LOCAL_CFLAGS أو LOCAL_CPPFLAGS.

يستخدم نظام التصميم أيضًا مسارات LOCAL_C_INCLUDES تلقائيًا عند إطلاقه. تصحيح الأخطاء الأصلي باستخدام ndk-gdb.

LOCAL_ASFLAGS

علامات سيتم تمريرها إلى Clang عند إنشاء ملفات .s أو .S.

LOCAL_ASMFLAGS

علامات سيتم تمريرها إلى yasm عند إنشاء ملفات .asm.

المحلية

العلامات التي سيتم تمريرها إلى Clang عند إنشاء المباني C وC++ وبعض المباني (.s و.S، ولكن ليس .asm). يمكن أن تساعدك القدرة على القيام بذلك أن تكون مفيدة في تحديد تعريفات ماكرو إضافية أو خيارات تجميع إضافية. استخدام LOCAL_CPPFLAGS لتحديد علامات لـ C++ فقط. استخدام LOCAL_CONLYFLAGS من أجل لتحديد علامات C فقط.

جرِّب عدم تغيير مستوى التحسين/تصحيح الأخطاء في ملف Android.mk. يمكن لنظام التصميم معالجة هذا الإعداد تلقائيًا نيابةً عنك، وذلك باستخدام ذات صلة في ملف Application.mk. القيام بذلك بهذه الطريقة يسمح لإنشاء ملفات بيانات مفيدة يتم استخدامها أثناء تصحيح الأخطاء.

يمكن تحديد مسارات تضمين إضافية بكتابة:

LOCAL_CFLAGS += -I<path>,

ومع ذلك، من الأفضل استخدام LOCAL_C_INCLUDES لهذا الغرض، لأنّه يمكن من خلال ذلك أيضًا استخدام المسارات المتاحة لتصحيح الأخطاء الأصلي باستخدام ndk-gdb.

LOCAL_CONLYFLAGS

علامات سيتم تمريرها إلى Clang عند تجميع مصادر C. إلغاء الإعجاب لن يتم تمرير LOCAL_CFLAGS، LOCAL_CONLYFLAGS إلى Clang عند التجميع. C++ أو مصادر التجميع.

LOCAL_CPPFLAGS

مجموعة اختيارية من علامات المحول البرمجي التي سيتم تمريرها عند إنشاء مصدر C++ الملفات فقط. ستظهر بعد LOCAL_CFLAGS في سطر تعليمات المُجمِّع. استخدِم LOCAL_CFLAGS لتحديد علامات لكل من C وC++.

LOCAL_STATIC_LIBRARIES

يُخزن هذا المتغير قائمة وحدات المكتبات الثابتة التي الوحدة النمطية.

إذا كانت الوحدة الحالية مكتبة مشتركة أو ملف قابل للتنفيذ، سيؤدي هذا المتغيّر إلى فرض ربط هذه المكتبات بالملف الثنائي الناتج.

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

LOCAL_SHARED_LIBRARIES

يمثّل هذا المتغيّر قائمة وحدات المكتبات المشتركة التي تظهر فيها هذه الوحدة. حسب وقت التشغيل تكون هذه المعلومات ضرورية في وقت الربط، ولتضمين المعلومات المقابلة في الملف الذي تم إنشاؤه.

LOCAL_WHOLE_STATIC_LIBRARIES

هذا المتغيّر هو أحد متغيرات LOCAL_STATIC_LIBRARIES، ويوضّح أن أن يتعامل برنامج الربط مع وحدات المكتبة المرتبطة بها على أنّها أرشيفات كاملة. للحصول على مزيد من المعلومات عن الأرشيفات الكاملة، يُرجى الاطّلاع على مستندات GNU ld للتعرّف على العلامة --whole-archive.

يكون هذا المتغيّر مفيدًا عند توفّر تبعيات دائرية بين عدة مكتبات static. وعند استخدام هذا المتغير لإنشاء مكتبة مشتركة، إجبار نظام الإصدار على إضافة جميع ملفات الكائنات من مكتباتك الثابتة إلى ملف الثنائي النهائي. لا ينطبق ذلك، مع ذلك، عند إنشاء ملفات تنفيذية.

LOCAL_LDLIBS

يحتوي هذا المتغيّر على قائمة بعلامات الربط الإضافية لاستخدامها في إنشاء مكتبتك المشترَكة أو الملف القابل للتنفيذ. ويتيح لك استخدام البادئة -l لتمرير اسم مكتبات نظام معيّنة. على سبيل المثال، يخبر المثال التالي أداة الربط لإنشاء وحدة ترتبط بـ /system/lib/libz.so عند التحميل الوقت: 

LOCAL_LDLIBS := -lz

للاطّلاع على قائمة مكتبات النظام المعروضة التي يمكنك الربط بها في إصدار NDK هذا، يُرجى الاطّلاع على واجهات برمجة التطبيقات الأصلية.

LOCAL_LDFLAGS

قائمة علامات الربط الأخرى التي يستخدمها نظام الإنشاء عند إنشاء المكتبة المشتركة أو الملف القابل للتنفيذ على سبيل المثال، لاستخدام أداة الربط ld.bfd على ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

بشكلٍ تلقائي، عندما يواجه نظام الإنشاء مرجعًا غير محدّد أثناء محاولة إنشاء ملف مشترَك، سيُرسِل خطأ رمز غير محدّد. يمكن أن يساعدك هذا الخطأ في رصد الأخطاء في رمز المصدر.

لإيقاف عملية التحقّق هذه، عليك ضبط هذا المتغيّر على "true". لاحظ أن هذا الإعداد قد إلى تحميل المكتبة المشتركة في وقت التشغيل.

LOCAL_ARM_MODE

ينشئ نظام التصميم تلقائيًا برامج ثنائية مستهدفة من ARM في وضع الدمج. حيث يكون عرض كل تعليمات 16 بت وترتبط بمكتبات STL دليل thumb/. يؤدي تحديد هذا المتغيّر على أنّه arm إلى إجبار نظام الإنشاء على إنشاء ملفات الوحدات في وضع arm بسعة 32 بت. يوضّح المثال التالي كيفية إجراء ذلك:

LOCAL_ARM_MODE := arm

يمكنك أيضًا توجيه نظام التصميم لإنشاء مصادر محدّدة فقط في arm. من خلال إلحاق اللاحقة .arm بأسماء الملفات المصدر. على سبيل المثال، في المثال التالي، يطلب نظام التصميم تجميع bar.c دائمًا في وضع ARM، ولكن لإنشاء foo.c وفقًا لقيمة LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON

لا يهمّ هذا المتغيّر إلا عند استهداف ABI ‏armeabi-v7a. أُنشأها جون هنتر، الذي كان متخصصًا يسمح باستخدام جوهرات التجميع الأساسي لـ ARM Advanced SIMD (NEON) في C وC++ بالإضافة إلى تعليمات NEON في ملفات التجميع.

تجدر الإشارة إلى أنّ بعض وحدات المعالجة المركزية (CPU) المستندة إلى ARMv7 لا تتوافق مع إضافات مجموعة تعليمات NEON. ولهذا السبب، يجب رصد بيئة التشغيل لتتمكّن من استخدام التطبيق بأمان. هذا الرمز في وقت التشغيل. لمزيد من المعلومات، يُرجى الاطّلاع على مقالة التوافق مع Neon وميزات وحدة المعالجة المركزية.

بدلاً من ذلك، يمكنك استخدام اللاحقة .neon لتحديد أنّ نظام الإنشاء لا يُجمِّع سوى ملفات مصدر معيّنة تتيح استخدام NEON. في المثال التالي، يُنشئ نظام الإنشاء foo.c مع دعم thumb وNEON، وbar.c مع دعم thumb، وzoo.c مع دعم ARM وNEON:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

في حال استخدام كلتا اللاحقتَين، يجب أن يسبق .arm .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

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

LOCAL_EXPORT_CFLAGS

يسجِّل هذا المتغيّر مجموعة من علامات مُجمِّع C/C++ لإضافتها إلى LOCAL_CFLAGS تعريف أي وحدة أخرى تستخدِم هذه الوحدة من خلال المتغيّرات LOCAL_STATIC_LIBRARIES أو LOCAL_SHARED_LIBRARIES.

على سبيل المثال، لنأخذ المكوّنَين التاليَين: foo وbar، اللذان يعتمدان على foo:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_CFLAGS := -DFOO=1
include $(BUILD_STATIC_LIBRARY)


include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_CFLAGS := -DBAR=2
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

هنا، يمرر نظام التصميم العلامتين -DFOO=1 و-DBAR=2 إلى برنامج التجميع عند إنشاء bar.c. وتُضيف أيضًا علامات التصدير إلى LOCAL_CFLAGS في وحدتك حتى تتمكّن من إلغاء مفعولها بسهولة.

بالإضافة إلى ذلك، تكون العلاقة بين الوحدات تبادلية: إذا كانت zoo تعتمد على bar، والتي تعتمد بدورها على foo، سترث zoo أيضًا جميع العلامات المصدَّرة من foo.

أخيرًا، لا يستخدم نظام الإنشاء العلامات التي تم تصديرها عند الإنشاء على الجهاز فقط (أي إنشاء الوحدة التي يتم تصدير علاماتها). وبالتالي، في المثال أعلاه، لا يتم تمرير -DFOO=1 إلى المُجمِّع عند إنشاء foo/foo.c. إلى تُنشِئ على الجهاز، استخدِم LOCAL_CFLAGS بدلاً منها.

LOCAL_EXPORT_CPPFLAGS

هذا المتغيّر مماثل لـ LOCAL_EXPORT_CFLAGS، ولكن لعلامات C++ فقط.

LOCAL_EXPORT_C_INCLUDES

هذا المتغيّر هو نفسه LOCAL_EXPORT_CFLAGS، ولكن مع تضمين المسارات في C. وهو مفيد في الحالات التي تحتاج فيها وحدة bar.c مثلاً إلى تضمين رؤوس من الوحدة foo.

LOCAL_EXPORT_LDFLAGS

هذا المتغيّر مماثل لـ LOCAL_EXPORT_CFLAGS، ولكن بالنسبة لعلامات الربط.

LOCAL_EXPORT_LDLIBS

هذا المتغيّر هو نفسه LOCAL_EXPORT_CFLAGS، ويطلب من نظام الإنشاء تمرير أسماء مكتبات نظام معيّنة إلى المُجمِّع. إضافة البادئة -l إلى لكل مكتبة تحددها.

يُرجى العلم أنّ نظام الإنشاء يُلحق علامات الربط المستورَدة بقيمة المتغيّر LOCAL_LDLIBS في الوحدة. ويحدث ذلك بسبب طريقة عمل روابط Unix.

وعادةً ما يكون هذا المتغير مفيدًا عندما تكون الوحدة foo مكتبة ثابتة وتحتوي على الذي يعتمد على مكتبة النظام. يمكنك بعد ذلك استخدام LOCAL_EXPORT_LDLIBS من أجل لتصدير التبعية. مثلاً: 

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_LDLIBS := -llog
include $(BUILD_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

في هذا المثال، يضع نظام التصميم -llog في نهاية أمر الربط. عند إنشاء libbar.so. ويُعلم ذلك الرابط بأنّه بما أنّ libbar.so يعتمد على foo، فهو يعتمد أيضًا على مكتبة تسجيل النظام.

الأوامر_المحلية

عليك ضبط هذا المتغيّر على true عندما تحتوي الوحدة على عدد كبير جدًا من المصادر. و/أو المكتبات الثابتة أو المشتركة التابعة. يؤدي القيام بذلك إلى إجبار نظام التصميم على استخدام بنية @ للأرشيفات التي تحتوي على ملفات كائنات وسيطة أو روابط المكتبات.

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

يُرجى العِلم أنّ أي قيمة غير true ستؤدي إلى إعادة السلوك التلقائي. يمكنك أيضًا تحديد APP_SHORT_COMMANDS في ملف Application.mk لفرض هذا السلوك على جميع الوحدات في مشروعك.

لا ننصح بتفعيل هذه الميزة تلقائيًا، لأنّها تجعل الإصدار أبطأ.

LOCAL_THIN_ARCHIVE

اضبط هذا المتغيّر على true عند إنشاء مكتبات ثابتة. سيؤدي القيام بذلك إلى إنشاء أرشيف رفيع أو ملف مكتبة لا يحتوي على ملفات الكائنات، ولكن بدلاً من ذلك، قم فقط بتقديم المسارات إلى الكائنات الفعلية التي عادةً ما تحتوي عليه.

يكون ذلك مفيدًا لتقليل حجم الناتج من عملية الإنشاء. العيب هو أن لا يمكن نقل هذه المكتبات إلى مكان مختلف (جميع المسارات داخلها نسبية).

القيم الصالحة هي true أو false أو فارغة. يمكن ضبط قيمة تلقائية في Application.mk من خلال المتغيّر APP_THIN_ARCHIVE.

LOCAL_FILTER_ASM

حدِّد هذا المتغيّر كأمر Shell الذي سيستخدمه نظام الإصدار لفلترة البيانات. ملفات التجميع المستخرجة أو التي تم إنشاؤها من الملفات التي حددتها LOCAL_SRC_FILES يؤدي تعريف هذا المتغير إلى حدوث الأشياء التالية:

  1. يُنشئ نظام التصميم ملف تجميع مؤقت من أي مصدر C أو C++. بدلاً من تجميعها في ملف كائن.
  2. ينفِّذ نظام الإصدار أمر Shell في LOCAL_FILTER_ASM على أي ملف تجميع مؤقت وعلى أي ملف تجميع مدرج في LOCAL_SRC_FILES، وبالتالي إنشاء ملف تجميع مؤقت آخر.
  3. ويجمع نظام التصميم ملفات التجميع هذه التي تمت تصفيتها في ملف كائن.

مثلاً:

LOCAL_SRC_FILES  := foo.c bar.S
LOCAL_FILTER_ASM :=

foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o

يشير الرقم "1" إلى المُجمِّع، ويشير الرقم "2" إلى الفلتر، ويشير الرقم "3" إلى المُجمِّع. يجب أن يكون الفلتر أمرًا مستقلاً لنظام التشغيل يأخذ اسم ملف الإدخال كوسيطة أولى، واسم ملف الإخراج كوسيطة ثانية. مثلاً:

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S

وحدات ماكرو الدوال التي يوفّرها NDK

يشرح هذا القسم وحدات دالة GNU Make التي يوفّرها NDK. استخدام $(call <function>) لتقييمها. فإنها تعرض معلومات نصية.

أمري

تعرض هذه الماكرو مسار آخر ملف makefile تم تضمينه، والذي عادةً ما يكون دليل Android.mk الحالي. تُعد my-dir مفيدة لتحديد LOCAL_PATH في بداية ملف Android.mk. مثلاً:

LOCAL_PATH := $(call my-dir)

بسبب الطريقة التي تعمل بها GNU Make، فإن ما تعرضه هذه الماكرو حقًا هو مسار الملف الأخير الذي أدرجه نظام الإصدار عند تحليل النصوص البرمجية للإصدار. بالنسبة لهذا السبب، يجب عدم استدعاء my-dir بعد تضمين ملف آخر.

على سبيل المثال، إليك المثال التالي: 

LOCAL_PATH := $(call my-dir)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(call my-dir)

# ... declare another module

تكمن المشكلة هنا في أنّ الطلب الثاني إلى my-dir يحدّد LOCAL_PATH على أنّه $PATH/foo بدلاً من $PATH، لأنّه كان هذا هو المكان الذي أشار إليه أحدث ملف تضمين .

يمكنك تجنُّب هذه المشكلة عن طريق وضع عمليات تضمين إضافية بعد كل العناصر الأخرى في ملف Android.mk. مثلاً:

LOCAL_PATH := $(call my-dir)

# ... declare one module

LOCAL_PATH := $(call my-dir)

# ... declare another module

# extra includes at the end of the Android.mk file
include $(LOCAL_PATH)/foo/Android.mk

وإذا لم يكن من الممكن هيكلة الملف بهذه الطريقة، احفظ قيمة استدعاء my-dir الأول إلى متغير آخر. مثلاً: 

MY_LOCAL_PATH := $(call my-dir)

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare another module

all-subdir-makefiles

عرض قائمة ملفات Android.mk المتوفّرة في جميع الأدلة الفرعية لمسارmy-dir الحالي

يمكنك استخدام هذه الدالة لتقديم تسلسلات هرمية لدليل مصدر أكثر تعمقًا من أجل نظام التصميم. يبحث NDK تلقائيًا عن الملفات في الدليل الذي يحتوي على ملف Android.mk فقط.

ملف التصميم هذا

لعرض مسار ملف makefile الحالي (الذي استدعى نظام الإنشاء دالّة ).

ملف_إنشاء_عنصر رئيسي

عرض مسار ملف الإنشاء الرئيسي في شجرة التضمين (مسار ملف الإنشاء الذي يتضمّن الملف الحالي)

grand-parent-makefile

لعرض مسار ملف makefile الخاص بالجد في شجرة التضمين (مسار ملف makefile الذي يتضمن الملف الحالي).

import-module

دالة تتيح لك العثور على ملف Android.mk الخاص بالوحدة وتضمينه من خلال اسم الوحدة. في ما يلي مثال شائع: 

$(call import-module,<name>)

في هذا المثال، يبحث نظام الإنشاء عن الوحدة التي تم وضع علامة <name> عليها في قائمة الدلائل التي يشير إليها متغيّر NDK_MODULE_PATH في البيئة، ويضمّن ملف Android.mk تلقائيًا نيابةً عنك.