(6) application. mk File

--------------

For English documents, see documentation.html of android-ndk-r5b.

Part of Android Native Development Kit (ndk)

See http://developer.android.com/sdk/ndk/ (Agent required)

Translation is personal opinion only

-----------------

Application. mk File Syntax Specification

 

Application. mk File Syntax Specification

 

Introduction:

 

Introduction:

-------------

 

This document describes the syntax of application. MK 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 usage.

 

This document describes the syntax of the application. mk build file, which is used to describe your android application.ProgramRequired native module. To understand the following, assume that you have read the docs/overview.html file, which explains the roles and usage of these files.

 

Readers of this document shoshould have read docs/overview.html and docs/ANDROID-MK.html

 

Readers of this document should have read docs/overview.html and docs/ANDROID-MK.html

 

Overview:

 

Overview:

---------

 

The purpose of application. mk is to describe which native 'modules' (I. e. Static/Shared libraries) are needed by your application.

 

The purpose of application. mk is to describe which native "MODULE" (static or dynamic library) is required by your application.

 

An application. mk file is usually placed under $ Project/JNI/application. mk, where $ project points to your application's project directory.

 

An application. mk file is usually stored in $ Project/JNI/application. mk. Here $ project points to the project directory of your application.

 

Another alternative is to place it under a sub-directory of the top-level $ ndk/apps directory, e.g .:

 

Another option is to place it in the subdirectory of the top-level $ ndk/apps directory, for example:

 

$ Ndk/apps/<MyApp>/application. mk

 

Where <MyApp> 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 ).

 

<MyApp> is a short name used to describe your "application" to the ndk build system (this name will not be included in your dynamic library or your final package ).

 

The application. mk is really a tiny GNU makefile fragment that must define a few variables:

 

Application. mk is actually a small GNU makefile segment, which must define such variables:

 

App_project_path

This variable shoshould 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.

 

App_project_path

This variable should be given an absolute path to the root directory of your application project. The dynamic JNI library used to copy/install the cropping version to a specific location known by the APK generation tool.

 

Note that it is optional for $ Project/JNI/application. mk, but * Mandatory * for $ ndk/apps/<MyApp>/application. mk

 

Note that this variable is optional for $ Project/JNI/application. mk, but mandatory for $ ndk/apps/<MyApp>/application. mk.

 

App_modules

This variable is optional. If not defined, the ndk will build by default _ all _ the modules declared by your android. mk, and any sub-makefile it may include.

 

App_modules

This variable is optional. If you do not define it, ndk builds your android. mk by default and all modules declared in all sub-makefiles that it may contain.

 

If app_modules is defined, it must be a space-separated list of module names as they appear in the local_module definitions of Android. mk files. Note that the ndk will compute module dependencies automatically.

 

If app_modules is defined, it must be a list of module names separated by spaces, as they appear in the local_module variable in the Android. mk file. Note that the ndk automatically calculates the module dependency.

 

Note: This variable's behaviour changed in ndk R4. before that:

 

Note: The behavior of this variable changes in ndk R4. Before that:

 

-The variable was mandatory in your application. mk

 

-This variable is mandatory in your application. mk.

 

-All required modules had to be listed explicitly.

 

-All required modules must be listed explicitly.

 

App_optim

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.

 

App_optim

This optional variable can be defined as release or debug, which is used to change the optimization level when building your application module.

 

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.

 

The default mode is release, which generates a highly optimized binary. The debug mode generates non-optimized binary files, which are easier to debug.

 

Note that if your application is debuggable (I. e. if your manifest sets the Android: debuggable attribute to "true" in its <Application> tag), the default will be 'debug' instead of 'release '. this can be overridden by setting app_optim to 'release '.

 

Note that if your application is debuggable (that is, if your configuration file sets the Android: debuggable attribute to true in its <Application> tag ), the default value is debug rather than release. Set app_optim to release to overwrite it.

 

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...

 

Note that you can debug the binary values of release and debug, but the build of release tends to provide less information in the debugging session: some variables are optimized and cannot be detected,CodeRe-sorting may make code step-by-step difficult, stack tracking may be unreliable, and so on.

 

