Android.mk

Halaman ini menjelaskan sintaks file build Android.mk yang digunakan oleh ndk-build.

Ringkasan

File Android.mk berada di sebuah subdirektori pada direktori jni/ project Anda, dan mendeskripsikan file sumber dan library bersama Anda ke sistem build. File ini merupakan fragmen GNU Makefile yang sangat kecil, yang diurai satu atau beberapa kali oleh sistem build. File Android.mk berguna untuk menentukan setelan lingkup project yang belum ditentukan oleh Application.mk, sistem build, dan variabel lingkungan Anda. File ini juga dapat menggantikan setelan lingkup project untuk modul tertentu.

Sintaks Android.mk memungkinkan Anda mengelompokkan sumber ke dalam modul. Sebuah modul dapat berupa library statis, library bersama, atau executable tersendiri. Anda dapat menentukan satu atau beberapa modul di setiap file Android.mk, dan dapat menggunakan file sumber yang sama di beberapa modul. Sistem build hanya menempatkan library bersama ke dalam paket aplikasi Anda. Selain itu, library statis dapat menghasilkan library bersama.

Selain mengemas library, sistem build menangani berbagai detail lainnya untuk Anda. Misalnya, Anda tidak perlu mencantumkan file header atau dependensi eksplisit antara file yang dihasilkan dalam file Android.mk Anda. Sistem build NDK menghitung hubungan ini secara otomatis untuk Anda. Hasilnya, Anda akan dapat memanfaatkan dukungan toolchain/platform baru pada rilis NDK mendatang tanpa perlu menangani file Android.mk.

Sintaks file ini sangat mirip dengan yang digunakan dalam file Android.mk, yang didistribusikan bersama Project Open Source Android lengkap. Sementara implementasi sistem build yang menggunakannya berbeda, kesamaannya adalah keputusan desain intensional yang dimaksudkan untuk memudahkan developer aplikasi dalam menggunakan kembali kode sumber untuk library eksternal.

Dasar-dasar

Sebelum mengeksplorasi sintaks ini secara mendetail, ada baiknya kita memulai dengan memahami dasar-dasar tentang isi file Android.mk. Bagian ini menggunakan file Android.mk dalam sampel Hello-JNI untuk keperluan tersebut, yang menjelaskan peran setiap baris dalam file.

File Android.mk harus dimulai dengan menentukan variabel LOCAL_PATH:

LOCAL_PATH := $(call my-dir)
    

Variabel ini menunjukkan lokasi file sumber pada hierarki pengembangan. Di sini, fungsi makro my-dir, yang disediakan oleh sistem build, menampilkan jalur direktori saat ini (direktori yang memuat file Android.mk itu sendiri).

Baris berikutnya mendeklarasikan variabel CLEAR_VARS, yang nilainya diberikan oleh sistem build.

include $(CLEAR_VARS)
    

Variabel CLEAR_VARS menunjuk ke GNU Makefile khusus yang menghapus banyak variabel LOCAL_XXX untuk Anda, seperti LOCAL_MODULE, LOCAL_SRC_FILES, dan LOCAL_STATIC_LIBRARIES. Perhatikan bahwa variabel LOCAL_PATH tidak dihapus. Variabel ini harus mempertahankan nilainya karena sistem akan mengurai semua file kontrol build dalam satu konteks eksekusi GNU Make di mana semua variabel bersifat global. Anda harus mendeklarasikan (kembali) variabel ini sebelum menjelaskan setiap modul.

Selanjutnya, variabel LOCAL_MODULE menyimpan nama modul yang ingin Anda buat. Gunakan variabel ini sekali per modul dalam aplikasi Anda.

LOCAL_MODULE := hello-jni
    

Setiap nama modul harus unik dan tidak berisi spasi. Saat menghasilkan file library bersama terakhir, sistem build akan otomatis menambahkan awalan dan akhiran yang tepat ke nama yang Anda tetapkan untuk LOCAL_MODULE. Misalnya, contoh di atas menghasilkan library dengan nama libhello-jni.so.

