在login windows里允许root登陆
命令行输入 sudo passwd root进行修改
sudo apt-get install swig 在线安装swig
-----------------
英文文档见android-ndk-r5b的documentation.html
属于Android Native Development Kit (NDK)的一部分
见http://developer.android.com/sdk/ndk/（需要代理）
翻译仅个人见解
-----------------
NDK Prebuilt library support:
NDK 预构建库支持：
-----------------------------
Android NDK r5 introduced support for prebuilt libraries (shared and static), i.e. the ability to include and use, in your applications, prebuilt version of libraries.
Android NDK r5引入预构建库（动态和静态）的支持，即在你的应用程序中包含和使用库的预构建版本。
This feature can be useful for two things:
这个特性可能在两方面有用：
1/ You want to distribute your own libraries to third-party NDK developers without distributing your sources.
1、你想发布你自己的库给第三方NDK开发者而不分发你的源代码。
2/ You want to use a prebuilt version of your own libraries to speed up your build.
2、你想使用你自己的库的预构建版本以加速你的构建。
This document explains how this support works.
这个文档解释这种支持是如何工作的。
I. Declaring a prebuilt library module:
一、声明一个预构建库模块：
---------------------------------------
Each prebuilt library must be declared as a *single* independent module to the build system. Here is a trivial example where we assume that the file "libfoo.so" is located in the same directory than the Android.mk below:
每个预构建库必须向构建系统声明为一个单一独立模块。这里有个小示例，我们假设文件libfoo.so位于以下Android.mk相同的目录中。
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := libfoo.so
include $(PREBUILT_SHARED_LIBRARY)
Notice that, to declare such a module, you really only need the following:
注意，要声明这个模块，你实际上只需要以下东西：
1. Give the module a name (here 'foo-prebuilt'). This does not need to correspond to the name of the prebuilt library itself.
1. 给模块一个名称（这里是foo-prebuilt）。不需要对应预构建库本身的名称。
2. Assign to LOCAL_SRC_FILES the path to the prebuilt library you are providing. As usual, the path is relative to your LOCAL_PATH.
2. 把你提供的预构建库的路径赋给LOCAL_SRC_FILES。通常路径相对于你的LOCAL_PATH
IMPORTANT: You *must* ensure that the prebuilt library corresponds to the target ABI you are using. More on this later.
重要：你必须确保预构建库对应你正在使用的目标ABI（注：应用程序二进制接口，即操作系统开放给应用程序的接口）。更多相关信息见后。
3. Include PREBUILT_SHARED_LIBRARY, instead of BUILD_SHARED_LIBRARY, if you are providing a shared, library. For static ones, use PREBUILT_STATIC_LIBRARY.
3. 包含PREBUILT_SHARED_LIBRARY，而非BUILD_SHARED_LIBRARY，如果你提供的是一个动态库。对于静态库，请使用PREBUILT_STATIC_LIBRARY
A prebuilt module does not build anything. However, a copy of your prebuilt shared library will be copied into $PROJECT/obj/local, and another will be copied and stripped into $PROJECT/libs/<abi>.
一个预构建模块不编译任何东西。然而，你的预构建动态库的副本将被复制到$PROJECT/obj/local，而另一个副本将被复制并裁剪进$PROJECT/libs/<abi>。
II. Referencing the prebuilt library in other modules:
二、引用其它模块的预构建库：
------------------------------------------------------
Simply list your prebuilt module's name in the LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES declaration in the Android.mk of any module that depends on them.
在依赖于你的构建模块的所有模块的Android.mk的LOCAL_STATIC_LIBRARIES或LOCAL_SHARED_LIBRARIES的声明中简单列出这些预构建模块的名称。
For example, a naive example of a module using libfoo.so would be:
例如，一个使用libfoo.so的模块的单纯例子将是：
include $(CLEAR_VARS)
LOCAL_MODULE := foo-user
LOCAL_SRC_FILES := foo-user.c
LOCAL_SHARED_LIBRARY := foo-prebuilt
include $(BUILD_SHARED_LIBRARY)
III. Exporting headers for prebuilt libraries:
三、导出预构建库的头文件：
----------------------------------------------
The example above was called 'naive' because, in practice, the code in foo-user.c is going to depend on specific declarations that are normally found in a header file distributed with the prebuilt library (e.g. "foo.h").
上面的例子被称为“单纯”是因为，实际上，foo-user.c的代码将依赖于特定的声明，那些声明通常在预构建库分发的头文件中找到（例如，foo.h）
In other words, foo-user.c is going to have a line like:
换句话说，foo-user.c将有类似的一行：
#include <foo.h>
And you need to provide the header and its include path to the compiler when building the foo-user module.
而你需要在构建foo-user模块时提供头文件和它的编译器包含目录。
A simple way to deal with that is to use exports in the prebuilt module definition. For example, assuming that a file "foo.h" is located under the 'include' directory relative to the prebuilt module, we can write:
一个简单处理方法是在预构建模块定义中使用导出。例如，假设一个foo.h文件位于相对于预构建模块的include目录下，我们可以这样写：
include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := libfoo.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
The LOCAL_EXPORT_C_INCLUDES definition here ensures that any module that depends on the prebuilt one will have its LOCAL_C_INCLUDES automatically prepended with the path to the prebuilt's include directory, and will thus be able to find headers inside that.
这里LOCAL_EXPORT_C_INCLUDES的定义确保任何依赖于预构建模块的模块将自动拥有带预构建库包含目录为前置值的LOCAL_C_INCLUDES，而它将能够找到包含其中的头文件。
IV. Debugging prebuilt binaries:
四、调试预构建二进制文件：
--------------------------------
We recommend you to provide prebuilt shared libraries that contain debug symbols. The version that is installed into $PROJECT/libs/<abi>/ is always stripped by the NDK build system, but the debug version will be used for debugging purposes with ndk-gdb.
我们建议你提供包含调试符号的预构建共享库。安装进$PROJECT/libs/<abi>/的版本常常是被NDK构建系统裁剪过（注：ndk提供的工具链中包含了strip工具，它应该是用来优化生成文件的大小），但调试版本将可以供ndk-gdb使用以达到调试目的。
V. ABI Selection of prebuilt binaries:
五、预构建二进制文件的ABI选择：
--------------------------------------
As said previously, it is crucial to provide a prebuilt shared library that is compatible with the targetted ABI during the build. To do that, check for the value of TARGET_ARCH_ABI, its value will be:
正如前面所说，关键问题是在构建期间提供一个兼容于目标ABI的预构建动态库（注：开源是好事啊）。为了做到那点，检查TARGET_ARCH_ABI的值，它的值将是：
armeabi => when targetting ARMv5TE or higher CPUs
armeabi => 目标为ARMv5TE或更高的CPU
armeabi-v7a => when targetting ARMv7 or higher CPUs
armeabi-v7a => 目标为ARMv7或更高的CPU
x86 => when targetting x86 CPUs
x86 => 目标为x86 CPU。
Note that armeabi-v7a systems can run armeabi binaries just fine.
注意armeabi-v7a系统可以很好地运行armeabi的二进制文件。
Here's an example where we provide two versions of a prebuilt library and select which one to copy based on the target ABI:
这里有一个例子，我们提供两个版本的预构建库并且基于目标ABI选择哪一个版本去复制。
include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := $(TARGET_ARCH_ABI)/libfoo.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
Here. we assume that the prebuilt libraries to copy are under the following directory hierarchy:
这里。我们假设要复制的预构建库位于以下目录层次：
Android.mk --> the file above
Android.mk --> 上面的文件
armeabi/libfoo.so --> the armeabi prebuilt shared library
armeabi/libfoo.so --> armeabi预构建动态库
armeabi-v7a/libfoo.so --> the armeabi-v7a prebuilt shared library
armeabi-v7a/libfoo.so --> armeabi-v7a预构建动态库
include/foo.h --> the exported header file
include/foo.h --> 导出的头文件
NOTE: Remember that you don't need to provide an armeabi-v7a prebuilt library, since an armeabi one can easily run on the corresponding devices.
注意：记住你不需要提供一个armeabi-v7a预构建库，因为armeabi版本可以更容易地运行在相应的设备上。
-----------------
英文文档见android-ndk-r5b的documentation.html
属于Android Native Development Kit (NDK)的一部分
见http://developer.android.com/sdk/ndk/（需要代理）
翻译仅个人见解
-----------------
Application.mk file syntax specification
Application.mk文件语法规范
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.
这个文档描述Application.mk构建文件的语法，书写它的目的是描述你的Android应用程序需要的原生模块。为了理解下面所说的东西，假设你已经读过docs/OVERVIEW.html文件，它解释这些文件的角色和用法。
Readers of this document should have read docs/OVERVIEW.html and docs/ANDROID-MK.html
这个文档的读者应该读过docs/OVERVIEW.html和docs/ANDROID-MK.html
Overview:
概述：
---------
The purpose of Application.mk is to describe which native 'modules' (i.e. static/shared libraries) are needed by your application.
Application.mk的目的是描述哪个原生“模块”（即静态或动态库）是你的应用程序所需要的。
An Application.mk file is usually placed under $PROJECT/jni/Application.mk, where $PROJECT points to your application's project directory.
一个Application.mk文件通常放置在$PROJECT/jni/Application.mk，这里$PROJECT指向你的应用程序的工程目录。
Another alternative is to place it under a sub-directory of the top-level $NDK/apps directory, e.g.:
另一个选择是放在顶级$NDK/apps目录的子目录下，例如：
$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>是一个短名称，用于向NDK构建系统描述你的“应用程序”（这个名称不会被带入你生成的动态库或你的最终程序包）。
The Application.mk is really a tiny GNU Makefile fragment that must define a few variables:
Application.mk其实是一个小型GNU Makefile片段，它必须定义一些这样的变量：
APP_PROJECT_PATH
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.
APP_PROJECT_PATH
这个变量应该给定为你的应用程序工程根目录的绝对路径。用于复制/安装剪裁版的JNI动态生成库到APK生成工具知道的特定位置。
Note that it is optional for $PROJECT/jni/Application.mk, but *mandatory* for $NDK/apps/<myapp>/Application.mk
注意这个变量对于$PROJECT/jni/Application.mk是可选的，但对于$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
这个变量是可选的。如果不定义它，NDK将默认构建你的Android.mk，以及它可能包含的所有子makefile中声明的所有模块。
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.
如果定义了APP_MODULES，它必须是用空格分隔的模块名称列表，正如它们在Android.mk文件中LOCAL_MODULE变量里出现那样。注意NDK将自动计算模块依赖。
NOTE: This variable's behaviour changed in NDK r4. Before that:
注意：这个变量的行为在NDK r4中发生改变。在此之前：
- the variable was mandatory in your Application.mk
- 这个变量在你的Application.mk中是强制的
- all required modules had to 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
这个可选变量可以定义为release或者debug，它在构建你的应用程序模块时用于改变优化级别。
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.
默认是release模式，它将生成高度优化的二进制。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'.
注意如果你的应用程序是可调试的（即，如果你的清单文件在它的<application>标签中把android:debuggable属性设为true），默认将是debug而非release。把APP_OPTIM设置为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...
注意可以调试release和debug版二进制，但release版构建倾向于在调试会话中提供较少信息：一些变量被优化并且不能被检测，代码重新排序可能致使代码步进变得困难，堆栈跟踪可能不可靠，等等。
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
一个C编译器开关集合，在编译任意模块的任意C或C++源代码时传递。它可以用于改变一个给定的应用程序需要依赖的模块的构建，而不是修改它自身的Android.mk文件
IMPORTANT WARNING: +++++++++++++++++++++++++++++++++++++++++++++++++++
重要警告：
All paths in these flags should be relative to the top-level NDK directory. For example, if you have the following setup:
这些开关的所有路径应该是相对于顶级NDK目录。例如，如果你拥有以下配置：
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 should use:
为了在foo/Android.mk中表明你想在构建期间添加路径（注：这里应该指头文件搜索路径）到bar的源代码，你应该使用
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.
使用-I../bar将不能工作，因为它将改为等效于-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.
注意：在android-ndk-1.5_r1里，它仅应用于C源文件，而非C++源文件。它已经被更正为匹配完全Android构建系统。
APP_CXXFLAGS
An alias for APP_CPPFLAGS, to be considered obsolete as it may disappear in a future release of the NDK.
APP_CXXFLAGS
APP_CPPFLAGS的别名，将考虑为过时，因为它可能在未来的NDK发布版中消失。
APP_CPPFLAGS
A set of C++ compiler flags passed when building C++ sources *only*.
APP_CPPFLAGS
一个C++编译器开关集合，仅当构建C++源码时传递。
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.
注意：在android-ndk-1.5_r1中，它应用于C和C++源码。它被更正为匹配完全Android构建系统。你现在可以使用APP_CFLAGS设置应用于C和C++源码的开关。
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
默认，NDK构建系统将在$(APP_PROJECT_PATH)/jni下寻找一个名为Android.mk的文件。即，对于这个文件
$(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.
如果你想重载这个行为，你可以定义APP_BUILD_SCRIPT指向一个不同的构建脚本。一个非绝对路径将总是被解析为相对于NDK顶级目录的路径。
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
默认，NDK构建系统将生成使用armeabi ABI的机器代码。它对应于一个带有软件浮点操作的基于ARMv5TE的CPU。你可以使用APP_ABI选择一个不同的ABI
For example, to support hardware FPU instructions on ARMv7 based devices, use:
例如，为了支持基于ARMv7的设备的软件浮点单元指令，使用：
APP_ABI := armeabi-v7a
Or to support both ARMv5TE and ARMv7 based devices, use:
或者为了支持基于ARMv5TE和ARMv7的设备，使用
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
想获得所有支持的ABI列表和关于它们用法和限制的细节，请阅读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
默认，NDK构建系统提供由Android系统给出的最小C++运行时库（/system/lib/libstdc++.so）的C++头文件。
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:
然而，NDK带有另一个C++实现，你可以在你自己的应用程序中使用或链接它。定义APP_STL以选择它们其中的一个。例子如下：
APP_STL := stlport_static --> static STLport library
APP_STL := stlport_static --> 静态STLport库
APP_STL := stlport_shared --> shared STLport library
APP_STL := stlport_shared --> 动态STLport库
APP_STL := system --> default C++ runtime library
APP_STL := system --> 默认的C++运行时库
For more information on the subject, please read docs/CPLUSPLUS-SUPPORT.html
关于这个主题的详细信息，请阅读docs/CPLUSPLUS-SUPPORT.html
A trivial Application.mk file would be:
一个细小的Application.mk文件将是：
-------------- cut here -------------------------
APP_PROJECT_PATH := <path to project>
-------------- cut here -------------------------