NDK开发之一

2015.07.22

Wiki_Tree:

--NDK开发；

--NDK特征；

--MK文件编写规则；

NDK开发：

Ndk-build编译时会生成的两个同名的so库，位于不同的目录/project path/libs/armeabi/xxx.so和/project path/obj/local/armeabi/xxx.so，比较两个so文件会发现体积相差很大。前者会跟随App一起发布，所以尽可能地小，而后者包含了很多调试信息，主要为了gdb调试的时候使用，当然，NDK的日志符号化信息也包含其中。

C++崩溃的符号化工具ndk-stack、addr2line、objdump

readelf可以查看so文件的结构信息,so是shared object区别于executable\relocatable,统称 EFL。

ELF Header

ELF Header文件头的结构如下，记录了文件其他内容在文件中的偏移以及大小信息。这里以32bit为例：

typedef struct {

unsigned char   e_ident[EI_NIDENT];

Elf32_Half      e_type;          // 目标文件类型，如relocatable、executable和shared object

Elf32_Half      e_machine;   // 指定需要的特定架构，如Intel 80386，Motorola 68000

Elf32_Word      e_version;   // 目标文件版本，通e_ident中的EI_VERSION

Elf32_Addr      e_entry;       // 指定入口点地址，如C可执行文件的入口是_start()，而不是main()

Elf32_Off       e_phoff;   // program header table 的偏移量

Elf32_Off       e_shoff;   // section header table的偏移量

Elf32_Word      e_flags;  // 处理器相关的标志

Elf32_Half      e_ehsize;  // 代表ELF Header部分的大小

Elf32_Half      e_phentsize; // program header table中每一项的大小

Elf32_Half      e_phnum;   // program header table包含多少项

Elf32_Half      e_shentsize;  // section header table中每一项的大小

Elf32_Half      e_shnum;  // section header table包含多少项

Elf32_Half      e_shstrndx;  //section header table中某一子项的index，该子项包含了所有section的字符串名称

} Elf32_Ehdr;

ELF结构：

其中e_ident为固定16个字节大小的数组，称为ELF Identification，包含了处理器类型、文件编码格式、机器类型等，具体结构如下：

ndk(native development kit) 解压：tar -xf ndk-linux-x86.tar

1.添加：export PATH="/target/bin:$PATH"

2.source .bashrc

NDK特征：

1.NDK集成了交叉编译器，并提供了相应的mk文件隔离CPU、平台、ABI等差异，开发人员只需要简单修改mk文件（指出“哪些文件需要编译”、“编译特性要求”等），就可以创建出so。

2.

2.NDK提供了一份稳定、功能有限的API头文件声明

Google明确声明该API是稳定的，在后续所有版本中都稳定支持当前发布的API。从该版本的NDK中看出，这些API支持的功能非常有限，包含有：C标准库（libc）、标准数学库（libm）、压缩库（libz）、Log库（liblog）。

Jni使用:

//声明函数

public native void method();

static{
System.LoadLibrary("what_jni");

}

1.编写java代码；

2.编写c代码,javah生成了h、class文件；编写mk文件，ndk-build生成so文件。

3.联合编译。

MK编写规则

LOCAL_PATH :=
$(call my-dir)

Android.mk
文件首先必须定义好LOCAL_PATH变量。它用于在开发树中查找源文件。在这个例子中，宏函数’my-dir’,
由编译系统提供，用于返回当前路径（即包含Android.mk file文件的目录）。

include $(
CLEAR_VARS)

CLEAR_VARS由编译系统提供，指定让GNU MAKEFILE为你清除许多LOCAL_XXX变量（例如
LOCAL_MODULE, LOCAL_SRC_FILES,
LOCAL_STATIC_LIBRARIES, 等等...),
除LOCAL_PATH 。这是必要的，因为所有的编译控制文件都在同一个GNU MAKE执行环境中，所有的变量都是全局的。

LOCAL_MODULE :=
hello-jni

编译的目标对象，LOCAL_MODULE变量必须定义，以标识你在Android.mk文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。

注意：编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为'hello-jni'的共享库模块，将会生成'libhello-jni.so'文件。

重要注意事项：如果你把库命名为‘libhello-jni’，编译系统将不会添加任何的lib前缀，也会生成
'libhello-jni.so'，这是为了支持来源于Android平台的源代码的Android.mk文件，如果你确实需要这么做的话。

LOCAL_SRC_FILES :=
hello-jni.c

LOCAL_SRC_FILES变量必须包含将要编译打包进模块中的C或C++源代码文件。注意，你不用在这里列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。

注意，默认的C++源码文件的扩展名是’.cpp’.
指定一个不同的扩展名也是可能的，只要定义LOCAL_DEFAULT_CPP_EXTENSION变量，不要忘记开始的小圆点（也就是’.cxx’,而不是’cxx’）

include
$(BUILD_SHARED_LIBRARY)

BUILD_SHARED_LIBRARY表示编译生成共享库，是编译系统提供的变量，指向一个GNU
Makefile脚本，负责收集自从上次调用'include
$(CLEAR_VARS)'以来，定义在LOCAL_XXX变量中的所有信息，并且决定编译什么，如何正确地去做。还有
BUILD_STATIC_LIBRARY变量表示生成静态库：lib$(LOCAL_MODULE).a， BUILD_EXECUTABLE 表示生成可执行文件。