Android.mk

このページでは、ndk-build で使用される Android.mk ビルドファイルの構文について説明します。

概要

Android.mk ファイルはプロジェクトの jni/ ディレクトリのサブディレクトリに存在し、ビルドシステムに提供されるソースと共有ライブラリの情報が記述されています。このファイルは実際には GNU Makefile の小さなフラグメントであり、ビルドシステムはこのファイルを 1 回または複数回解析します。Android.mk ファイルは、Application.mk、ビルドシステム、環境変数で定義されないプロジェクトレベルの設定を定義するのに役立ちます。また、特定のモジュールに対するプロジェクトレベルの設定をオーバーライドすることもできます。

Android.mk の構文を使用して、ソースをモジュールにグループ化できます。モジュールは、静的ライブラリ、共有ライブラリ、スタンドアロン実行ファイルのいずれかです。Android.mk ファイルごとに 1 つ以上のモジュールを定義でき、同じソースファイルを複数のモジュールで使用できます。ビルドシステムは共有ライブラリのみをアプリパッケージ内に配置します。また、静的ライブラリから共有ライブラリを生成することができます。

ビルドシステムは、ライブラリのパッケージ化に加えて、さまざまな処理を自動的に行います。たとえば、ヘッダーファイルや、生成されるファイル間の明示的な依存関係を Android.mk ファイルにリストする必要はありません。そのような関係は、NDK ビルドシステムが自動的に計算します。したがって、将来の NDK リリースでは、Android.mk ファイルを編集しなくても、新しいツールチェーンやプラットフォームのサポートを利用できます。

このファイルの構文は、完全な Android オープンソースプロジェクトで配布される Android.mk ファイルで使用されているものとよく似ています。それらのファイルを使用するビルドシステム実装は異なりますが、アプリ開発者が外部ライブラリのソースコードを再利用しやすくするために、設計上の意図により類似した構文が採用されています。

基本

構文について詳しく見る前に、Android.mkAndroid.mk ファイルの基本的な内容について理解しておくことをおすすめします。このセクションでは、Hello-JNI サンプルにある Android.mk ファイルを使用して、各行が果たす機能について説明します。

Android.mk ファイルは、LOCAL_PATH 変数の定義から始める必要があります。

LOCAL_PATH := $(call my-dir)

この変数は、開発ツリー内のソースファイルの場所を示します。この行の my-dir マクロ関数はビルドシステムが提供する関数で、現在のディレクトリ（Android.mk ファイル自身が格納されているディレクトリ）のパスを返します。

次の行で、CLEAR_VARS 変数を宣言します。値はビルドシステムから与えられます。

include $(CLEAR_VARS)

CLEAR_VARS 変数は、LOCAL_MODULE、LOCAL_SRC_FILES、LOCAL_STATIC_LIBRARIES など、多くの LOCAL_XXX 変数をクリアする特別な GNU Makefile をポイントします。ただし、LOCAL_PATH はクリアしません。この変数は値を保持する必要があります。システムは、すべての変数がグローバルである単一の GNU Make 実行コンテキスト内ですべてのビルドコントロールファイルを解析するからです。各モジュールについて記述する前に、この変数を宣言（再宣言）する必要があります。

次に、ビルドするモジュールの名前を LOCAL_MODULE 変数に格納します。この変数は、アプリ内の各モジュールで 1 回ずつ使用します。

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 変数は、直近の include 以降に LOCAL_XXX 変数で定義されたすべての情報を収集する GNU Makefile スクリプトをポイントします。このスクリプトがビルドの対象とビルドの方法を決定します。

サンプルディレクトリには、もっと複雑な例としてコメント付きの Android.mk ファイルが用意されているので、そちらも参考になります。また、そのサンプルの Android.mk ファイルについては、サンプル: native-activity に詳しい説明があります。このセクションで取り上げた変数の詳細については、変数とマクロをご覧ください。

変数とマクロ

ビルドシステムには、Android.mk ファイルで使用できる変数が多数用意されています。大半の変数には、あらかじめ値が割り当てられています。値が割り当てられていない変数には、手動で割り当てます。

用意されている変数に加えて、独自の変数を定義することもできます。ただし、NDK ビルドシステムでは、次の変数名が予約済みであることにご注意ください。

LOCAL_ で始まる名前。LOCAL_MODULE など。
PRIVATE_、NDK_、APP で始まる名前。これらはビルドシステムが内部的に使用します。
my-dir などの小文字の名前。これらもビルドシステムが内部的に使用します。

Android.mk ファイルで独自のコンビニエンス変数を定義する必要がある場合は、名前の先頭に MY_ を付けることをおすすめします。

