Android.mk

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

概要

Android.mk ファイルはプロジェクトの jni/ ディレクトリのサブディレクトリにあり、ビルドシステム向けのソースと共有ライブラリが記述されています。 このファイルは実際は GNU Makefile のごく一部であり、ビルドシステムによって一度以上解析されます。 Android.mk ファイルは、Application.mk、ビルドシステム、環境変数では定義されていない、プロジェクト全体にわたる設定を定義するために使われます。 特定の「モジュール」に関するプロジェクト全体の設定をオーバーライドすることもできます。

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

ライブラリのパッケージ化に加えて、ビルドシステムでは、自動的に、その他のさまざまな詳細が処理されます。 たとえば、ヘッダー ファイルまたは生成されたファイル間の明示的な依存関係を Android.mk ファイルに記載する必要はありません。 代わりに NDK ビルドシステムによって、自動でこれらの関係が計算されます。 その結果、今後の NDK リリースでも、Android.mk ファイルを編集せずに新しいツールチェーンまたはプラットフォームのサポートを受けることができます。

このファイルの構文は、Android オープンソース プロジェクト全体で公開されている Android.mk ファイルに使用されている構文とよく似ています。 このファイルを使用するビルドシステムの実装が異なっていてもファイルの内容が類似しているのは、アプリのデベロッパーが外部ライブラリ向けにソースコードを容易に再利用できるよう、意図的に設計された結果です。

基本

Android.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_MODULELOCAL_SRC_FILESLOCAL_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 ファイルも用意されていますので、そちらも参照してください。 さらに、サンプル: native-activity には、サンプルの Android.mk ファイルに関する詳しい説明があります。 次の変数とマクロでは、このセクションの変数の詳細について説明します。

変数とマクロ

ビルドシステムには、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_SHARED_LIBRARY

この変数は、LOCAL_XXX 変数で指定したモジュールに関するすべての情報を収集し、リストしたソースからターゲットの共有ライブラリをビルドする方法を指定するビルド スクリプトを指します。 このスクリプトを使用する場合、少なくとも LOCAL_MODULELOCAL_SRC_FILES に値を指定しておく必要があることに注意してください(これらの変数の詳細については、モジュール記述変数をご覧ください)。

この変数を使用する構文は次のとおりです。

include $(BUILD_SHARED_LIBRARY)

共有ライブラリ変数によって、ビルドシステムで .so 拡張子のライブラリ ファイルが生成されます。

BUILD_STATIC_LIBRARY

静的ライブラリのビルドに使用する BUILD_SHARED_LIBRARY のバリアント。 ビルドシステムでは静的ライブラリがプロジェクトまたはパッケージにコピーされませんが、それらを共有ライブラリのビルドに使用することができます(後述の LOCAL_STATIC_LIBRARIESLOCAL_WHOLE_STATIC_LIBRARIES をご覧ください)。 この変数を使用する構文は次のとおりです。

include $(BUILD_STATIC_LIBRARY)

静的ライブラリ変数によって、ビルドシステムで .a 拡張子のライブラリが生成されます。

PREBUILT_SHARED_LIBRARY

事前にビルドされた共有ライブラリの指定に使用するビルド スクリプトを指します。 BUILD_SHARED_LIBRARYBUILD_STATIC_LIBRARY の場合と異なり、ここでは LOCAL_SRC_FILES の値をソースファイルにはできません。 foo/libfoo.so のように、事前にビルドされた共有ライブラリへのシングルパスである必要があります。 この変数を使用する構文は次のとおりです。

include $(PREBUILT_SHARED_LIBRARY)

LOCAL_PREBUILTS 変数を使用して、別のモジュールの事前にビルドされたライブラリを参照することもできます。 事前ビルドの使用方法については、[ビルド済みライブラリの使用]をご覧ください。

PREBUILT_STATIC_LIBRARY

事前にビルドされた静的ライブラリが対象であることを除き、PREBUILT_SHARED_LIBRARY と同じです。 事前ビルドの使用方法については、[ビルド済みライブラリの使用]をご覧ください。

ターゲット情報変数

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

TARGET_ARCH

ビルドシステムでこの Android.mk ファイルが解析されるときに対象となる CPU ファミリー。 この変数は、armarm64x86x86_64 のいずれかです。

TARGET_PLATFORM

ビルドシステムでこの Android.mk ファイルが解析されるときに対象となる Android API レベル番号。 たとえば、Android 5.1 システム イメージは、Android API レベル 22: android-22 に対応します。 プラットフォーム名と対応する Android システム イメージの一覧については、Android NDK ネイティブ API をご覧ください。 以下の例は、この変数を使用するための構文を示しています。

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

TARGET_ARCH_ABI

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

表 1. 各 CPU とアーキテクチャの ABI 設定。

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

次の例は、ARMv8 AArch64 をターゲットの CPU と ABI の組み合わせとして設定する方法を示します。

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

アーキテクチャ ABI と関連する互換性の問題については、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"