Baris berikutnya mengenumerasi file sumber, dengan spasi untuk memisah beberapa file:

LOCAL_SRC_FILES := hello-jni.c
    

Variabel LOCAL_SRC_FILES harus memuat daftar file sumber C dan/atau C++ untuk dibuat menjadi sebuah modul.

Baris terakhir membantu sistem menyatukan semuanya:

include $(BUILD_SHARED_LIBRARY)
    

Variabel BUILD_SHARED_LIBRARY menunjuk ke skrip GNU Makefile yang mengumpulkan semua informasi yang Anda tetapkan dalam variabel LOCAL_XXX sejak include terbaru. Skrip ini menentukan apa yang akan dibuat, dan cara membuatnya.

Ada contoh yang lebih kompleks dalam direktori sampel, dengan file Android.mk berisi komentar yang dapat Anda lihat. Selain itu, Sampel: native-activity memberikan penjelasan mendetail tentang file Android.mk dari sampel tersebut. Terakhir, Variabel dan Makro memberikan informasi lebih lanjut tentang variabel dari bagian berikut.

Variabel dan Makro

Sistem build menyediakan banyak kemungkinan variabel untuk digunakan dalam file Android.mk. Banyak dari variabel ini yang dilengkapi dengan nilai yang telah ditetapkan sebelumnya. Untuk variabel lainnya, Anda perlu menetapkan sendiri nilainya.

Selain variabel-variabel tersebut, Anda juga dapat menentukan variabel bebas. Jika itu yang Anda lakukan, perlu diingat bahwa sistem build NDK mencadangkan nama variabel berikut:

  • Nama yang diawali dengan LOCAL_, seperti LOCAL_MODULE.
  • Nama yang diawali dengan PRIVATE_, NDK_, atau APP. Sistem build menggunakannya secara internal.
  • Nama yang berhuruf kecil, seperti my-dir. Sistem build juga menggunakannya secara internal.

Jika Anda ingin menentukan variabel sendiri dalam file Android.mk, sebaiknya tambahkan MY_ ke awal nama file.

Variabel include yang ditentukan NDK

Bagian ini membahas variabel GNU Make yang ditentukan oleh sistem build sebelum mengurai file Android.mk. Dalam keadaan tertentu, NDK mungkin akan mengurai file Android.mk beberapa kali, menggunakan definisi yang berbeda untuk sebagian variabel tersebut setiap kali.

CLEAR_VARS

Variabel ini menunjuk ke skrip build yang tidak menentukan hampir semua variabel LOCAL_XXX yang tercantum di bagian "Variabel yang ditentukan developer" di bawah. Gunakan variabel tersebut untuk mencakup skrip ini sebelum mendeskripsikan modul baru. Sintaks untuk menggunakannya adalah:

include $(CLEAR_VARS)
    

BUILD_SHARED_LIBRARY

Variabel ini menunjuk ke skrip build yang mengumpulkan semua informasi tentang modul yang Anda berikan dalam variabel LOCAL_XXX, dan menentukan cara membuat library bersama target dari sumber yang Anda cantumkan. Perhatikan bahwa untuk menggunakan skrip ini, Anda harus sudah menetapkan nilai setidaknya ke variabel LOCAL_MODULE dan LOCAL_SRC_FILES (untuk informasi lebih lanjut tentang variabel-variabel ini, lihat Variabel Deskripsi Modul).

Sintaks untuk menggunakan variabel ini adalah:

include $(BUILD_SHARED_LIBRARY)
    

Variabel library bersama menyebabkan sistem build menghasilkan file library dengan ekstensi .so.

BUILD_STATIC_LIBRARY

Salah satu varian BUILD_SHARED_LIBRARY yang digunakan untuk membuat library statis. Sistem build tidak menyalin library statis ke project/paket Anda, tetapi dapat menggunakannya untuk membuat library bersama (lihat LOCAL_STATIC_LIBRARIES dan LOCAL_WHOLE_STATIC_LIBRARIES, di bawah). Sintaks untuk menggunakan variabel ini adalah:

include $(BUILD_STATIC_LIBRARY)
    

Variabel library statis menyebabkan sistem build menghasilkan file library dengan ekstensi .a.

PREBUILT_SHARED_LIBRARY

Menunjuk ke skrip build yang digunakan untuk menetapkan library bersama bawaan. Tidak seperti pada kasus BUILD_SHARED_LIBRARY dan BUILD_STATIC_LIBRARY, di sini nilai LOCAL_SRC_FILES tidak boleh berupa file sumber. Sebagai gantinya, nilai ini harus berupa jalur tunggal ke library bersama bawaan, seperti foo/libfoo.so. Sintaks untuk menggunakan variabel ini adalah:

include $(PREBUILT_SHARED_LIBRARY)
    

Anda juga bisa mereferensikan library bawaan di modul lain menggunakan variabel LOCAL_PREBUILTS. Untuk informasi lebih lanjut tentang menggunakan library bawaan, lihat Menggunakan Library Bawaan.

PREBUILT_STATIC_LIBRARY

Sama seperti PREBUILT_SHARED_LIBRARY, tetapi untuk library statis bawaan. Untuk informasi lebih lanjut tentang menggunakan library bawaan, lihat Menggunakan Library Bawaan.

Variabel informasi target

Sistem build mengurai Android.mk sekali per ABI yang ditentukan oleh variabel APP_ABI, yang biasanya ditentukan dalam file Application.mk Anda. Jika APP_ABI adalah all, maka sistem build akan mengurai Android.mk sekali per ABI yang didukung NDK. Bagian ini menjelaskan variabel-variabel yang ditentukan oleh sistem build setiap kali mengurai Android.mk.

TARGET_ARCH

Kelompok CPU yang ditargetkan sistem build ketika mengurai file Android.mk ini. Variabel ini adalah salah satu dari: arm, arm64, x86, atau x86_64.

TARGET_PLATFORM

Nomor level API Android yang ditargetkan sistem build ketika mengurai file Android.mk ini. Sebagai contoh, image sistem Android 5.1 berhubungan dengan Android API level 22: android-22. Untuk daftar lengkap nama platform dan image sistem Android yang sesuai, lihat API Native Android NDK. Contoh berikut menunjukkan sintaks untuk menggunakan variabel ini:

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

TARGET_ARCH_ABI

ABI yang ditargetkan sistem build saat mengurai file Android.mk ini. Tabel 1 menunjukkan setelan ABI yang digunakan untuk setiap CPU dan arsitektur yang didukung.

Tabel 1. Setelan ABI untuk berbagai CPU dan arsitektur.

CPU dan arsitektur Setelan
ARMv7 armeabi-v7a
AArch64 ARMv8 arm64-v8a
i686 x86
x86-64 x86_64

Contoh berikut menunjukkan cara memeriksa AArch64 ARMv8 sebagai kombinasi CPU-dan-ABI target:

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

Untuk penjelasan selengkapnya tentang ABI arsitektur dan masalah kompatibilitas yang terkait, lihat Pengelolaan ABI.

Di masa mendatang, ABI target baru akan memiliki nilai yang berbeda.

TARGET_ABI

Penyambungan level API Android dan ABI target. Sangat berguna saat Anda ingin menjalankan pengujian terhadap image sistem target tertentu untuk perangkat sebenarnya. Misalnya, untuk memeriksa perangkat ARM 64-bit yang dijalankan di Android API level 22:

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

Variabel Deskripsi Modul

Variabel-variabel di bagian ini mendeskripsikan modul Anda ke sistem build. Setiap deskripsi modul harus mengikuti alur dasar berikut:

  1. Menginisialisasi atau tidak menentukan variabel yang terkait dengan modul, menggunakan variabel CLEAR_VARS.
  2. Menetapkan nilai ke variabel yang digunakan untuk mendeskripsikan modul.
  3. Menetapkan sistem build NDK untuk menggunakan skrip build yang sesuai untuk modul, menggunakan variabel BUILD_XXX.