NDK 定義のインクルード変数

このセクションでは、Android.mk ファイルの解析前にビルドシステムが定義する GNU Make 変数について説明します。特定の状況では、NDK は変数の一部について毎回異なる定義を使用して複数回 Android.mk ファイルを解析することがあります。

CLEAR_VARS

この変数は、下記の「デベロッパー定義の変数」のリストにあるほぼすべての LOCAL_XXX 変数の定義をクリアするビルドスクリプトをポイントします。この変数を使用して、新しいモジュールの記述の前にこのスクリプトをインクルードします。この変数を使用するための構文は次のとおりです。

include $(CLEAR_VARS)

BUILD_EXECUTABLE

この変数は、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 と同様の変数で、ビルド済み静的ライブラリを対象とします。ビルド済みライブラリの使用方法については、ビルド済みライブラリを使用するをご覧ください。

ターゲット情報変数

ビルドシステムは、通常は Application.mk ファイルで定義される APP_ABI 変数によって指定される ABI ごとに 1 回ずつ Android.mk を解析します。APP_ABI が all の場合、ビルドシステムは NDK がサポートする ABI ごとに 1 回ずつ Android.mk を解析します。このセクションでは、ビルドシステムが Android.mk を解析するたびに定義する変数について説明します。

TARGET_ARCH

ビルドシステムがこの Android.mk ファイルを解析する際にターゲットとする CPU ファミリー。この変数は、arm、arm64、x86、x86_64 のいずれかです。

TARGET_PLATFORM

ビルドシステムがこの Android.mk ファイルを解析する際にターゲットとする Android API レベル番号。たとえば、Android 5.1 システムイメージは Android API レベル 22（android-22）に対応します。プラットフォーム名と、対応する Android システムイメージの完全なリストについては、ネイティブ API をご覧ください。この変数を使用する構文の例を次に示します。

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

TARGET_ARCH_ABI

ビルドシステムがこの Android.mk ファイルを解析する際にターゲットとする ABI。サポート対象の CPU とアーキテクチャに使用される各 ABI 設定を表 1 に示します。

表 1. CPU とアーキテクチャに使用される各 ABI 設定

CPU とアーキテクチャ	設定
ARMv7	`armeabi-v7a`
ARMv8 AArch64	`arm64-v8a`
i686	`x86`
x86-64	`x86_64`

CPU と ABI の組み合わせのターゲットが ARMv8 AArch64 かどうかをチェックする方法の例を次に示します。

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

アーキテクチャ ABI とそれに関連する互換性の問題の詳細については、Android ABI をご覧ください。

今後も、別の値の新しいターゲット ABI が随時用意されていく予定です。

TARGET_ABI

ターゲット Android API レベルと ABI の連結。これは、実際のデバイスに対応する特定のターゲットシステムイメージをテストする際に特に役立ちます。たとえば、Android API レベル 22 を搭載した 64 ビット ARM デバイスをチェックする場合は、次のように指定します。

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

モジュール記述変数

このセクションでは、ビルドシステムに対してモジュールを記述する変数について説明します。モジュールの記述は、次の基本フローに沿って行う必要があります。

CLEAR_VARS 変数を使用して、モジュールに関連付けられている変数を初期化するか、変数の定義をクリアします。
モジュールの記述に使用する変数に値を割り当てます。
BUILD_XXX 変数を使用して、モジュールに適したビルドスクリプトを使用するよう NDK ビルドシステムを設定します。

LOCAL_PATH

この変数は、現在のファイルのパスを指定するために使用します。Android.mk ファイルの先頭で定義する必要があります。指定方法は次のとおりです。

LOCAL_PATH := $(call my-dir)

CLEAR_VARS がポイントするスクリプトは、この変数をクリアしません。したがって、Android.mk ファイル内に複数のモジュールを記述する場合でも、一度定義するだけで済みます。

LOCAL_MODULE

この変数は、モジュールの名前を格納します。指定する名前は、すべてのモジュール名の中で一意でなければならず、名前にスペースを含めることはできません。この変数は、スクリプト（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_EXTENSION

必要に応じてこの変数を使用することで、C++ ソースファイル用の .cpp 以外のファイル拡張子を指定できます。たとえば、次の行では拡張子を .cxx に変更しています（ドットを含めて指定する必要があります）。

LOCAL_CPP_EXTENSION := .cxx

この変数では、複数の拡張子を指定することができます。たとえば、次のようになります。

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

