Android.mk

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

Ringkasan

File Android.mk berada dalam subdirektori dari direktori jni/ proyek Anda, dan menjelaskan sumber serta pustaka bersama untuk sistem pembangunan. Ini sebenarnya fragmen GNU makefile kecil yang diurai oleh sistem pembangunan sekali atau beberapa kali. File Android.mk berguna untuk mendefinisikan setelan lingkup-proyek Application.mk, sistem pembangunan, dan variabel lingkungan sengaja tidak didefinisikan. Ini juga bisa menggantikan setelan lingkup-proyek untuk modul tertentu.

Sintaks Android.mk memungkinkan Anda mengelompokkan sumber-sumber ke dalam beberapa modul. Modul tersebut bisa berupa pustaka statis, pustaka bersama, atau file mandiri yang dapat dieksekusi. Anda bisa mendefinisikan satu atau beberapa modul dalam setiap file Android.mk, dan Anda bisa menggunakan file sumber yang sama dalam beberapa modul sekaligus. Sistem pembangunan hanya memasukkan pustaka bersama ke dalam paket aplikasi Anda. Sebagai tambahan, pustaka statis bisa menghasilkan pustaka bersama.

Selain pengemasan perpustakaan, sistem pembangunan menangani berbagai detail untuk Anda. Misalnya, Anda tidak perlu mencantumkan file header atau dependensi eksplisit antara file yang dihasilkan dalam Android.mk file Anda. Sistem pembangunan NDK mengkomputasi hubungan ini secara otomatis untuk Anda. Hasilnya, Anda akan dapat memanfaatkan toolchain/dukungan platform baru dalam rilis NDK mendatang tanpa harus menyentuh file Android.mk.

Sintaks file ini sangat mirip dengan yang digunakan dalam Android.mk file yang didistribusikan bersama Proyek Open Source Android. Sedangkan implementasi sistem pembangunan yang menggunakannya adalah berbeda, kemiripannya adalah keputusan desain disengaja yang bertujuan mempermudah developer aplikasi untuk menggunakan kembali kode sumber bagi pustaka eksternal.

Dasar-Dasar

Sebelum mendalami sintaks secara detail, ada baiknya dimulai dengan memahami dasar-dasar mengenai apa yang ada dalam file Android.mk. Bagian ini menggunakan file Android.mk dalam contoh Hello-JNI sampai akhir, yang menjelaskan peran yang dimainkan oleh setiap baris dalam file.

File Android.mk harus dimulai dengan mendefinisikan variabel LOCAL_PATH:

LOCAL_PATH := $(call my-dir)

Variabel ini menunjukkan lokasi file sumber di pohon pengembangan. Di sini, fungsi makro my-dir, yang disediakan oleh sistem pembangunan, mengembalikan jalur direktori saat ini (direktori yang berisi file Android.mk itu sendiri).

Baris berikutnya mendeklarasikan variabel CLEAR_VARS, yang nilainya disediakan oleh sistem pembangunan.

include $(CLEAR_VARS)

Variabel CLEAR_VARS menunjukkan GNU Makefile khusus yang mengosongkan banyak LOCAL_XXX variabel untuk Anda, seperti LOCAL_MODULE, LOCAL_SRC_FILES, dan LOCAL_STATIC_LIBRARIES. Perhatikan, ini tidak mengosongkan LOCAL_PATH. Variabel ini harus mempertahankan nilainya karena sistem akan menguraikan semua file kontrol pembangunan dalam konteks eksekusi GNU Make yang semua variabelnya global. Anda harus mendeklarasikan kembali variabel ini sebelum menjelaskan setiap modul.

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

LOCAL_MODULE := hello-jni

Setiap nama modul harus unik dan tidak berisi spasi. Sistem pembangunan, bila menghasilkan file pustaka bersama akhir, secara otomatis menambahkan awalan dan akhiran yang sesuai ke nama yang Anda berikan ke LOCAL_MODULE. Misalnya, contoh yang muncul di atas mengakibatkan pembuatan pustaka bernama libhello-jni.so.

Baris berikutnya menyebutkan file sumber, bersama spasi yang membatasi beberapa file:

LOCAL_SRC_FILES := hello-jni.c