LOCAL_PATH

Variabel ini digunakan untuk memberikan jalur file saat ini. Anda harus menentukannya di awal file Android.mk Anda. Contoh berikut menunjukkan cara melakukannya:

LOCAL_PATH := $(call my-dir)
    

Skrip yang ditunjukkan CLEAR_VARS tidak mengosongkan variabel ini. Karena itu, Anda hanya perlu menentukannya sekali, sekalipun file Android.mk Anda mendeskripsikan beberapa modul.

LOCAL_MODULE

Variabel ini menyimpan nama modul. Nama ini harus unik di antara semua nama modul, dan tidak boleh berisi spasi. Anda harus menentukannya sebelum menyertakan skrip apa pun (selain skrip untuk CLEAR_VARS). Anda tidak perlu menambahkan awalan lib atau ekstensi file .so atau .a; sistem build akan melakukan modifikasi ini secara otomatis. Di seluruh file Android.mk dan Application.mk, rujuk modul Anda menurut nama yang tidak dimodifikasi. Misalnya, baris berikut menghasilkan modul library bersama dengan nama libfoo.so:

LOCAL_MODULE := "foo"
    

Jika ingin modul yang dihasilkan memiliki nama selain lib + nilai LOCAL_MODULE, Anda dapat menggunakan variabel LOCAL_MODULE_FILENAME untuk memberikan nama pilihan Anda sendiri.

LOCAL_MODULE_FILENAME

Variabel opsional ini memungkinkan Anda mengganti nama yang secara default digunakan sistem build untuk file yang dihasilkannya. Misalnya, jika nama LOCAL_MODULE Anda adalah foo, Anda dapat memaksa sistem untuk memanggil file libnewfoo yang dihasilkannya. Contoh berikut menunjukkan cara melakukannya:

LOCAL_MODULE := foo
    LOCAL_MODULE_FILENAME := libnewfoo
    

Untuk modul library bersama, contoh ini akan menghasilkan file dengan nama libnewfoo.so.

LOCAL_SRC_FILES

Variabel ini memuat daftar file sumber yang digunakan sistem build untuk menghasilkan modul. Cantumkan hanya file yang benar-benar diteruskan oleh sistem build ke compiler, karena sistem build akan otomatis menghitung setiap dependensi yang terkait. Perhatikan bahwa Anda dapat menggunakan jalur file relatif (untuk LOCAL_PATH) dan juga absolut.

Sebaiknya hindari menggunakan jalur file absolut; jalur relatif menjadikan file Android.mk Anda lebih portabel.

LOCAL_CPP_EXTENSION

Anda dapat menggunakan variabel opsional ini untuk menunjukkan ekstensi file selain .cpp untuk file sumber C++ Anda. Misalnya, baris berikut mengubah ekstensi ke .cxx. (Setelan ini harus menyertakan titik.)

LOCAL_CPP_EXTENSION := .cxx
    

Anda dapat menggunakan variabel ini untuk menentukan banyak ekstensi. Sebagai contoh:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc
    

LOCAL_CPP_FEATURES

Anda dapat menggunakan variabel opsional ini untuk menunjukkan bahwa kode Anda bergantung pada fitur C++ tertentu. Variabel ini akan mengaktifkan tanda compiler dan linker yang tepat selama proses build. Untuk biner bawaan, variabel ini juga mendeklarasikan pada fitur mana biner bergantung, sehingga membantu memastikan penautan akhir berfungsi dengan benar. Kami merekomendasikan penggunaan variabel ini, bukan mengaktifkan -frtti dan -fexceptions secara langsung dalam definisi LOCAL_CPPFLAGS Anda.

Penggunaan variabel ini memungkinkan sistem build menggunakan tanda yang sesuai untuk setiap modul. Penggunaan LOCAL_CPPFLAGS menyebabkan compiler menggunakan semua tanda yang ditentukan untuk semua modul, terlepas dari kebutuhan sebenarnya.