生成されたモジュールに libLOCAL_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 ファイルで最適化/デバッグレベルを変更しないようにしてください。 ビルドシステムでは、この設定が [pplication.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 のバリアントで、関連付けられているライブラリ モジュールを「完全アーカイブ」としてリンカーで処理する必要があることを示します。 完全アーカイブの詳細については、GNU ld のドキュメント--whole-archive フラグをご覧ください。

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

LOCAL_LDLIBS

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

LOCAL_LDLIBS := -lz

この NDK リリースでリンク可能な公開システム ライブラリの一覧については、Android 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 モードで行い、foo.c のビルドは LOCAL_ARM_MODE の値に従って行うように、ビルドシステムに指示しています。

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON

この変数は armeabi-v7a ABI をターゲットとしている場合のみ重要になります。 C ソースファイルと C++ ソースファイルで ARM 拡張 SIMD (NEON)コンパイラ イントリンシクスを、アセンブリ ファイルで NEON 命令を使用できるようにします。

ARMv7 ベースのすべての CPU が NEON 命令セットの拡張機能をサポートするわけではないことに注意してください。 このため、ランタイム検出を実行して、このコードを実行時に安全に使用できるようにします。 詳細については、NEON サポートcpufeatures ライブラリをご覧ください。

または .neon 拡張子を使用して、ビルドシステムで特定のファイルだけ NEON を有効にしてビルドするように指定することも可能です。 次の例では、ビルドシステムで、foo.c が Thumb および NEON サポートで、bar.c が Thumb サポートで、zoo.c が ARM と NEON サポートでコンパイルされます。

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

両方の拡張子を使用する場合、.arm.neon よりも先にする必要があります。

LOCAL_DISABLE_FORMAT_STRING_CHECKS

既定では、ビルドシステムではフォーマット文字列が保護されてコードがコンパイルされます。 この方式のコンパイルでは、printf スタイルの関数で非定数フォーマット文字列が使用されている場合、コンパイル エラーが発生します。 この保護は既定で有効になっていますが、この変数の値を true に設定すると無効にすることができます。 設定を無効にする理由が明白でない限り、この操作はお勧めしません。

LOCAL_EXPORT_CFLAGS

この変数には一連の C/C++ コンパイラ フラグを指定します。これは、LOCAL_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 の先頭に付加されるため、簡単にオーバーライドできるようになります。

さらに、モジュール間の関係が推移的です。つまり、zoobar に依存していると、foo にも依存していることになり、zoofoo からエクスポートされるすべてのフラグも継承します。

ビルドシステムでは、ローカルビルド(フラグをエクスポートしているモジュールのビルドなど)の場合、エクスポートされるフラグが使用されません。 したがって、上記の例で、ビルドシステムでは、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.sofoo に依存するため、システムのロギング ライブラリにも依存することをリンカーに通知します。

LOCAL_SHORT_COMMANDS

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

Windows ではコマンドラインの許容文字数が最大 8191 文字であり、複雑なオブジェクトには足りない可能性があるため、この機能が特に役に立ちます。 また、リストファイル内にほぼすべてのコンパイラ フラグを持つ、個々のソースファイルのコンパイルにも効果があります。

true 以外のすべての値は既定の動作に戻されることに注意してください。 APP_SHORT_COMMANDSApplication.mk ファイルに定義して、プロジェクト内のすべてのモジュールにこの動作を強制することもできます。

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

LOCAL_THIN_ARCHIVE

静的ライブラリをビルドするときに、この変数を true に設定します。 この設定により、thin archive が生成されます。これは、オブジェクト ファイルを含まず、通常は含まれる実際のオブジェクトへのファイルパスだけを含むライブラリ ファイルです。

これはビルド出力のサイズを抑える際に有効です。 この欠点は、こうしたライブラリを別の場所に移動できないということです(ライブラリ内のすべてのパスは相対パスです)。

有効な値は、truefalse、または空値です。 既定値は Application.mk ファイルの APP_THIN_ARCHIVE 変数で指定できます。

LOCAL_FILTER_ASM

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

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

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

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

LOCAL_PATH := $(call my-dir)

GNU Make の動作により、このマクロから実際に返されるのは、ビルド スクリプトの解析時にビルドシステムにインクルードされた最終的なメイクファイルのパスになります。 このため、別のファイルをインクルードしてから my-dir を呼び出さないようにしてください。

たとえば、次の例を考えてみましょう。

LOCAL_PATH := $(call my-dir)

# ... declare one module

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

LOCAL_PATH := $(call my-dir)

# ... declare another module

ここでの問題は、my-dir の 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

現在のメイクファイルのパス(ビルドシステムがこの関数を呼び出した場所を起点にしたもの)を返します。

parent-makefile

インクルード ツリー内の呼び出し元のメイクファイルのパス(現在のメイクファイルを含むメイクファイルのパス)を返します。

grand-parent-makefile

インクルード ツリー内の呼び出し元の呼び出し元のメイクファイルのパス(現在のメイクファイルを含むメイクファイルのパス)を返します。

import-module

モジュールの Android.mk ファイルをモジュール名で検索してインクルードできる機能です。 代表的な例を次に示します。

$(call import-module,<name>)

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