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 という名前のライブラリが生成されます。

注: モジュール名の先頭がすでに lib である場合、ビルドシステムは追加の lib プレフィックスを付加しません。現在のモジュール名がそのまま使用され、.so 拡張子が付加されます。したがって、たとえばソースファイルが元々 libfoo.c という名前だった場合は、libfoo.so という名前の共有オブジェクト ファイルが生成されます。これは、Android プラットフォーム ソースにより Android.mk ファイルから生成されるライブラリをサポートするためです。このようなライブラリの名前はすべて lib から始まります。

次の行で、ソースファイルを指定します。ファイルが複数ある場合はスペースで区切ります。

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)

注: ほとんどの Android アプリには実行ファイルが含まれませんが、実行ファイルは単体テストやその他のデバッグツールの作成に役立ちます。

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

モジュール記述変数

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

1. CLEAR_VARS 変数を使用して、モジュールに関連付けられている変数を初期化するか、変数の定義をクリアします。
2. モジュールの記述に使用する変数に値を割り当てます。
3. 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 ファイルの移植性が高くなります。

注: ビルドファイル内では、必ず Unix スタイルのフォワード スラッシュ（/）を使用してください。ビルドシステムは、Windows スタイルのバックスラッシュ（\）を適切に処理しません。

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_ASFLAGS

.s ファイルまたは .S ファイルをビルドするときに Clang に渡されるフラグ。

注意: これは、yasm ソースに使用される名前である LOCAL_ASMFLAGS とは異なります。

LOCAL_ASMFLAGS

.asm ファイルをビルドするときに yasm に渡されるフラグ。

注意: これは、yasm 以外のソースに使用される名前である LOCAL_ASFLAGS とは異なります。

LOCAL_CFLAGS

C、C++、一部のアセンブリ（.s と .S、.asm は除く）ソースファイルをビルドするときに Clang に渡されるフラグ。この機能は、マクロ定義またはコンパイル オプションを追加で指定する際に有用です。C++ 専用のフラグを指定する場合は、LOCAL_CPPFLAGS を使用します。C 専用のフラグを指定するには、LOCAL_CONLYFLAGS を使用します。

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

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

LOCAL_CFLAGS += -I<path>,

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

LOCAL_CONLYFLAGS

C ソースのコンパイル時に Clang に渡されるフラグ。LOCAL_CFLAGS とは異なり、LOCAL_CONLYFLAGS は C++ ソースまたはアセンブリ ソースをコンパイルするときに Clang に渡されません。

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 をご覧ください。

注: 静的ライブラリに対してこの変数を定義した場合、ビルドシステムはこの変数を無視し、ndk-build は警告を出力します。

LOCAL_LDFLAGS

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

LOCAL_LDFLAGS += -fuse-ld=bfd

注: 静的ライブラリに対してこの変数を定義しても、ビルドシステムは変数を無視し、ndk-build は警告を出力します。

LOCAL_ALLOW_UNDEFINED_SYMBOLS

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

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

注: 静的ライブラリに対してこの変数を定義した場合、ビルドシステムはこの変数を無視し、ndk-build は警告を出力します。

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

注: Application.mk ファイルの APP_OPTIM を debug に設定して、ビルドシステムが ARM バイナリを生成するように指定することもできます。ツールチェーン デバッガは Thumb コードを適切に処理しないため、debug を指定すると強制的に 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 で指定したファイルからアセンブリ ファイルの抽出や生成を行う際、ビルドシステムがフィルタリング用に使用するシェルコマンドを定義します。この変数を定義すると、次の処理が発生します。

1. ビルドシステムは、C / C++ ソースファイルをオブジェクト ファイルにコンパイルせず、それらのソースファイルから一時的アセンブリ ファイルを生成します。
2. ビルドシステムは、一時的アセンブリ ファイルと、LOCAL_SRC_FILES 内のリストにあるアセンブリ ファイルに対して、LOCAL_FILTER_ASM 内のシェルコマンドを実行します。これにより、別の一時的アセンブリ ファイルが生成されます。
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」はアセンブラに相当します。 フィルタはスタンドアロンのシェルコマンドで、入力ファイルの名前を第 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 ファイルを自動的にインクルードします。