Misalnya, untuk menunjukkan bahwa kode Anda menggunakan RTTI (waktu proses Type Information), tulislah:

LOCAL_CPP_FEATURES := rtti
    

Untuk menunjukkan bahwa kode Anda menggunakan pengecualian C++, tulislah:

LOCAL_CPP_FEATURES := exceptions
    

Anda juga bisa menetapkan banyak nilai untuk variabel ini. Contoh:

LOCAL_CPP_FEATURES := rtti features
    

Urutan Anda mendeskripsikan nilai-nilai tersebut tidaklah penting.

LOCAL_C_INCLUDES

Anda dapat menggunakan variabel opsional ini untuk menentukan daftar jalur, yang terkait dengan direktori root NDK, yang akan ditambahkan ke jalur penelusuran include saat mengompilasi semua sumber (C, C++, dan Assembly). Contoh:

LOCAL_C_INCLUDES := sources/foo
    

Atau bahkan:

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

Tentukan variabel ini sebelum menetapkan tanda penyertaan yang terkait melalui LOCAL_CFLAGS atau LOCAL_CPPFLAGS.

Sistem build juga otomatis menggunakan jalur LOCAL_C_INCLUDES saat meluncurkan proses debug native dengan ndk-gdb.

LOCAL_CFLAGS

Variabel opsional ini menetapkan tanda compiler yang akan diteruskan oleh sistem build saat membuat file sumber C dan C++. Kemampuan ini dapat berguna untuk menentukan definisi makro atau opsi kompilasi tambahan. Gunakan LOCAL_CPPFLAGS untuk menentukan tanda untuk C++ saja.

Usahakan tidak mengubah level pengoptimalan/proses debug pada file Android.mk. Sistem build dapat menangani setelan ini secara otomatis, menggunakan informasi yang relevan pada file [pplication.mk]. Dengan cara ini, sistem build dapat menghasilkan file data berguna yang digunakan selama proses debug.

Jalur include tambahan dapat ditetapkan dengan menulis:

LOCAL_CFLAGS += -I<path>,
    

Namun, sebaiknya gunakan LOCAL_C_INCLUDES untuk keperluan ini, karena cara tersebut juga memungkinkan penggunaan jalur yang tersedia untuk proses debug native dengan ndk-gdb.

LOCAL_CPPFLAGS

Kumpulan tanda compiler opsional yang akan diteruskan saat membuat file sumber C++ saja. Tanda ini akan muncul setelah LOCAL_CFLAGS pada command line compiler. Gunakan LOCAL_CFLAGS untuk menetapkan tanda untuk C dan juga C++.

LOCAL_STATIC_LIBRARIES

Variabel ini menyimpan daftar modul library statis yang menjadi tempat bergantung modul saat ini.

Jika modul saat ini berupa library bersama atau file executable, variabel ini akan memaksa library tersebut untuk ditautkan ke biner yang dihasilkan.

Jika modul saat ini berupa library statis, variabel ini hanya menunjukkan bahwa modul lain yang bergantung pada library saat ini juga akan bergantung pada library yang dicantumkan.

LOCAL_SHARED_LIBRARIES

Variabel ini adalah daftar modul library bersama yang menjadi tempat bergantung modul ini selama waktu proses. Informasi ini diperlukan pada waktu penautan, dan untuk menyematkan informasi yang sesuai ke dalam file yang dihasilkan.

LOCAL_WHOLE_STATIC_LIBRARIES

Variabel ini merupakan varian dari LOCAL_STATIC_LIBRARIES, dan menyatakan bahwa linker harus memperlakukan modul library yang terkait sebagai arsip utuh. Untuk informasi lebih lanjut tentang arsip utuh, lihat dokumentasi GNU ld untuk tanda --whole-archive.

Variabel ini berguna saat ada dependensi sirkuler di antara beberapa library statis. Jika Anda menggunakan variabel ini untuk membuat library bersama, sistem build akan dipaksa untuk menambahkan semua file objek dari library statis Anda ke biner akhir. Akan tetapi, hal yang sama tidak berlaku saat menghasilkan file executable.