Variabel LOCAL_SRC_FILES harus berisi daftar file sumber C dan/atau C++ yang akan dibangun menjadi modul.

Baris terakhir membantu sistem mengikat semuanya:

include $(BUILD_SHARED_LIBRARY)

Variabel BUILD_SHARED_LIBRARY menunjukkan skrip GNU Makefile yang mengumpulkan semua informasi yang Anda definisikan dalam variabel LOCAL_XXX sejak terbaru include. Skrip ini menentukan apa yang akan dibangun, dan bagaimana melakukannya.

Ada contoh lebih kompleks dalam direktori contoh, bersama file Android.mk berisi komentar yang bisa Anda lihat. Selain itu, Contoh: native-activity menyediakan penjelasan detail mengenai file Android.mk contoh. Terakhir, Variabel dan Makro menyediakan informasi lebih lanjut mengenai variabel dari bagian ini.

Variabel dan Makro

Sistem pembangunan menyediakan banyak kemungkinan variabel untuk digunakan dalam file Android.mk. Banyak variabel ini disertakan dengan nilai telah ditetapkan sebelumnya. Untuk variabel lain, Anda yang menetapkan.

Sebagai tambahan untuk variabel-variabel ini, Anda juga bisa mendefinisikan sendiri variabel bebas. Jika Anda melakukannya, ingatlah bahwa sistem pembangunan NDK mencadangkan nama-nama variabel berikut:

  • Nama-nama yang diawali dengan, LOCAL_, misalnya LOCAL_MODULE.
  • Nama-nama yang diawali dengan PRIVATE_, NDK_, atau APP. Sistem pembangunan menggunakan ini secara internal.
  • Nama-nama yang berhuruf kecil, misalnya my-dir. Sistem pembangunan menggunakannya secara internal pula.

Jika Anda perlu mendefinisikan sendiri variabel yang disukai dalam file Android.mk, sebaiknya tambahkan MY_ di depannya.

NDK yang didefinisikan meliputi variabel

Bagian ini membahas berbagai variabel GNU Make yang didefinisikan sistem pembangunan sebelum mengurai file Android.mk Anda. Pada keadaan tertentu, NDK mungkin akan menguraikan file Android.mk beberapa kali, menggunakan definisi berbeda untuk sebagian variabel ini setiap kalinya.

CLEAR_VARS

Variabel ini menunjukkan skrip pembangunan yang tidak-mendefinisikan hampir semua variabel LOCAL_XXX yang tercantum di bagian "Variabel yang didefinisikan developer" di bawah ini. Gunakan variabel ini untuk menyertakan skrip ini sebelum menjelaskan modul baru. Sintaks untuk menggunakannya adalah:

include $(CLEAR_VARS)

BUILD_SHARED_LIBRARY

Variabel ini menunjukkan skrip yang mengumpulkan semua informasi tentang modul yang disediakan dalam variabel LOCAL_XXX, dan menentukan cara membangun target pustaka bersama dari sumber yang Anda cantumkan. Perhatikan, penggunaan skrip ini mengharuskan Anda sudah memberikan nilai-nilai ke LOCAL_MODULE and LOCAL_SRC_FILES, secara minimum (untuk informasi selengkapnya tentang variabel-variabel ini, lihat Variabel Keterangan Modul).

Sintaks untuk menggunakan variabel ini adalah:

include $(BUILD_SHARED_LIBRARY)

Variabel pustaka bersama menyebabkan sistem pembangunan menghasilkan file pustaka dengan ekstensi .so.

BUILD_STATIC_LIBRARY

Varian BUILD_SHARED_LIBRARY yang digunakan untuk membangun pustaka statis. Sistem pembangunan tidak menyalin pustaka statis ke dalam proyek/paket Anda, melainkan menggunakannya untuk membangun pustaka bersama (lihat LOCAL_STATIC_LIBRARIES dan LOCAL_WHOLE_STATIC_LIBRARIES, di bawah ini). Sintaks untuk menggunakan variabel ini adalah:

include $(BUILD_STATIC_LIBRARY)

Variabel pustaka statis menyebabkan sistem pembangunan menghasilkan file pustaka dengan ekstensi .a.

PREBUILT_SHARED_LIBRARY