必要に応じてこの変数を使用することで、コードが特定の C++ 機能に依存していることを示すことができます。これにより、ビルドプロセス中に適切なコンパイラフラグとリンカーフラグが有効になります。ビルド済みバイナリの場合、この変数でバイナリが依存する機能を宣言することで、最終リンクを正常に機能させることができます。LOCAL_CPPFLAGS 定義で -frtti と -fexceptions を直接有効にする代わりに、この変数を使用することをおすすめします。

この変数を使用した場合、ビルドシステムは、モジュールごとに適切なフラグを使用できるようになります。一方、LOCAL_CPPFLAGS を使用した場合、実際に必要かどうかにかかわらず、コンパイラは、すべてのモジュールに対してすべての指定フラグを使用します。

たとえば、コードが RTTI（実行時型情報）を使用していることを示すには、次のように記述します。

LOCAL_CPP_FEATURES := rtti

コードが C++ 例外を使用していると示すには、次のように記述します。

LOCAL_CPP_FEATURES := exceptions

この変数では、複数の値を指定することもできます。次に例を示します。

LOCAL_CPP_FEATURES := rtti features

値はどの順番で記述しても構いません。

LOCAL_C_INCLUDES

必要に応じてこの変数を使用することで、NDK の root ディレクトリからの相対パスのリストを指定して、すべてのソース（C、C++、アセンブリ）をコンパイルする際のインクルード検索パスに追加できます。次に例を示します。

LOCAL_C_INCLUDES := sources/foo

次のように指定することもできます。

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

この変数を定義した後、LOCAL_CFLAGS または LOCAL_CPPFLAGS を使用して、対応するインクルードフラグを設定します。

また、ビルドシステムは、ndk-gdb を使用してネイティブデバッグを起動する際、自動的に LOCAL_C_INCLUDES パスを使用します。

LOCAL_CFLAGS

必要に応じてこの変数を使用することで、C / C++ ソースファイルのビルド時にビルドシステムが渡すコンパイラフラグを設定することができます。この機能は、マクロ定義またはコンパイルオプションを追加で指定する際に有用です。C++ 専用のフラグを指定する場合は、LOCAL_CPPFLAGS を使用します。

Android.mk ファイル内で最適化レベル / デバッグレベルを変更しないようにしてください。ビルドシステムは、Application.mk ファイル内の関連情報を使用して、この設定を自動的に処理できます。これにより、デバッグ時に役立つデータファイルが自動的に生成されます。

追加のインクルードパスを指定するには、次のように記述します。

LOCAL_CFLAGS += -I<path>,

ただし、この目的のためには LOCAL_C_INCLUDES を使用することをおすすめします。こちらの方法であれば、ndk-gdb を使用したネイティブデバッグでも、パスを利用できるようになります。

LOCAL_CPPFLAGS

ビルド対象が C++ ソースファイルだけの場合に渡されるコンパイラフラグのセットで、必要に応じて指定します。コンパイラのコマンドラインでは、LOCAL_CFLAGS の後に配置されます。C と C++ 両方のフラグを指定する場合は、LOCAL_CFLAGS を使用します。

LOCAL_STATIC_LIBRARIES

この変数は、現在のモジュールが依存している静的ライブラリモジュールのリストを格納します。

現在のモジュールが共有ライブラリまたは実行ファイルの場合、この変数は、生成されたバイナリに対して自動的に依存先ライブラリをリンクします。

現在のモジュールが静的ライブラリの場合、この変数は、現在のモジュールに依存している他のモジュールもリスト内の依存先ライブラリに依存することを示すだけで、リンクは行いません。

LOCAL_SHARED_LIBRARIES

この変数は、このモジュールが実行時に依存する共有ライブラリのモジュールのリストを格納します。この情報は、リンク時に、対応する情報を生成ファイル内に埋め込む際に必要になります。

LOCAL_WHOLE_STATIC_LIBRARIES

この変数は LOCAL_STATIC_LIBRARIES のバリアントで、関連付けられているライブラリモジュールをリンカーが完全アーカイブとして扱う必要があることを示します。完全アーカイブの詳細については、--whole-archive フラグに関する GNU ld のドキュメントをご覧ください。

この変数は、複数の静的ライブラリ間で依存関係が循環している場合に役に立ちます。この変数を使用して共有ライブラリをビルドすると、ビルドシステムは、静的ライブラリ内のすべてのオブジェクトファイルを自動的に最終バイナリに追加します。ただし、実行ファイルの生成時は、このような処理は行われません。

LOCAL_LDLIBS

この変数は、共有ライブラリまたは実行ファイルをビルドする際に使用する追加のリンカーフラグのリストを格納します。これにより、特定のシステムライブラリの名前を渡すための -l プレフィックスを使用できます。たとえば、次の例では、読み込み時に /system/lib/libz.so にリンクするモジュールを生成するようリンカーに指示しています。