LOCAL_LDLIBS

Variabel ini memuat daftar tanda linker tambahan untuk digunakan dalam membuat library bersama atau executable. Ini memungkinkan Anda menggunakan awalan -l untuk meneruskan nama library sistem tertentu. Misalnya, contoh berikut memberi tahu linker untuk menghasilkan modul yang menaut ke /system/lib/libz.so pada waktu pemuatan:

LOCAL_LDLIBS := -lz
    

Untuk daftar library sistem terbuka yang dapat Anda tautkan dalam rilis NDK ini, lihat API Native Android NDK.

LOCAL_LDFLAGS

Daftar tanda linker lain yang akan digunakan sistem build saat membuat library bersama atau executable. Misalnya, untuk menggunakan linker ld.bfd pada ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd
    

LOCAL_ALLOW_UNDEFINED_SYMBOLS

Secara default, saat sistem build menemukan referensi yang tidak ditentukan sewaktu mencoba membuat library bersama, maka error simbol tidak ditentukan akan muncul. Error ini dapat membantu Anda menangkap bug dalam kode sumber.

Untuk menonaktifkan pemeriksaan ini, tetapkan variabel ini ke true. Perhatikan bahwa setelan ini dapat menyebabkan library bersama dimuat pada waktu proses.

LOCAL_ARM_MODE

Secara default, sistem build akan menghasilkan biner target ARM dalam mode thumb, di mana setiap petunjuk memiliki lebar 16 bit dan ditautkan dengan library STL di direktori thumb/. Jika variabel ini ditetapkan sebagai arm, sistem build akan dipaksa untuk menghasilkan file objek modul dalam mode arm 32-bit. Contoh berikut menunjukkan cara melakukannya:

LOCAL_ARM_MODE := arm
    

Anda juga dapat memerintahkan sistem build untuk hanya membuat file sumber spesifik dalam mode arm dengan menambahkan akhiran .arm ke nama file sumber. Misalnya, contoh berikut memberi tahu sistem build untuk selalu mengompilasi bar.c dalam mode ARM, tetapi membuat foo.c sesuai dengan nilai LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm
    

LOCAL_ARM_NEON

Variabel ini hanya penting jika Anda menargetkan ABI armeabi-v7a. Dengan variabel ini, Anda dapat menggunakan compiler ARM Advanced SIMD (NEON) yang melekat dalam sumber C dan C++, serta petunjuk NEON dalam file Assembly.

Perhatikan, tidak semua CPU berbasis ARMv7 mendukung ekstensi set petunjuk NEON. Karena alasan ini, Anda harus menjalankan deteksi waktu proses agar dapat menggunakan kode ini dengan aman pada waktu proses. Untuk informasi lebih lanjut, lihat Dukungan NEON dan Library cpufeatures.

Cara lainnya, Anda dapat menggunakan akhiran .neon untuk menentukan bahwa sistem build hanya mengompilasi file sumber tertentu dengan dukungan NEON. Dalam contoh berikut, sistem build mengompilasi foo.c dengan dukungan thumb dan neon, bar.c dengan dukungan thumb, dan zoo.c dengan dukungan untuk ARM dan NEON:

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

Jika Anda menggunakan kedua akhiran, .arm harus mendahului .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

Secara default, sistem build mengompilasi kode dengan perlindungan string format. Hal ini akan memaksa error compiler jika string format non-konstan digunakan dalam fungsi gaya printf. Perlindungan ini aktif secara default, tetapi Anda dapat menonaktifkannya dengan menetapkan nilai variabel ini menjadi true. Kami tidak merekomendasikan tindakan ini tanpa alasan yang memaksa.

LOCAL_EXPORT_CFLAGS

Variabel ini mencatat sekumpulan tanda compiler C/C++ untuk ditambahkan ke definisi LOCAL_CFLAGS modul lain yang menggunakannya melalui variabel LOCAL_STATIC_LIBRARIES atau LOCAL_SHARED_LIBRARIES.