Menunjukkan skrip pembangunan yang digunakan untuk menetapkan pustaka bersama bawaan. Tidak seperti dalam kasus BUILD_SHARED_LIBRARY dan BUILD_STATIC_LIBRARY, di sini nilai LOCAL_SRC_FILES tidak bisa berupa file sumber. Melainkan, harus berupa jalur tunggal ke pustaka bersama bawaan, misalnya foo/libfoo.so. Sintaks untuk menggunakan variabel ini adalah:

include $(PREBUILT_SHARED_LIBRARY)

Anda juga bisa mereferensikan pustaka bawaan dalam modul lain dengan menggunakan variabel LOCAL_PREBUILTS. Untuk informasi lebih lanjut tentang cara menggunakan bawaan atau prebuilt, lihat [Menggunakan Pustaka Bawaan].

PREBUILT_STATIC_LIBRARY

Sama seperti PREBUILT_SHARED_LIBRARY, tetapi untuk pustaka statis bawaan. Untuk informasi lebih lanjut tentang cara menggunakan bawaan atau prebuilt, lihat [Menggunakan Pustaka Bawaan].

Variabel informasi target

Sistem pembangunan menguraikan Android.mk sekali per ABI yang ditentukan oleh variabel APP_ABI , yang biasanya didefinisikan dalam file Application.mk. Jika APP_ABI adalah all, sistem pembangunan menguraikan Android.mk sekali per ABI the yang didukung NDK. Bagian ini menjelaskan variabel yang didefinisikan sistem pembangunan setiap kali sistem ini menguraikan Android.mk.

TARGET_ARCH

Keluarga CPU yang menjadi target sistem pembangunan saat variabel ini menguraikan file Android.mk ini. Variabel ini akan menjadi salah satu: arm, arm64, x86, atau x86_64.

TARGET_PLATFORM

Nomor level Android API yang menjadi target sistem build saat sistem ini menguraikan file Android.mk ini. Misanya, gambar sistem Android 5.1 sesuai dengan Android API level 22: android-22. Untuk daftar lengkap nama platform dan citra sistem Android yang sesuai, lihat Android NDK Native API. Contoh berikut menampilkan sintaks untuk menggunakan variabel ini:

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

TARGET_ARCH_ABI

ABI yang menjadi target sistem pembangunan saat sistem ini menguraikan file Android.mk ini. Tabel 1 memperlihatkan setelan ABI yang digunakan untuk setiap CPU dan arsitektur yang didukung.

Tabel 1. Setelan ABI untuk beragam CPU dan arsitektur.

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

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

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

Untuk detail selengkapnya tentang ABI dan masalah kompatibilitas terkait, lihat Manajemen ABI.

ABI target yang baru di masa mendatang akan memiliki nilai-nilai yang berbeda.

TARGET_ABI

Penyambungan level Android API dan ABI target. Berguna khususnya bila Anda ingin menguji citra sistem target tertentu untuk perangkat sungguhan. 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 Keterangan Modul

Variabel-variabel di bagian ini menjelaskan modul Anda pada sistem pembangunan. Setiap keterangan modul harus mengikuti alur dasar ini:

  1. Lakukan inisialisasi atau batalkan definisi variabel-variabel yang berkaitan dengan modul, dengan variabel CLEAR_VARS.
  2. Berikan nilai ke variabel-variabel yang digunakan untuk menjelaskan modul.
  3. Setel sistem pembangunan NDK agar menggunakan skrip pembangunan untuk modul, menggunakan variabel BUILD_XXX.

LOCAL_PATH

Variabel ini digunakan untuk memberikan jalur file saat ini. Anda harus mendefinisikannya pada awal file Android.mk. Contoh berikut memperlihatkan cara melakukannya :

LOCAL_PATH := $(call my-dir)

Skrip yang ditunjukkan CLEAR_VARS tidak mengosongkan variabel. Oleh karena itu, Anda hanya perlu mendefinisikannya satu kali, sekalipun file Android.mk menjelaskan beberapa modul.

LOCAL_MODULE