LOCAL_LDLIBS := -lz

この NDK リリースでリンク可能な公開システムライブラリのリストについては、ネイティブ API をご覧ください。

LOCAL_LDFLAGS

共有ライブラリまたは実行ファイルをビルドする際にビルドシステムが使用する他のリンカーフラグのリストを格納します。たとえば、ARM/X86 で ld.bfd リンカーを使用するには、次のように記述します。

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

デフォルトでは、ビルドシステムが共有ライブラリをビルドする際に未定義の参照が検出されると、「undefined symbol」のエラーがスローされます。このエラーは、ソースコード内のバグを検出するのに役立ちます。

このチェックを無効にするには、この変数を true に設定します。ただし、そのように設定すると、実行時に共有ライブラリが読み込まれる可能性があります。

LOCAL_ARM_MODE

デフォルトでは、ビルドシステムは ARM ターゲットバイナリを Thumb モードで生成します。このモードでは、各命令は 16 ビット幅で、thumb/ ディレクトリの STL ライブラリにリンクされます。この変数を arm として定義すると、ビルドシステムはモジュールのオブジェクトファイルを 32 ビット arm モードで生成します。次の例はその方法を示しています。

LOCAL_ARM_MODE := arm

また、ソースファイル名に .arm サフィックスを付加すると、arm モードで特定のソースのみをビルドするようビルドシステムに指示できます。たとえば、次の例では、bar.c を常に ARM モードでコンパイルする一方で、LOCAL_ARM_MODE の値に従って foo.c をビルドするようビルドシステムに指示しています。

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON

この変数は、armeabi-v7a ABI をターゲットとする場合にのみ意味を持ちます。この変数により、C / C++ ソースで ARM Advanced SIMD（NEON）コンパイラ組み込み関数を使用し、アセンブリファイルで NEON 命令を使用できます。

すべての ARMv7 ベースの CPU が NEON 命令セット拡張機能をサポートしているわけではありません。そのため、実行時にこのコードを安全に使用できるように、実行時検出を行う必要があります。詳細については、Neon のサポートと CPU 機能をご覧ください。

または、.neon サフィックスを使用して、NEON をサポートする特定のソースファイルのみをコンパイルするようビルドシステムに指示することもできます。次の例では、ビルドシステムは Thumb および NEON サポートを使用して foo.c をコンパイルしています。また、Thumb サポートを使用して bar.c を、ARM および NEON サポートを使用して zoo.c をコンパイルしています。

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

両方のサフィックスを使用する場合は、必ず .neon の前に .arm を配置してください。

LOCAL_DISABLE_FORMAT_STRING_CHECKS

デフォルトでは、ビルドシステムは、フォーマット文字列の保護を有効にした状態でコードをコンパイルします。この設定を行うと、printf スタイルの関数で定数以外のフォーマット文字列が使用されている場合に、コンパイラエラーを強制的に発生させることができます。この保護はデフォルトで有効になっていますが、この変数の値を true に設定すると無効にできます。ただし、やむを得ない理由がない限り、無効にしないことをおすすめします。

LOCAL_EXPORT_CFLAGS

この変数は、C / C++ コンパイラフラグのセットを記録して、LOCAL_STATIC_LIBRARIES 変数または LOCAL_SHARED_LIBRARIES 変数を介してこのモジュールを使用する別のモジュールの LOCAL_CFLAGS 定義に追加します。

たとえば、foo と、foo に依存する bar というモジュールのペアがあるとします。

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)

この場合、ビルドシステムは bar.c をビルドする際に、-DFOO=1 フラグと -DBAR=2 フラグをコンパイラに渡します。さらに、エクスポートされたフラグをモジュールの LOCAL_CFLAGS の先頭に付加します。これにより、それらを簡単にオーバーライドできます。

また、モジュール間の関係は推移的です。zoo が bar に依存し、後者が foo に依存する場合、zoo は foo からエクスポートされたすべてのフラグも継承します。

なお、ビルドシステムは、ローカルでビルドを行うとき（フラグをエクスポートするモジュールをビルドするとき）は、エクスポートされたフラグを使用しません。したがって、上記の例では、foo/foo.c をビルドする際に -DFOO=1 をコンパイラに渡しません。ローカルでビルドする場合は、代わりに 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)

この例では、ビルドシステムは libbar.so をビルドする際にリンカーコマンドの最後に -llog を配置しています。それにより、libbar.so が foo に依存しており、したがってシステムロギングライブラリにも依存していることをリンカーに伝えられます。

LOCAL_SHORT_COMMANDS

