This document explains the `Application.mk` build file used by `ndk-build`.

We recommend that you read the [Concepts](https://developer.android.com/ndk/guides/concepts) page before this
one.

## Overview

The `Application.mk` specifies project-wide settings for ndk-build. By default,
it is located at `jni/Application.mk`, in your application's project directory.
| **Note:** Many of these parameters also have a per-module equivalent. For example, `APP_CFLAGS` corresponds to `LOCAL_CFLAGS`. In every case, the module-specific option will take precedence over the application-wide option. For flags, both are used but the module-specific flags will appear later in the command line so they may override project-wide settings.

## Variables

### APP_ABI

By default, the NDK build system generates code for all non-deprecated ABIs. You
can use the `APP_ABI` setting to generate code for specific ABIs. Table 1 shows
the `APP_ABI` settings for different instruction sets.


**Table 1.** `APP_ABI` settings for different instruction sets.

| Instruction set | Value |
|---|---|
| 32-bit ARMv7 | `APP_ABI := armeabi-v7a` |
| 64-bit ARMv8 (AArch64) | `APP_ABI := arm64-v8a` |
| x86 | `APP_ABI := x86` |
| x86-64 | `APP_ABI := x86_64` |
| All supported ABIs (default) | `APP_ABI := all` |

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

    APP_ABI := armeabi-v7a arm64-v8a x86

| **Note:** `APP_ABI` is ignored by Gradle's `externalNativeBuild`. Instead, use an `abiFilters` block or (if you are using "Multiple APKs") an `abi` block inside a `splits` block.

For the list of all supported ABIs and details about their usage and
limitations, refer to [Android ABIs](https://developer.android.com/ndk/guides/abis).

### APP_ASFLAGS

Flags to be passed to the assembler for every assembly source file (`.s` and
`.S` files) in the project.
| **Note:** `ASFLAGS` are distinct from `ASMFLAGS`. The latter applies specifically to YASM source files (see the section on [APP_ASMFLAGS](https://developer.android.com/ndk/guides/application_mk#app_asmflags)).

### APP_ASMFLAGS

Flags to be passed to YASM when for all YASM source files (`.asm`, x86/x86_64
only).

### APP_BUILD_SCRIPT

By default, ndk-build assumes that the [Android.mk](https://developer.android.com/ndk/guides/android_mk) file is located at
`jni/Android.mk` relative to the project root.

To load an [Android.mk](https://developer.android.com/ndk/guides/android_mk) file from a different location, set `APP_BUILD_SCRIPT`
to the absolute path of the Android.mk file.
| **Note:** Gradle's `externalNativeBuild` will configure this automatically based on the `externalNativeBuild.ndkBuild.path` variable.

### APP_CFLAGS

Flags to be passed for all C/C++ compiles in the project.
| **Note:** Include paths should use `LOCAL_C_INCLUDES` rather than explicit `-I` flags.

See also: [APP_CONLYFLAGS](https://developer.android.com/ndk/guides/application_mk#app_conlyflags), [APP_CPPFLAGS](https://developer.android.com/ndk/guides/application_mk#app_cppflags).

### APP_CLANG_TIDY

Set to true to enable clang-tidy for all modules in the project. Disabled by
default.

### APP_CLANG_TIDY_FLAGS

Flags to pass for all clang-tidy executions in the project.

### APP_CONLYFLAGS

Flags to be passed for all C compiles in the project. These flags will not be
used for C++ code.

See also: [APP_CFLAGS](https://developer.android.com/ndk/guides/application_mk#app_cflags), [APP_CPPFLAGS](https://developer.android.com/ndk/guides/application_mk#app_cppflags).

### APP_CPPFLAGS

Flags to be passed for all C++ compiles in the project. These flags will not be
used for C code.

See also: [APP_CFLAGS](https://developer.android.com/ndk/guides/application_mk#app_cflags), [APP_CONLYFLAGS](https://developer.android.com/ndk/guides/application_mk#app_conlyflags).

### APP_CXXFLAGS

| **Note:** [APP_CPPFLAGS](https://developer.android.com/ndk/guides/application_mk#app_cppflags) should be preferred to `APP_CXXFLAGS`.

Identical to `APP_CPPFLAGS`, but will appear after `APP_CPPFLAGS` in the compile
command. For example:  

    APP_CPPFLAGS := -DFOO
    APP_CXXFLAGS := -DBAR

The above configuration will result in a compilation command similar to `clang++
-DFOO -DBAR` rather than `clang++ -DBAR -DFOO`.

### APP_DEBUG

Set to true to build a debuggable application.

### APP_LDFLAGS

Flags to be passed when linking executables and shared libraries.
| **Note:** These flags have no effect on static libraries. Static libraries are not linked.

### APP_MANIFEST

Absolute path to an AndroidManifest.xml file.

By default, `$(APP_PROJECT_PATH)/AndroidManifest.xml)` will be used if it
exists.
| **Note:** When using `externalNativeBuild` this value will not be set by Gradle.

### APP_MODULES

An explicit list of modules to build. The elements of this list are the names of
the modules as they appear in `LOCAL_MODULE` within the [Android.mk](https://developer.android.com/ndk/guides/android_mk) file.

By default, ndk-build will build all shared libraries, executables, and their
dependencies. Static libraries will be built only if they are used by the
project, the project contains *only* static libraries, or if they are named in
`APP_MODULES`.
| **Note:** Imported modules (those defined in build scripts imported with `$(call
| import-module)` will not be built unless depended on by a module to be built or listed in `APP_MODULES`.

### APP_OPTIM

Define this optional variable as either `release` or `debug`. Release binaries
will be built by default.

Release mode enables optimizations and may produce binaries that are not usable
with a debugger. Debug mode disables optimizations so that debuggers may be
used.

Note that you can debug either release or debug binaries. Release binaries,
however, provide less information during debugging. For example, variables may
be optimized out, preventing inspection. 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`.
| **Note:** When building with `externalNativeBuild`, Android Studio will set this flag appropriately based on your build flavor.

### APP_PLATFORM

`APP_PLATFORM` declares the Android API level this application is built against
and corresponds to the application's `minSdkVersion`.

If not specified, ndk-build will target the minimum API level supported by the
NDK. The minimum API level supported by the latest NDK will always be low enough
to support nearly all active devices.
| **Warning:** Setting `APP_PLATFORM` higher than an application's `minSdkVersion` will likely produce an application that will not run on older devices. In most cases the libraries will fail to load because they refer to symbols that are not available on older devices.

For example, a value of `android-16` specifies that your library uses APIs that
are not available below Android 4.1 (API level 16) and can't be used on devices
running a lower platform version. For a complete list of platform names and
corresponding Android system images, see [Android NDK native
APIs](https://developer.android.com/ndk/guides/stable_apis).

When using Gradle and `externalNativeBuild`, this parameter should not be set
directly. Instead, set the `minSdkVersion` property in the `defaultConfig` or
`productFlavors` blocks of your
[module-level](https://developer.android.com/studio/build#module-level) `build.gradle` file. This
makes sure your library is used only by apps installed on devices running an
adequate version of Android.

Note that the NDK does not contain libraries for every API level of Android.
Versions that did not include new native APIs are omitted to save space in the
NDK. ndk-build uses, in descending order of preference:

1. The platform version matching `APP_PLATFORM`.
2. The next available API level below `APP_PLATFORM`. For example, `android-19` will be used when `APP_PLATFORM` is `android-20`, since there were no new native APIs in android-20.
3. The minimum API level supported by the NDK.

### APP_PROJECT_PATH

The absolute path of the project's root directory.

### APP_SHORT_COMMANDS

The project-wide equivalent of `LOCAL_SHORT_COMMANDS`. For more information, see
the documentation for `LOCAL_SHORT_COMMANDS` in [Android.mk](https://developer.android.com/ndk/guides/android_mk).

### APP_STL

The C++ standard library to use for this application.

The `system` STL is used by default. Other choices are `c++_shared`,
`c++_static`, and `none`. See [NDK C++ Runtimes and
Features](https://developer.android.com/ndk/guides/cpp-support#c_runtime_libraries).

### APP_STRIP_MODE

The argument to be passed to `strip` for modules in this application. Defaults
to `--strip-unneeded`. To avoid stripping all binaries in the module, set to
`none`. For other strip modes, see the [strip
documentation](https://sourceware.org/binutils/docs/binutils/strip.html).

### APP_THIN_ARCHIVE

Set to true to use thin archives for all static libraries in the project. For
more information, see the documentation for `LOCAL_THIN_ARCHIVE` in
[Android.mk](https://developer.android.com/ndk/guides/android_mk).

### APP_WRAP_SH

Path to the [wrap.sh](https://developer.android.com/ndk/guides/wrap-script) file to be included with this application.

A variant of this variable exists for each ABI, as does an ABI-generic variant:

- `APP_WRAP_SH`
- `APP_WRAP_SH_armeabi-v7a`
- `APP_WRAP_SH_arm64-v8a`
- `APP_WRAP_SH_x86`
- `APP_WRAP_SH_x86_64`

| **Note:** `APP_WRAP_SH_<abi>` may not be combined with `APP_WRAP_SH`. If any ABI uses an ABI-specific wrap.sh, all ABIs must.