Variabel ini menyimpan nama modul Anda. Namanya harus unik di antara semua nama modul, dan tidak boleh berisi spasi. Anda harus mendefinisikannya sebelum menyertakan skrip (selain yang untuk CLEAR_VARS). Anda tidak perlu menambahkan awalan lib atau .so atau .a ekstensi file; sistem pembangunan membuat modifikasi ini secara otomatis. Di seluruh file Android.mk dan Application.mk , rujuklah modul berdasarkan nama yang tidak dimodifikasi. Misalnya, baris berikut mengakibatkan pembuatan modul pustaka bersama bernama libfoo.so:

LOCAL_MODULE := "foo"

Jika Anda ingin modul yang dihasilkan memiliki nama selain lib + nilai LOCAL_MODULE, Anda bisa menggunakan variabel LOCAL_MODULE_FILENAME untuk menamai modul yang dihasilkan dengan nama pilihan Anda sendiri, sebagai gantinya.

LOCAL_MODULE_FILENAME

Variabel opsional ini memungkinkan Anda menggantikan nama-nama yang digunakan sistem pembangunan secara default untuk file yang dihasilkannya. Misalnya, jika nama LOCAL_MODULE adalah foo, Anda bisa memaksa sistem untuk memanggil file yang dihasilkannya libnewfoo. Contoh berikut menampilkan cara melakukannya:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

Untuk modul pustaka bersama, contoh ini akan menghasilkan file bernama libnewfoo.so.

LOCAL_SRC_FILES

Variabel ini berisi daftar file sumber yang digunakan sistem pembangunan untuk menghasilkan modul. Cantumkan hanya file yang sesungguhnya diteruskan sistem pembangunan ke pengompilasi, karena sistem pembangunan secara otomatis akan menghitung semua dependensi terkait. Perhatikan bahwa Anda bisa menggunakan jalur file relatif (ke LOCAL_PATH) maupun absolut.

Kami menyarankan agar menghindari jalur file absolut; jalur relatif akan membuat file Android.mk jadi lebih portabel.

LOCAL_CPP_EXTENSION

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

LOCAL_CPP_EXTENSION := .cxx

Anda bisa menggunakan variabel ini untuk menentukan beberapa ekstensi. Sebagai contoh:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

Anda bisa menggunakan variabel opsional ini untuk menunjukkan bahwa kode Anda mengandalkan fitur C++ tertentu. Variabel ini memungkinkan bendera pengompilasi dan penaut yang tepat selama proses pembangunan. Untuk biner bawaan, variabel ini juga mendeklarasikan fitur mana yang diandalkan biner, sehingga membantu memastikan pekerjaan penautan akhir dengan benar. Kami menyarankan agar Anda bisa menggunakan variabel ini sebagai ganti -frtti dan -fexceptions secara langsung dalam definisi LOCAL_CPPFLAGS.

Penggunaan variabel ini memungkinkan sistem pembangunan menggunakan flag yang sesuai untuk setiap modul. Penggunaan LOCAL_CPPFLAGS menyebabkan pengompilasi menggunakan semua bendera yang ditetapkan untuk semua modul, apa pun kebutuhan sesungguhnya.

