blob: ed73716f03ba5483c0e3cc818af6c698f8894734 [file] [log] [blame]
<html><body><pre> file syntax specification
This document describes the syntax of build files
written to describe the native modules required by your Android
application. To understand what follows, it is assumed that you have
read the docs/OVERVIEW.html file that explains their role and
Readers of this document should have read docs/OVERVIEW.html and
The purpose of is to describe which native
'modules' (i.e. static/shared libraries) are needed by your
An file is usually placed 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, e.g.:
Where &lt;myapp&gt; is a short name used to describe your 'application'
to the NDK build system (this name doesn't go into your generated
shared libraries or your final packages).
The is really a tiny GNU Makefile fragment that must
define a few variables:
This variable should give the *absolute* path to your
Application's project root directory. This is used to copy/install
stripped versions of the generated JNI shared libraries to a
specific location known to the APK-generating tools.
Note that it is optional for $PROJECT/jni/, but
*mandatory* for $NDK/apps/&lt;myapp&gt;/
This variable is optional. If not defined, the NDK will build by
default _all_ the modules declared by your, and any
sub-makefile it may include.
If APP_MODULES is defined, it must be a space-separated list of module
names as they appear in the LOCAL_MODULE definitions of
files. Note that the NDK will compute module dependencies automatically.
NOTE: This variable's behaviour changed in NDK r4. Before that:
- the variable was mandatory in your
- all required modules had to be listed explicitly.
This optional variable can be defined to either 'release' or
'debug'. This is used to alter the optimization level when
building your application's modules.
A 'release' mode is the default, and will generate highly
optimized binaries. The 'debug' mode will generate un-optimized
binaries which are much easier to debug.
Note that if your application is debuggable (i.e. if your manifest
sets the android:debuggable attribute to "true" in its &lt;application&gt;
tag), the default will be 'debug' instead of 'release'. This can
be overridden by setting APP_OPTIM to 'release'.
Note that it is possible to debug both 'release' and 'debug'
binaries, but the 'release' builds tend to provide less information
during debugging sessions: some variables are optimized out and
can't be inspected, code re-ordering can make stepping through
the code difficult, stack traces may not be reliable, etc...
A set of C compiler flags passed when compiling any C or C++ source code
of any of the modules. This can be used to change the build of a given
module depending on the application that needs it, instead of modifying
the file itself.
IMPORTANT WARNING: +++++++++++++++++++++++++++++++++++++++++++++++++++
+ All paths in these flags should be relative to the top-level NDK
+ directory. For example, if you have the following setup:
+ sources/foo/
+ sources/bar/
+ 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:
+ APP_CFLAGS += -I$(LOCAL_PATH)/../bar
+ Using '-I../bar' will *NOT* work since it will be equivalent to
+ '-I$NDK_ROOT/../bar' instead.
NOTE: In android-ndk-1.5_r1, this only applied to C sources, not C++ ones.
This has been corrected to match the full Android build system.
An alias for APP_CPPFLAGS, to be considered obsolete as it may disappear
in a future release of the NDK.
A set of C++ compiler flags passed when building C++ sources *only*.
NOTE: In android-ndk-1.5_r1, this applied to both C and C++ sources.
This has been corrected to match the full Android build system.
You can now use APP_CFLAGS for flags that shall apply to C and
C++ sources.
By default, the NDK build system will look for a file named
under $(APP_PROJECT_PATH)/jni, i.e. for the file:
If you want to override this behaviour, you can define APP_BUILD_SCRIPT
to point to an alternate build script. A non-absolute path will always
be interpreted as relative to the NDK's top-level directory.
By default, the NDK build system will generate machine code for the
'armeabi' ABI. This corresponds to an ARMv5TE based CPU with software
floating point operations. You can use APP_ABI to select a different
For example, to support hardware FPU instructions on ARMv7 based devices,
APP_ABI := armeabi-v7a
Or to support both ARMv5TE and ARMv7 based devices, use:
APP_ABI := armeabi armeabi-v7a
For the list of all supported ABIs and details about their usage and
limitations, please read docs/CPU-ARCH-ABIS.html
By default, the NDK build system provides C++ headers for the minimal
C++ runtime library (/system/lib/ provided by the Android
However, the NDK comes with alternative C++ implementations that you can
use or link to in your own applications. Define APP_STL to select one of
them. Examples are:
APP_STL := stlport_static --> static STLport library
APP_STL := stlport_shared --> shared STLport library
APP_STL := system --> default C++ runtime library
For more information on the subject, please read docs/CPLUSPLUS-SUPPORT.html
A trivial file would be:
-------------- cut here -------------------------
APP_PROJECT_PATH := &lt;path to project&gt;
-------------- cut here -------------------------