Sebagai contoh, perhatikan pasangan modul berikut: foo dan bar, yang bergantung pada 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)
    

Di sini, sistem build akan meneruskan tanda -DFOO=1 dan -DBAR=2 ke compiler saat membuat bar.c Sistem build juga menambahkan tanda yang diekspor ke LOCAL_CFLAGS modul sehingga Anda dapat menggantinya dengan mudah.

Selain itu, hubungan antarmodul bersifat transitif: Jika zoo bergantung pada bar, yang pada akhirnya bergantung pada foo, maka zoo juga mewarisi semua tanda yang diekspor dari foo.

Terakhir, sistem build tidak menggunakan tanda yang telah diekspor saat membuat modul secara lokal (misalnya, membuat modul yang flagnya diekspornya). Jadi, dalam contoh di atas, sistem tidak meneruskan -DFOO=1 ke compiler saat membuat foo/foo.c Untuk membuat modul secara lokal, gunakan LOCAL_CFLAGS sebagai gantinya.

LOCAL_EXPORT_CPPFLAGS

Variabel ini sama dengan LOCAL_EXPORT_CFLAGS, tetapi hanya untuk tanda C++.

LOCAL_EXPORT_C_INCLUDES

Variabel ini sama dengan LOCAL_EXPORT_CFLAGS, tetapi untuk jalur include C. Ini berguna dalam kasus-kasus ketika, misalnya, bar.c perlu menyertakan header dari modul foo.

LOCAL_EXPORT_LDFLAGS

Variabel ini sama dengan LOCAL_EXPORT_CFLAGS, tetapi untuk tanda linker.

LOCAL_EXPORT_LDLIBS

Variabel ini sama dengan LOCAL_EXPORT_CFLAGS, yang memberi tahu sistem build untuk meneruskan nama library sistem tertentu ke compiler. Tambahkan -l ke awal nama setiap library yang Anda tentukan.

Perhatikan bahwa sistem build menambahkan tanda linker yang telah diimpor ke akhir nilai variabel LOCAL_LDLIBS modul. Hal ini dilakukan demikian karena cara kerja linker Unix.

Variabel ini biasanya berguna saat modul foo adalah library statis dan memiliki kode yang bergantung pada library sistem. Selanjutnya Anda dapat menggunakan LOCAL_EXPORT_LDLIBS untuk mengekspor dependensi tersebut. Contoh:

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)
    

Dalam contoh ini, sistem build menempatkan -llog di akhir perintah linker saat membuat libbar.so. Dengan begitu, linker akan tahu bahwa karena libbar.so bergantung pada foo , maka ia juga bergantung pada library logging sistem.

LOCAL_SHORT_COMMANDS

Tetapkan variabel ini ke true jika modul Anda memiliki file sumber dan/atau library statis atau library bersama yang sangat banyak. Dengan begitu, sistem build akan dipaksa menggunakan sintaks @ untuk arsip yang memuat file objek perantara atau yang menautkan library.

Fitur ini dapat berguna pada Windows, yang fitur command line-nya hanya menerima maksimal 8191 karakter. Batas ini mungkin terlalu kecil untuk project yang kompleks. Batasan ini juga memengaruhi kompilasi masing-masing file sumber, yang menempatkan hampir semua tanda compiler ke dalam file daftar.

Perhatikan bahwa nilai apa pun selain true akan mengembalikan perilaku default. Anda juga dapat menentukan APP_SHORT_COMMANDS dalam file Application.mk untuk memaksakan perilaku ini bagi semua modul dalam project Anda.

Kami tidak menyarankan pengaktifan fitur ini secara default, karena akan memperlambat build.

LOCAL_THIN_ARCHIVE

Tetapkan variabel ini ke true saat membuat library statis. Cara ini akan menghasilkan arsip tipis, yakni file library yang tidak memuat file objek, melainkan hanya jalur file ke objek aktual yang biasanya dimuatnya.

Hal ini berguna untuk mengurangi ukuran output build. Kelemahannya adalah library semacam ini tidak dapat dipindahkan ke lokasi lain (semua jalur di dalamnya bersifat relatif).