Misalnya, untuk menunjukkan bahwa kode Anda menggunakan RTTI (RunTime 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. Misalnya:

LOCAL_CPP_FEATURES := rtti features

Urutan Anda menjelaskan nilai-nilai itu tidaklah penting.

LOCAL_C_INCLUDES

Anda bisa menggunakan variabel opsional ini untuk menetapkan suatu daftar jalur, yang relatif terhadap direktori NDK root, untuk ditambahkan ke jalur pencarian penyertaan saat mengompilasi semua sumber (C, C++ dan Assembly). Misalnya:

LOCAL_C_INCLUDES := sources/foo

Atau bahkan:

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

Definisikan variabel ini sebelum menyetel suatu bendera penyertaan yang sesuai lewat LOCAL_CFLAGS atau LOCAL_CPPFLAGS.

Sistem pembangunan juga menggunakan jalur LOCAL_C_INCLUDES secara otomatis saat meluncurkan proses debug asli dengan ndk-gdb.

LOCAL_CFLAGS

Variabel opsional ini menyetel bendera pengompilasi untuk diteruskan oleh sistem pembangunan saat membangun file sumber C dan C++. Kemampuan untuk melakukannya bisa berguna untuk menetapkan definisi makro tambahan atau opsi kompilasi. Gunakan LOCAL_CPPFLAGS untuk menentukan bendera untuk C++ saja.

Coba untuk tidak mengubah level pengoptimalan/proses debug dalam file Android.mk. Sistem pembangunan bisa menangani setelan ini secara otomatis untuk Anda, menggunakan informasi relevan dalam file [pplication.mk]. Melakukannya dengan cara ini memungkinkan sistem pembangunan menghasilkan file data yang digunakan selama proses debug.

Jalur penyertaan tambahan bisa ditetapkan dengan menuliskan:

LOCAL_CFLAGS += -I<path>,

Akan tetapi, lebih baik menggunakan LOCAL_C_INCLUDES untuk keperluan ini, karena hal itu akan memungkinkan penggunaan jalur yang tersedia untuk proses debug asli dengan ndk-gdb.

LOCAL_CPPFLAGS

Setel bendera pengompilasi opsional yang akan diteruskan saat membangun file sumber C++ saja. Bendera tersebut akan muncul setelah LOCAL_CFLAGS pada baris perintah pengompilasi. Gunakan LOCAL_CFLAGS untuk menentukan bendera baik untuk C dan C++.

LOCAL_STATIC_LIBRARIES

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

Jika modul saat ini berupa pustaka bersama atau file yang dapat dieksekusi, variabel ini akan memaksakan pustaka-pustaka ini ditautkan ke dalam biner hasil.

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

LOCAL_SHARED_LIBRARIES

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

LOCAL_WHOLE_STATIC_LIBRARIES

Variabel ini adalah varian LOCAL_STATIC_LIBRARIES, dan menyatakan bahwa penaut harus memperlakukan modul pustaka terkait sebagai arsip utuh. Untuk informasi selengkapnya mengenai arsip utuh, lihat dokumentasi Id GNU untuk bendera --whole-archive.

Variabel ini berguna saat bila ada dependensi sirkuler di antara sejumlah pustaka statis. Bila Anda menggunakan variabel ini untuk membangun pustaka bersama, variabel ini akan memaksa sistem pembangunan untuk menambahkan semua file objek dari pustaka statis Anda ke biner akhir. Akan tetapi, hal yang sama tidak berlaku saat menghasilkan file yang dapat dieksekusi.

LOCAL_LDLIBS

Variabel ini berisi daftar bendera penaut tambahan untuk digunakan dalam membangun pustaka bersama atau file yang dapat dieksekusi. Ini memungkinkan Anda menggunakan awalan -l untuk meneruskan nama pustaka sistem tertentu. Misalnya, contoh berikut memberi tahu linker untuk menghasilkan modul yang menautkan ke /system/lib/libz.so pada waktu pemuatan:

LOCAL_LDLIBS := -lz

Untuk daftar pustaka sistem yang diekspos, yang nanti bisa Anda tautkan dengan rilis NDK ini, lihat Android NDK Native API.

LOCAL_LDFLAGS

Daftar bendera penaut lain yang akan digunakan sistem pembangunan saat membangun pustaka bersama atau file yang dapat dieksekusi. Misalnya, untuk menggunakan penaut ld.bfd di ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

Secara default, bila sistem pembangunan menemukan referensi yang tidak didefinisikan selagi mencoba membangun pustaka bersama, sistem ini akan melontarkan kesalahan simbol yang tidak didefinisikan. Kesalahan ini bisa membantu Anda menangkap bug dalam kode sumber.

Untuk menonaktifkan pemeriksaan ini, setel variabel ini ke true. Perhatikan, setelan ini dapat menyebabkan pustaka bersama dimuat pada waktu proses.

LOCAL_ARM_MODE

Secara default, sistem pembangunan menghasilkan biner target ARM dalam mode thumb, yang masing-masing petunjuk selebar 16 bit dan ditautkan dengan pustaka STL di direktori thumb/. Mendefinisikan variabel ini sebagai arm memaksa sistem pembangunan menghasilkan file objek dalam mode 32-bit arm. Contoh berikut menampilkan cara melakukannya:

LOCAL_ARM_MODE := arm

Anda juga bisa memerintahkan sistem pembangunan agar hanya membangun sumber tertentu dalam mode arm dengan menambahkan akhiran .arm ke nama file sumber. Misalnya, contoh berikut memberi tahu sistem pembangunan agar selalu mengompilasi bar.c dalam mode ARM, tetapi membangun 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 armeabi-v7a ABI. Variabel ini memungkinkan penggunaan intrinsik ARM Advanced SIMD (NEON) GCC dalam sumber C dan C++, juga petunjuk NEON dalam file Assembly.

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

Atau, Anda bisa menggunakan akhiran .neon untuk menetapkan bahwa sistem pembangunan hanya mengompilasi file sumber tertentu bersama dukungan NEON. Dalam contoh berikut, sistem pembangunan mengompilasi foo.c bersama dukungan thumb dan NEON, bar.c bersama dukungan thumb, dan zoo.c bersama 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 pembangunan mengompilasi kode bersama perlindungan string format. Hal itu akan memaksa kesalahan pengompilasi jika string format non-konstanta digunakan dalam fungsi yang bergaya printf. Perlindungan ini diaktifkan secara default, namun Anda bisa menonaktifkannya dengan menyetel nilai variabel ini ke true. Kami tidak menyarankan melakukannya tanpa alasan yang memaksa.

LOCAL_EXPORT_CFLAGS

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

Misalnya, pertimbangkan sepasang 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 pembangunan meneruskan bendera -DFOO=1 dan -DBAR=2 ke pengompilasi saat membangun bar.c. Juga menambahkan flag yang telah diekspor ke LOCAL_CFLAGS modul agar Anda bisa dengan mudah menggantinya.

Selain itu, hubungan di antara modul bersifat transitif: Jika zoo bergantung pada bar, yang selanjutnya bergantung pada foo, maka zoo juga akan mewarisi semua bendera yang diekspor dari foo.

Terakhir, sistem pembangunan tidak menggunakan bendera yang telah diekspor saat membangun secara lokal (yakni, membangun modul yang benderanya-nya diekspornya). Sehingga, dalam contoh di atas , sistem ini tidak meneruskan -DFOO=1 ke pengompilasi saat membangun foo/foo.c. Untuk membangun secara lokal, gunakan LOCAL_CFLAGS sebagai gantinya.

LOCAL_EXPORT_CPPFLAGS

Variabel ini sama seperti LOCAL_EXPORT_CFLAGS, tetapi hanya untuk bendera C++.

LOCAL_EXPORT_C_INCLUDES

Variabel ini sama seperti LOCAL_EXPORT_CFLAGS, tetapi untuk jalur penyertaan C. Ini akan berguna jika, misalnya, bar.c perlu menyertakan header dari modul foo.

LOCAL_EXPORT_LDFLAGS

Variabel ini sama seperti LOCAL_EXPORT_CFLAGS, tetapi untuk bendera penaut.

LOCAL_EXPORT_LDLIBS

Variabel ini sama seperti LOCAL_EXPORT_CFLAGS, yang memberi tahu sistem pembangunan untuk meneruskan nama pustaka sistem tertentu ke pengompilasi. Tambahkan -l di depan nama setiap pustaka yang Anda tetapkan.

Perhatikan, sistem pembangunan menambahkan bendera penaut yang telah diimpor ke nilai variabel LOCAL_LDLIBS modul Anda. Hal ini dilakukan demikian karena cara kerja penaut Unix.

Variabel ini biasanya berguna bila modul foo merupakan pustaka statis dan memiliki kode yang bergantung pada pustaka sistem. Nanti Anda bisa menggunakan LOCAL_EXPORT_LDLIBS untuk mengekspor dependensi. Misalnya:

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)

