Skip to content

Most visited

Recently visited


On this page

  1. Overview
  2. Variables

This document explains the build file, which describes the native modules that your app requires. A module can be a static library, a shared library, or an executable.

We recommend that you read the Concepts and pages before this one. Doing so will help maximize your understanding of the material on this page.


The file is really a tiny GNU Makefile fragment that defines several variables for compilation. It usually resides under $PROJECT/jni/, where $PROJECT points to your application's project directory. Another alternative is to place it under a sub-directory of the top-level $NDK/apps/ directory. For example:


Here, <myapp> is a short name used to describe your app to the NDK build system. It doesn't actually go into your generated shared libraries or your final packages.



This variable stores the absolute path to your app's project-root directory. The build system uses this information to place stripped-down versions of the generated JNI shared libraries into a specific location known to the APK-generating tools.

If you place your file under $NDK/apps/<myapp>/, you must define this variable. If you place it under $PROJECT/jni/, it is optional.


Define this optional variable as either release or debug. You use it to alter the optimization level when building your application's modules.

Release mode is the default, and generates highly optimized binaries. Debug mode generates unoptimized binaries that are much easier to debug.

Note that you can debug either release or debug binaries. Release binaries, however, provide less information during debugging. For example, the build system optimizes out some variables, preventing you from inspecting them. Also, code re-ordering can make it more difficult to step through the code; stack traces may not be reliable.

Declaring android:debuggable in your application manifest's <application> tag will cause this variable to default to debug instead of release. Override this default value by setting APP_OPTIM to release.


This variable stores a set of C compiler flags that the build system passes to the compiler when compiling any C or C++ source code for any of the modules. You can use this variable to change the build of a given module according to the application that needs it, instead of having to modify the file itself.

All paths in these flags should be relative to the top-level NDK directory. For example, if you have the following setup:


To specify in foo/ that you want to add the path to the bar sources during compilation, you should use:

APP_CFLAGS += -Isources/bar

Or, alternatively:


-I../bar will not work since it is equivalent to -I$NDK_ROOT/../bar.

Note: This variable only works on C, not C++, sources in android-ndk-1.5_r1. In all versions after that one, APP_CFLAGS matches the full Android build system.


This variable contains a set of C++ compiler flags that the build system passes to the compiler when building only C++ sources.

Note: In android-ndk-1.5_r1, this variable works on both C and C++ sources. In all subsequent versions of the NDK, APP_CPPFLAGS now matches the full Android build system. For flags that apply to both C and C++ sources, use APP_CFLAGS.


A set of linker flags that the build system passes when linking the application. This variable is only relevant when the build system is building shared libraries and executables. When the build system builds static libraries, it ignores these flags.


By default, the NDK build system looks under jni/ for a file named

If you want to override this behavior, you can define APP_BUILD_SCRIPT to point to an alternate build script. The build system always interprets a non-absolute path as relative to the NDK's top-level directory.


By default, the NDK build system generates machine code for the armeabi ABI. This machine code corresponds to an ARMv5TE-based CPU with software floating point operations. You can use APP_ABI to select a different ABI. Table 1 shows the APP_ABI settings for different instruction sets.

Table 1. APP_ABI settings for different instruction sets.

Instruction set Value
Hardware FPU instructions on ARMv7 based devices APP_ABI := armeabi-v7a
ARMv8 AArch64 APP_ABI := arm64-v8a
IA-32 APP_ABI := x86
Intel64 APP_ABI := x86_64
MIPS32 APP_ABI := mips
MIPS64 (r6) APP_ABI := mips64
All supported instruction sets APP_ABI := all

Note: all is available starting from NDKr7.

You can also specify multiple values by placing them on the same line, delimited by spaces. For example:

APP_ABI := armeabi armeabi-v7a x86 mips

For the list of all supported ABIs and details about their usage and limitations, refer to ABI Management.


This variable contains the name of the target Android platform. For example, android-3 specifies the Android 1.5 system images. For a complete list of platform names and corresponding Android system images, see Android NDK Native APIs .


By default, the NDK build system provides C++ headers for the minimal C++ runtime library (system/lib/ provided by the Android system. In addition, it comes with alternative C++ implementations that you can use or link to in your own applications. Use APP_STL to select one of them. For information about the supported runtimes, and the features they offer, see NDK Runtimes and Features.


The equivalent of LOCAL_SHORT_COMMANDS in for your whole project. For more information, see the documentation for this variable on


Define this variable as 4.9 to select that version of the GCC compiler. Define this variable as clang to select the Clang compiler, which is the default value for NDK r13 and later.


Starting from Android 4.1 (API level 16), Android's dynamic linker supports position-independent executables (PIE). From Android 5.0 (API level 21), executables require PIE. To use PIE to build your executables, set the -fPIE flag. This flag makes it harder to exploit memory corruption bugs by randomizing code location. By default, ndk-build automatically sets this value to true if your project targets android-16 or higher. You may set it manually to either true or false.

This flag applies only to executables. It has no effect when building shared or static libraries.

Note: PIE executables cannot run on Android releases prior to 4.1.

This restriction only applies to executables. It has no effect when building shared or static libraries.


Sets the default value of LOCAL_THIN_ARCHIVE in the file for all static library modules in this project. For more information, see the documentation for LOCAL_THIN_ARCHIVE on

This site uses cookies to store your preferences for site-specific language and display options.


This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.