モジュールにソースまたは依存元の静的ライブラリ / 共有ライブラリが多数含まれている場合は、この変数を true に設定します。そうすると、ビルドシステムは、中間オブジェクトファイルまたはリンクライブラリを含むアーカイブに対して @ 構文を使用します。

この機能は Windows で有用です。Windows では、コマンドラインの許容文字数が最大 8,191 文字であり、複雑なプロジェクトでは文字数が足りなくなる可能性があるからです。また、この機能は、リストファイル内にほぼすべてのコンパイラフラグを配置している個々のソースファイルのコンパイルにも効果があります。

true 以外の値を指定すると、デフォルトの動作に戻ります。Application.mk ファイルで APP_SHORT_COMMANDS を定義して、プロジェクト内のすべてのモジュールにこの動作を強制することもできます。

この機能を有効にするとビルドの速度が低下するため、デフォルトでは有効にしないことをおすすめします。

LOCAL_THIN_ARCHIVE

静的ライブラリをビルドする場合は、この変数を true に設定します。この設定により、シンアーカイブが生成されます。シンアーカイブは、オブジェクトファイルを含まず、通常含まれる実際のオブジェクトへのファイルパスのみを含むライブラリファイルです。

これは、ビルド出力のサイズを抑える際に役に立ちます。ただし、ライブラリを別の場所に移動できないという欠点があります（ライブラリ内のパスはすべて相対パスになります）。

有効な値は、true、false、または空です。APP_THIN_ARCHIVE 変数を使用して、Application.mk ファイルにデフォルト値を設定できます。

LOCAL_FILTER_ASM

この変数は、LOCAL_SRC_FILES で指定したファイルからアセンブリファイルの抽出や生成を行う際、ビルドシステムがフィルタリング用に使用するシェルコマンドを定義します。この変数を定義すると、次の処理が発生します。

ビルドシステムは、C / C++ ソースファイルをオブジェクトファイルにコンパイルせず、それらのソースファイルから一時的アセンブリファイルを生成します。
ビルドシステムは、一時的アセンブリファイルと、LOCAL_SRC_FILES 内のリストにあるアセンブリファイルに対して、LOCAL_FILTER_ASM 内のシェルコマンドを実行します。これにより、別の一時的アセンブリファイルが生成されます。
ビルドシステムは、フィルタ済みのアセンブリファイルをオブジェクトファイルにコンパイルします。

次に例を示します。

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」はアセンブラに相当します。フィルタはスタンドアロンのシェルコマンドで、入力ファイルの名前を第 1 引数に取り、出力ファイルの名前を第 2 引数に取ります。次に例を示します。

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

NDK が提供する関数マクロ

このセクションでは、NDK が提供する GNU Make 関数マクロについて説明します。$(call <function>) を使用してマクロを評価すると、テキスト情報が返されます。

my-dir

このマクロは、最後にインクルードされた Makefile のパスを返します。これは、通常は現在の Android.mk のディレクトリです。my-dir は、Android.mk ファイルの先頭で LOCAL_PATH を定義するのに便利です。次に例を示します。

LOCAL_PATH := $(call my-dir)

GNU Make の仕様上、このマクロが実際に返す値は、ビルドスクリプトの解析時にビルドシステムがインクルードした最後の Makefile のパスになります。そのため、別のファイルをインクルードした後は 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 の 2 回目の呼び出しで、LOCAL_PATH が $PATH ではなく $PATH/foo として定義されている（直近のインクルードでポイントした場所であるため）ことです。

この問題を防ぐには、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

現在の my-dir パスのすべてのサブディレクトリにある Android.mk ファイルのリストを返します。

この関数を使用すると、深くネストされたソースディレクトリ階層をビルドシステムに提供できます。デフォルトでは、NDK は Android.mk ファイルが含まれるディレクトリ内のファイルのみを検索します。

this-makefile

現在の Makefile のパスを返します（パスの起点は、ビルドシステムがこの関数を呼び出した場所になります）。

parent-makefile

インクルードツリー内の親 Makefile のパス（現在の Makefile を含む Makefile のパス）を返します。

grand-parent-makefile

インクルードツリー内の祖父母 Makefile のパス（現在の Makefile を含む Makefile のパス）を返します。

import-module

この関数を使用すると、モジュールの Android.mk ファイルをモジュールの名前で検索してインクルードできます。一般的な例を次に示します。

$(call import-module,<name>)

この例では、ビルドシステムは NDK_MODULE_PATH 環境変数が参照するディレクトリのリスト内で <name> タグが付けられたモジュールを検索し、そのモジュールの Android.mk ファイルを自動的にインクルードします。