Nilai yang valid adalah true, false, atau kosong. Nilai default dapat ditetapkan dalam file Application.mk melalui variabel APP_THIN_ARCHIVE.

LOCAL_FILTER_ASM

Tentukan variabel ini sebagai perintah shell yang akan digunakan sistem build untuk memfilter file assembly yang diekstrak atau dihasilkan dari file yang Anda tetapkan untuk LOCAL_SRC_FILES. Menentukan variabel ini menyebabkan terjadinya hal-hal berikut:

  1. Sistem build akan menghasilkan file assembly sementara dari setiap file sumber C atau C++, bukan mengompilasinya ke dalam file objek.
  2. Sistem build akan menjalankan perintah shell di LOCAL_FILTER_ASM atas setiap file assembly sementara dan setiap file assembly yang tercantum di LOCAL_SRC_FILES, sehingga menghasilkan file assembly sementara lainnya.
  3. Sistem build akan mengompilasi file assembly yang telah difilter ini ke dalam file objek.

Contoh:

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" berkaitan dengan compiler, "2" dengan filter, dan "3" dengan assembler. Filter harus berupa perintah shell mandiri yang menggunakan nama file input sebagai argumen pertama, dan nama file output sebagai yang kedua. Contoh:

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

Makro fungsi yang disediakan NDK

Bagian ini menjelaskan makro fungsi GNU Make yang disediakan NDK. Gunakan $(call <function>) untuk mengevaluasinya, dan informasi tekstual akan ditampilkan.

my-dir

Makro ini menampilkan jalur makefile terakhir yang disertakan, yang biasanya adalah direktori Android.mk saat ini. my-dir berguna untuk menentukan LOCAL_PATH di awal file Android.mk Anda. Contoh:

LOCAL_PATH := $(call my-dir)
    

Karena cara kerja GNU Make, yang sebenarnya ditampilkan makro ini adalah jalur makefile terakhir yang disertakan oleh sistem build saat mengurai skrip build. Karena alasan ini, Anda tidak perlu memanggil my-dir setelah memasukkan file lain.

Misalnya, perhatikan contoh berikut:

LOCAL_PATH := $(call my-dir)

    # ... declare one module

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

    LOCAL_PATH := $(call my-dir)

    # ... declare another module
    

Masalahnya di sini adalah panggilan kedua ke my-dir menentukan LOCAL_PATH sebagai $PATH/foo, bukan $PATH, karena di situlah include terakhirnya ditunjukkan.

Anda dapat menghindari masalah ini dengan menempatkan include tambahan setelah semua yang lain dalam file Android.mk. Contoh:

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
    

Jika tidak memungkinkan untuk membuat struktur file dengan cara ini, simpan nilai panggilan my-dir pertama ke variabel lain. Contoh:

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

Menampilkan daftar file Android.mk yang terletak di semua subdirektori dari jalur my-dir saat ini.

Anda dapat menggunakan fungsi ini untuk menyediakan hierarki direktori sumber yang bersarang dalam kepada sistem build. Secara default, NDK hanya mencari file di direktori yang berisi file Android.mk.

this-makefile

Menampilkan jalur makefile saat ini (yang digunakan sistem build untuk memanggil fungsi).

parent-makefile

Menampilkan jalur makefile induk pada hierarki penyertaan (jalur makefile yang menyertakan makefile saat ini).

grand-parent-makefile

Menampilkan jalur makefile induk dari induk pada hierarki penyertaan (jalur makefile yang menyertakan makefile saat ini).

import-module

Fungsi yang memungkinkan Anda menemukan dan menyertakan file Android.mk modul menurut nama modul tersebut. Contoh umumnya adalah seperti berikut:

$(call import-module,<name>)
    

Dalam contoh ini, sistem build mencari modul yang bertanda <name> pada daftar direktori yang direferensikan oleh variabel lingkungan NDK_MODULE_PATH Anda, dan yang otomatis menyertakan file Android.mk untuk Anda.