要想真正开始使用安卓NDK首先要学会Android.mk脚本的编写，It is really a tiny GNUmakefile fragment that the build system parses once or more. The Android.mk file is useful for defining project-wide settings that Application.mk, the build system, and yourenvironment variables leave undefined. It can also override project-wide settings for specificmodules.使用此脚本才能将c和c++代码进行黏着。The syntax of the Android.mk allows you to group your sources intomodules. A module is either a static library, a shared library, or a stand alone executable. You can define one or more modules in each Android.mk file, and you can use the same source file in multiple modules. The build system only places shared librariesinto your application package. In addition, static libraries can generate shared libraries.
Android .mk语法：
An Android.mk file must begin by defining the LOCAL_PATH variable:
LOCAL_PATH := $(call my-dir)
This variable indicates the location of the source files in the development tree. Here, the macrofunction my-dir, provided by the build system, returns the path of the current directory(the directory containing the Android.mk file itself).
The next line declares the CLEAR_VARS variable, whose value the build system provides.
include $(CLEAR_VARS)
The CLEAR_VARS variable points to a special GNU Makefile that clears manyLOCAL_XXX variables for you, such as LOCAL_MODULE, LOCAL_SRC_FILES, andLOCAL_STATIC_LIBRARIES. Note that it does not clear LOCAL_PATH. This variable mustretain its value because the system parses all build control files in a single GNU Make executioncontext where all variables are global. You must (re-)declare this variable before describing eachmodule.
Next, the LOCAL_MODULE variable stores the name of the module that you wish to build.Use this variable once per module in your application.
LOCAL_MODULE := hello-jni
Each module name must be unique and not contain any spaces. The build system, when itgenerates the final shared-library file, automatically adds the proper prefix and suffix tothe name that you assign to LOCAL_MODULE. For example, the example that appears aboveresults in generation of a library called libhello-jni.so.
Note: If your module's name already starts with lib, thebuild system does not prepend an additional lib prefix; it takes the module name as-is, andadds the .so extension. So a source file originally called, for example, libfoo.cstill produces a shared-object file called libfoo.so. This behavior is to support librariesthat the Android platform sources generate from Android.mk files; the names of all suchlibraries start with lib.
The next line enumerates the source files, with spaces delimiting multiple files:
LOCAL_SRC_FILES := hello-jni.c
The LOCAL_SRC_FILES variable must contain a list of C and/or C++ source files to buildinto a module.
The last line helps the system tie everything together:
include $(BUILD_SHARED_LIBRARY)
The BUILD_SHARED_LIBRARY variable points to a GNU Makefile script that collects all theinformation you defined in LOCAL_XXX variables since the most recent include. Thisscript determines what to build, and how to do it.
There are more complex examples in the samples directories, with commentedAndroid.mk files that you can look at. In addition,Sample: native-activity providesa detailed explanation of that sample's Android.mk file. Finally, Variables and Macros provides further information on the variables from this section.