App_cflags

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 android. MK file itself.

 

App_cflags

A set of C compiler switches that compile arbitrary C or C ++ modules.Source code. It can be used to change the construction of a module that a given application needs to depend on, rather than modifying its own Android. mk file.

 

Important warning: ++ ++

 

Important warning:

 

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

 

All the paths of these switches should be relative to the top-level ndk directory. For example, if you have the following configurations:

 

Sources/Foo/Android. mk

Sources/BAR/Android. mk

 

To specify in Foo/Android. mk that you want to add the path to the 'bar' sources during compilation, you shoshould use:

 

To indicate in Foo/Android. mk that you want to add the path (Note: The file search path here should be directed) to the bar source code during the build, you should use

 

App_cflags + =-isources/Bar

 

Or alternatively:

 

Or choose this:

 

App_cflags + =-I $ (local_path)/../Bar

 

Using '-I ../bar' will * not * work since it will be equivalent to '-I $ ndk_root/../bar' instead.

 

Using-I ../bar won't work, because it will be equivalent to-I $ ndk_root/../bar.

 

++ ++

 

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.

 

Note: In the android-ndk-1.5_r1, it applies only to the C source file, not the C ++ source file. It has been corrected to match the full Android build system.

 

App_cxxflags

An alias for app_cppflags, to be considered obsolete as it may disappear in a future release of the ndk.

 

App_cxxflags

The alias of app_cppflags will be considered obsolete because it may disappear in future ndk releases.

 

App_cppflags

A set of C ++ compiler flags passed when building C ++ sources * only *.

 

App_cppflags

A set of C ++ compiler switches that are passed only when the C ++ source code is built.

 

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.

 

Note: In the android-ndk-1.5_r1, it applies to C and C ++ source code. It is corrected to match the full Android build system. Now you can use app_cflags to set the switch that applies to C and C ++ source code.

 

App_build_script

By default, the ndk build system will look for a file named Android. mk under $ (app_project_path)/JNI, I. e. For the file:

 

App_build_script

By default, the ndk build system searches for a file named Android. mk under $ (app_project_path)/JNI. That is, for this file

 

$ (App_project_path)/JNI/Android. mk

 

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.

 

If you want to reload this behavior, you can define app_build_script to point to a different build script. A non-absolute path will always be parsed as a path relative to the ndk top-level directory.

 

App_abi

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 Abi.

 

App_abi

By default, the ndk build system generates machine code using armeabi Abi. It corresponds to a armv5te-based CPU with Floating Point Software. You can use app_abi to select a different Abi

 

For example, to support hardware FPU instructions on armv7 based devices, use:

 

For example, to support software floating point unit commands of armv7-based devices, use:

 

App_abi: = armeabi-v7a

 

Or to support both armv5te and armv7 based devices, use:

 

Or to support devices based on armv5te and armv7, 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

 

For a list of all supported abi and details about their usage and limits, read the docs/CPU-ARCH-ABIS.html.

 

App_stl

By default, the ndk build system provides C ++ headers for the minimal C ++ Runtime Library (/system/lib/libstdc ++. So) provided by the Android system.

 

App_stl

By default, the ndk build system provides the C ++ header file of the minimum C ++ Runtime Library (/system/lib/libstdc ++. So) provided by the Android system.

 

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:

 

However, ndk comes with another c ++ implementation. You can use or link it in your own application. Define app_stl to select one of them. Example:

 

App_stl: = stlport_static --> static stlport Library

 

App_stl: = stlport_static --> static stlport Library

 

App_stl: = stlport_shared --> shared stlport Library

 

App_stl: = stlport_shared --> dynamic stlport Library

 

App_stl: = System --> default C ++ Runtime Library

 

App_stl: = System --> default C ++ Runtime Library

 

For more information on the subject, please read docs/CPLUSPLUS-SUPPORT.html

 

For more information about this topic, see Docs/CPLUSPLUS-SUPPORT.html

 

A trivial application. mk file wocould be:

 

A small application. mk file will be:

 

-------------- Cut here -------------------------

App_project_path: = <path to project>

-------------- Cut here -------------------------