Misalnya, sistem pembangunan menempatkan -llog di akhir perintah penaut saat membangun libbar.so. Hal itu akan memberi tahu penaut tentang hal itu, karena libbar.so bergantung pada foo, variabel ini juga bergantung pada pustaka logging sistem.

LOCAL_SHORT_COMMANDS

Setel variabel ini ke true bila modul Anda memiliki sangat banyak sumber dan/atau pustaka statis atau pustaka bersama. Melakukan hal itu akan memaksa sistem pembangunan menggunakan sintaks @ untuk arsip yang berisi file objek antara atau arsip yang menautkan pustaka.

Fitur ini bisa berguna di Windows, yang baris perintahnya maksimum hanya menerima 8191 karakter, yang boleh jadi terlalu kecil bagi proyek yang kompleks. Hal ini juga berdampak pada kompilasi file sumber individual, yang menempatkan hampir semua pengompilasi bendera di dalam file daftar juga.

Perhatikan, nilai selain true akan membalik ke perilaku default. Anda juga bisa mendefinisikan APP_SHORT_COMMANDS dalam file Application.mk untuk memaksa perilaku ini untuk semua modul dalam proyek Anda.

Kami tidak menyarankan pengaktifan fitur ini secara default, karena akan membuat pembangunan jadi lebih lambat.

LOCAL_THIN_ARCHIVE

Atur variabel ini menjadi true saat membangun pustaka statis. Melakukan hal itu akan menghasilkan arsip tipis, yakni suatu file pustaka yang tidak berisi file objek, melainkan cuma jalur file ke objek sesungguhnya yang biasanya akan berisi file objek tersebut.

Ini berguna untuk mengurangi ukuran keluaran pembangunan Anda. Kelemahannya adalah pustaka demikian tidak bisa dipindahkan ke lokasi berbeda (semua jalur di dalamnya bersifat relatif).

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

LOCAL_FILTER_ASM

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

  1. Sistem pembangunan akan menghasilkan file assembly sementara dari file sumber C atau C++, sebagai ganti mengompilasinya ke dalam file objek.
  2. Sistem pembangunan mengeksekusi perintah shell dalam LOCAL_FILTER_ASM atas semua file assembly sementara dan atas semua file assembly yang tercantum dalam LOCAL_SRC_FILES, sehingga menghasilkan file assembly sementara lainnya.
  3. Sistem pembangunan mengompilasi file assembly yang telah difilter ini ke dalam file objek.

Misalnya:

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" sama dengan compiler, "2" sama dengan filter, dan "3" sama dengan assembler. Filter harus berupa perintah shell mandiri yang menggunakan nama file masukan sebagai argumen pertamanya, dan nama file keluaran sebagai argumen kedua. Misalnya:

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; fungsi itu akan mengembalikan informasi tekstual.

my-dir

Makro ini mengembalikan jalur makefile yang terakhir disertakan, yang biasanya adalah direktori Android.mk terbaru. my-dir berguna untuk menentukan LOCAL_PATH pada awal file Android.mk. Misalnya:

LOCAL_PATH := $(call my-dir)

Karena cara kerja GNU Make, yang sebenarnya dikembalikan makro ini jalur makefile terakhir yang disertakan sistem pembangunan saat mengurai skrip pembangunan. Karena alasan ini, Anda tidak boleh memanggil my-dir setelah menyertakan 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

Masalah yang ada di sini adalah karena panggilan kedua ke my-dir mendefinisikan LOCAL_PATH sebagai $PATH/foo sebagai ganti $PATH, karena di situlah penyertaan terbaru ditunjukkan.

Anda bisa menghindari masalah ini dengan menempatkan penyertaan tambahan setelah semua yang lainnya di file Android.mk. Misalnya:

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 menstrukturkan file dengan cara ini, simpanlah nilai panggilan my-dir pertama ke dalam variabel lain. Misalnya:

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

Mengembalikan daftar file Android.mk yang berada di semua subdirektori jalur my-dir saat ini.

Anda bisa menggunakan fungsi ini untuk menyediakan hierarki direktori sumber yang tersarang-dalam ke sistem pembangunan. Secara default, NDK hanya mencari file dalam direktori yang berisi file Android.mk.

this-makefile

Mengembalikan jalur makefile saat ini (yang digunakan sistem pembangunan memanggil fungsi).

parent-makefile

Mengembalikan jalur makefile induk dalam pohon include (jalur makefile yang menyertakan makefile saat ini).

grand-parent-makefile

Mengembalikan jalur makefile induk dari induk dalam pohon penyertaan (jalur makefile yang menyertakan makefile saat ini).

import-module

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

$(call import-module,<name>)

Dalam contoh ini, sistem pembangunan mencari modul yang memiliki tag <name> dalam daftar direktori yang direferensikan oleh variabel NDK_MODULE_PATH lingkungan , dan menyertakan file Android.mk secara otomatis untuk Anda.