android头文件

❶ ndk-Android NDk 怎么编译时动态链接第三方so库，有头文件

问题描述：Android如何调用第三方SO库；
已知条件：SO库为Android版本连接库（*.so文件），并提供了详细的接口说明；
已了解解决方案：
1.将SO文件直接放到libs/armeabi下，然后代码中System.loadLibrary("xxx")；再public native static int xxx_xxx_xxx()；接下来就可以直接调用xxx_xxx_xxx()方法；
2.第二种方案，创建自己的SO文件，在自己的SO文件里调用第三方SO，再在程序中调用自己的SO，这种比较复杂，需要建java类文件，生成.h文件，编写C源文件include之前生成的.h文件并实现相应方法，最后用android NDK开发包中的ndk-build脚本生成对应的.so共享库；
求解：
1.上面两种方案是否可行？不可行的话存在什么问题？
2.两种方案有什么区别？为什么网上大部都是用的第二种方案？
3.只有一个*.so文件，并提供了详细的接口说明，是否可在ANDROID中使用它？

首先要看这个SO是不是JNI规范的SO，比如有没有返回JNI不直接支持的类型。也就是说这个SO是不是可以直接当作JNI来调用。如果答案是否定的，你只能选第二个方案。

如果答案是肯定的，还要看你是不是希望这个SO的库直接暴露给JAVA层，如果答案是否定的，你只能选第二个方案，比如你本身也是一个库的提供者。

一般如果你只有SO，就说明这个是别人提供给你的，你可以要求对方给你提供配套的JAVA调用文件。

1、这个要看这个SO是不是符合JNI调用的规范。还要看你自己的意愿。
2、因为第二种方法最灵活，各种情况都可以实现。
3、可以

看能不能直接从JAVA调用的最简单的方法就是看SO里的函数名是不是Java_XXX_XXX_XXX格式的
是就可以，你可以自己写一个配套的JAVA文件，注意一下SO函数名和JAVA函数名的转换规则，或者向SO提供方索要；
不是的话就选第二种方案吧。

1、检查所需文件是否齐全
使用第三方动态库，应该至少有2个文件，一个是动态库（.so），另一个是包含
动态库API声明的头文件(.h)
2、封装原动态库
原动态库文件不包含jni接口需要的信息，所以我们需要对其进行封装，所以我
们的需求是：将libadd.so 里面的API封装成带jni接口的动态
3、编写库的封装函数libaddjni.c
根据前面生成的com_android_libjni_LibJavaHeader.h 文件，编写libaddjni.c，用
来生成libaddjni.so

Android中集成第三方软件包（.jar, .so）

Android中可能会用到第三方的软件包，这包括Java包.jar和Native包.so。jar包既可通过Eclipse开发环境集成，也可通过编译源码集成，看你的工作环境。

假定自己开发的程序为MyMaps，需要用到BaiMaps的库，包括mapapi.jar和libBMapApiEngine_v1_3_1.so。

一、Eclipse中集成第三方jar包及.so动态库

MyMaps工程下创建目录libs以及libs/armeabi，把mapapi.jar放在的libs/目录下，把libBMapApiEngine_v1_3_1.so放在libs/armeabi/下。

Eclipse中把第三方jar包mapapi.jar打包到MyMaps的步骤：

1. 右击工程，选择Properties；
2. Java Build Path，选择Libraries；
3. Libraries页面点击右面按钮“Add Library…”；
4. 选择“User Library”，点击“Next”；
5. 点击“User Libraries”按钮；
6. 在弹出界面中，点击“New…”；
7. 输入“User library name”，点击“OK”确认；
8. 返回之后，选择刚刚创建的User library，右面点击“AddJARs”；
9. 选择MyMaps/libs/下的mapapi.jar；
10. 确认，返回。

这样，编译之后，该jar包就会被打进MyMaps.apk中，libBMapApiEngine_v1_3_1.so也被打包在lib/armeabi/中。
程序运行过程中，libBMapApiEngine_v1_3_1.so被放在/data/data/<yourAppPackage>/lib/下，加载动态库时系统会从程序的该lib/目录下查找.so库。

二、源码中集成第三方集成jar包及.so动态库

Android源码中MyMaps放在packages/apps下。MyMaps下创建目录libs以及libs/armeabi，并把mapapi.jar放在libs/，把libBMapApiEngine_v1_3_1.so放在libs/armeabi。

2.1 修改Android.mk文件

Android.mk文件如下：

[plain] view plain
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := optional

LOCAL_STATIC_JAVA_LIBRARIES := libmapapi

LOCAL_SRC_FILES := $(call all-subdir-java-files)

LOCAL_PACKAGE_NAME := MyMaps

include $(BUILD_PACKAGE)

##################################################
include $(CLEAR_VARS)

LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES :=libmapapi:libs/mapapi.jar
LOCAL_PREBUILT_LIBS :=libBMapApiEngine_v1_3_1:libs/armeabi/libBMapApiEngine_v1_3_1.so
LOCAL_MODULE_TAGS := optional
include $(BUILD_MULTI_PREBUILT)

# Use the following include to make our testapk.
include $(callall-makefiles-under,$(LOCAL_PATH))

1 集成jar包
LOCAL_STATIC_JAVA_LIBRARIES取jar库的别名，可以任意取值；
LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES指定prebuiltjar库的规则，格式：别名:jar文件路径。注意：别名一定要与LOCAL_STATIC_JAVA_LIBRARIES里所取的别名一致，且不含.jar；jar文件路径一定要是真实的存放第三方jar包的路径。
编译用BUILD_MULTI_PREBUILT。
2 集成.so动态库
LOCAL_PREBUILT_LIBS指定prebuilt so的规则，格式：别名:so文件路径。注意：别名一般不可改变，特别是第三方jar包使用.so库的情况，且不含.so；so文件路径一定要是真实的存放第三方so文件的路径。
编译拷贝用BUILD_MULTI_PREBUILT。

2.2 加入到GRANDFATHERED_USER_MODULES

在文件user_tags.mk中，把libBMapApiEngine_v1_3_1加入到GRANDFATHERED_USER_MODULES中

[plain] view plain
GRANDFATHERED_USER_MODULES += \
… \
libBMapApiEngine_v1_3_1

user_tags.mk可以是build/core下的，也可以是$(TARGET_DEVICE_DIR)下的，推荐修改$(TARGET_DEVICE_DIR)下的。

2.3 编译结果

MyMaps.apk编译生成在out/target/proct/<YourProct>/system/app/下；
libBMapApiEngine_v1_3_1.so放在out/target/proct/<YourProct>/system/lib/下，这也是系统加载动态库时搜索的路径。

❷ 为什么编译android内核的时候， 编译器提示找不到头文件，而该头文件其实是存在的，

你应该帖出具体的报错提示。你有没有改好交叉编译链的位置，或者换个交叉编译链的版本试试

❸ android studio jni生成头文件

可以直接单击右键，然后有一个转另存，为然后这样的话就能够生成其他的文件类型了。

❹ android studio中导入头文件有没有什么快捷方式

你复制别人的程序的吧？你自己目录里面没有这个头文件，把你同事的这个tinyxml.h复制过来，放到自己工程里面

❺ android studio中有一个就是抛红，怎样为它添加头文件，在线等

在工程的头文件夹上右键添加新建项，选择头文件 包括的头文件要保存在有cpp的文件夹里才行

❻ 如何在android.mk中添加c++头文件

LOCAL_C_INCLUDE := XX.H \
XXX.H

❼ android.mk怎么在jni编译时把系统头文件包含

Android.mk文件用来告知NDK Build 系统关于Source的信息。 Android.mk将是GNU Makefile的一部分，且将被Build System解析一次或多次。
所以，请尽量少的在Android.mk中声明变量，也不要假定任何东西不会在解析过程中定义。

Android.mk文件语法允许我们将Source打包成一个"moles". moles可以是：
静态库
动态库。

只有动态库可以被 install/到应用程序包(APK). 静态库则可以被链接入动态库。
可以在一个Android.mk中定义一个或多个moles. 也可以将同一份source 加进多个moles.

Build System帮我们处理了很多细节而不需要我们再关心。例如：你不需要在Android.mk中列出头文件和外部依赖文件。
NDK Build System自动帮我们提供这些信息。这也意味着，当用户升级NDK后，你将可以受益于新的toolchain/platform而不必再去修改Android.mk.

1. Android.mk语法：
首先看一个最简单的Android.mk的例子：
LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c

include $(BUILD_SHARED_LIBRARY)
讲解如下：
LOCAL_PATH := $(call my-dir)
每个Android.mk文件必须以定义LOCAL_PATH为开始。它用于在开发tree中查找源文件。
宏my-dir则由Build System提供。返回包含Android.mk的目录路径。

include $(CLEAR_VARS)
CLEAR_VARS 变量由Build System提供。并指向一个指定的GNU Makefile，由它负责清理很多LOCAL_xxx.
例如：LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES等等。但不清理LOCAL_PATH.
这个清理动作是必须的，因为所有的编译控制文件由同一个GNU Make解析和执行，其变量是全局的。所以清理后才能避免相互影响。

LOCAL_MODULE := hello-jni
LOCAL_MODULE模块必须定义，以表示Android.mk中的每一个模块。名字必须唯一且不包含空格。
Build System会自动添加适当的前缀和后缀。例如，foo，要产生动态库，则生成libfoo.so. 但请注意：如果模块名被定为：libfoo.则生成libfoo.so. 不再加前缀。

LOCAL_SRC_FILES := hello-jni.c
LOCAL_SRC_FILES变量必须包含将要打包如模块的C/C++ 源码。
不必列出头文件，build System 会自动帮我们找出依赖文件。
缺省的C++源码的扩展名为.cpp. 也可以修改，通过LOCAL_CPP_EXTENSION。

include $(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY：是Build System提供的一个变量，指向一个GNU Makefile Script。
它负责收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。并决定编译为什么。

BUILD_STATIC_LIBRARY：编译为静态库。
BUILD_SHARED_LIBRARY ：编译为动态库
BUILD_EXECUTABLE：编译为Native C可执行程序

2. NDK Build System变量：
NDK Build System 保留以下变量名：
以LOCAL_ 为开头的
以PRIVATE_ ,NDK_ 或者APP_ 开头的名字。
小写字母名字：如my-dir

如果想要定义自己在Android.mk中使用的变量名，建议添加 MY＿前缀。

2.1: NDK提供的变量：
此类GNU Make变量是NDK Build System在解析Android.mk之前就定义好了的。
2.1.1：CLEAR_VARS：

指向一个编译脚本。必须在新模块前包含之。
include $(CLEAR_VARS)
2.1.2：BUILD_SHARED_LIBRARY：
指向一个编译脚本，它收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。
并决定如何将你列出的Source编译成一个动态库。 注意，在包含此文件前，至少应该包含：LOCAL_MODULE and LOCAL_SRC_FILES 例如：
include $(BUILD_SHARED_LIBRARY)

2.1.3：BUILD_STATIC_LIBRARY：
与前面类似，它也指向一个编译脚本，
收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。
并决定如何将你列出的Source编译成一个静态库。 静态库不能够加入到Project 或者APK中。但它可以用来生成动态库。
LOCAL_STATIC_LIBRARIES and LOCAL_WHOLE_STATIC_LIBRARIES将描述之。
include $(BUILD_STATIC_LIBRARY)

2.1.4: BUILD_EXECUTABLE:
与前面类似，它也指向一个编译脚本，收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。
并决定如何将你列出的Source编译成一个可执行Native程序。 include $(BUILD_EXECUTABLE)

2.1.5：PREBUILT_SHARED_LIBRARY：
把这个共享库声明为 “一个” 独立的模块。
指向一个build 脚本，用来指定一个预先编译好多动态库。 与BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY不同，
此时模块的LOCAL_SRC_FILES应该被指定为一个预先编译好的动态库，而非source file. LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt # 模块名
LOCAL_SRC_FILES := libfoo.so # 模块的文件路径（相对于 LOCAL_PATH）

include $(PREBUILT_SHARED_LIBRARY) # 注意这里不是 BUILD_SHARED_LIBRARY

这个共享库将被拷贝到 $PROJECT/obj/local 和 $PROJECT/libs/<abi> (stripped) 主要是用在将已经编译好的第三方库
使用在本Android Project中。为什么不直接将其COPY到libs/armabi目录呢？因为这样做缺陷很多。下一节再详细说明。

2.1.6: PREBUILT_STATIC_LIBRARY:预先编译的静态库。 同上。

2.1.7: TARGET_ARCH: 目标CPU架构名。如果为“arm” 则声称ARM兼容的指令。与CPU架构版本无关。

2.1.8: TARGET_PLATFORM: 目标平台的名字。

2.1.9：TARGET_ARCH_ABI
Name of the target CPU+ABI
armeabi For ARMv5TE armeabi-v7a
2.1.10：TARGET_ABI

2.2: NDK提供的功能宏：
GNUMake 提供的功能宏，只有通过类似： $(call function) 的方式来得到其值，它将返回文本化的信息。

2.2.1: my-dir: $(call my-dir):
返回最近一次include的Makefile的路径。通常返回Android.mk所在的路径。它用来作为Android.mk的开头来定义LOCAL_PATH. LOCAL_PATH := $(call my-dir)
请注意：返回的是最近一次include的Makefile的路径。所以在Include其它Makefile后，再调用$(call my-dir)会返回其它Android.mk 所在路径。 例如：
LOCAL_PATH := $(call my-dir) ... declare one mole include $(LOCAL_PATH)/foo/Android.mk LOCAL_PATH := $(call my-dir) ... declare another mole
则第二次返回的LOCAL_PATH为：$PATH/foo。 而非$PATH.

2.2.2: all-subdir-makefiles:
返回一个列表，包含'my-dir'中所有子目录中的Android.mk。
例如： 结构如下： sources/foo/Android.mk sources/foo/lib1/Android.mk sources/foo/lib2/Android.mk
在If sources/foo/Android.mk 中， include $(call all-subdir-makefiles) 那则自动include 了sources/foo/lib1/Android.mk and sources/foo/lib2/Android.mk。

2.2.3：this-makefile：
当前Makefile的路径。

2.2.4：parent-makefile：
返回include tree中父Makefile 路径。 也就是include 当前Makefile的Makefile Path。

2.2.5：import-mole：
允许寻找并inport其它moles到本Android.mk中来。 它会从NDK_MODULE_PATH寻找指定的模块名。 $(call import-mole,<name>)
2.3: 模块描述变量：
此类变量用来给Build System描述模块信息。在'include $(CLEAR_VARS)' 和 'include $(BUILD_XXXXX)'之间。必须定义此类变量。 include $(CLEAR_VARS) script用来清空这些变量。

include $(BUILD_XXXXX)收集和使用这些变量。

2.3.1: LOCAL_PATH:
这个值用来给定当前目录。必须在Android.mk的开是位置定义之。
例如： LOCAL_PATH := $(call my-dir) LOCAL_PATH不会被include $(CLEAR_VARS) 清理。

2.3.2: LOCAL_MODULE:
moles名。在include $(BUILD_XXXXX)之前，必须定义这个变量。此变量必须唯一且不能有空格。
通常，由此变量名决定最终生成的目标文件名。

2.3.3: LOCAL_MODULE_FILENAME:
可选。用来override LOCAL_MODULE. 即允许用户重新定义最终生成的目标文件名。 LOCAL_MODULE := foo-version-1 LOCAL_MODULE_FILENAME := libfoo
2.3.4：LOCAL_SRC_FILES：
为Build Moles而提供的Source 文件列表。不需要列出依赖文件。 注意：文件相对于LOCAL_PATH存放，
且可以提供相对路径。 例如： LOCAL_SRC_FILES := foo.c \ toto/bar.c
2.3.5: LOCAL_CPP_EXTENSION:
指出C++ 扩展名。(可选) LOCAL_CPP_EXTENSION := .cxx 从NDK R7后，可以写多个：
LOCAL_CPP_EXTENSION := .cxx .cpp .cc

2.3.6：LOCAL_CPP_FEATURES：
可选。用来指定C++ features。 LOCAL_CPP_FEATURES := rtti
LOCAL_CPP_FEATURES := exceptions

2.3.7：LOCAL_C_INCLUDES：
一个可选的path列表。相对于NDK ROOT 目录。编译时，将会把这些目录附上。 LOCAL_C_INCLUDES := sources/foo LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
2.3.8: LOCAL_CFLAGS:
一个可选的设置，在编译C/C++ source 时添加如Flags。
用来附加编译选项。 注意：不要尝试在此处修改编译的优化选项和Debug等级。它会通过您Application.mk中的信息自动指定。
也可以指定include 目录通过：LOCAL_CFLAGS += -I<path>。 这个方法比使用LOCAL_C_INCLUDES要好。因为这样也可以被ndk-debug使用。

2.3.9: LOCAL_CXXFLAGS: LOCAL_CPPFLAGS的别名。
2.3.10: LOCAL_CPPFLAGS:
C++ Source 编译时添加的C Flags。这些Flags将出现在LOCAL_CFLAGS flags 的后面。

2.3.11: LOCAL_STATIC_LIBRARIES:
要链接到本模块的静态库list。(built with BUILD_STATIC_LIBRARY)

2.3.12: LOCAL_SHARED_LIBRARIES:
要链接到本模块的动态库。

2.3.13：LOCAL_WHOLE_STATIC_LIBRARIES：

静态库全链接。 不同于LOCAL_STATIC_LIBRARIES，类似于使用--whole-archive

2.3.14：LOCAL_LDLIBS：

linker flags。 可以用它来添加系统库。 如 -lz: LOCAL_LDLIBS := -lz

2.3.15: LOCAL_ALLOW_UNDEFINED_SYMBOLS:

2.3.16: LOCAL_ARM_MODE:
缺省模式下，ARM目标代码被编译为thumb模式。每个指令16位。如果指定此变量为：arm。 则指令为32位。 LOCAL_ARM_MODE := arm 其实也可以指定某一个或者某几个文件的ARM指令模式。
2.3.17: LOCAL_ARM_NEON:
设置为true时，会讲浮点编译成neon指令。这会极大地加快浮点运算(前提是硬件支持)
只有targeting 为 'armeabi-v7a'时才可以。

2.3.18：LOCAL_DISABLE_NO_EXECUTE：

2.3.19: LOCAL_EXPORT_CFLAGS:
定义这个变量用来记录C/C++编译器标志集合，
并且会被添加到其他任何以LOCAL_STATIC_LIBRARIES和LOCAL_SHARED_LIBRARIES的模块的LOCAL_CFLAGS定义中 LOCAL_SRC_FILES := foo.c bar.c.arm
注意：此处NDK版本为NDK R7C.（不同NDK版本，ndk-build所产生的Makefile并不完全相同）

❽ android.mk文件怎么写

一个Android.mk file用来向编译系统描述你的源代码。具体来说：该文件是GNU Makefile的一小部分，会被编译系统解析一次或多次。你可以在每一个Android.mk file中定义一个或多个模块，你也可以在几个模块中使用同一个源代码文件。编译系统为你处理许多细节问题。例如，你不需要在你的Android.mk中列出头文件和依赖文件。NDK编译系统将会为你自动处理这些问题。这也意味着，在升级NDK后，你应该得到新的toolchain/platform支持，而且不需要改变你的Android.mk文件。
先看一个简单的例子：一个简单的"hello world"，比如下面的文件：
sources/helloworld/helloworld.c
sources/helloworld/Android.mk
相应的Android.mk文件会象下面这样：
---------- cut here ------------------
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE
:= helloworld
LOCAL_SRC_FILES := helloworld.c
include $(BUILD_SHARED_LIBRARY)
---------- cut here ------------------
我们来解释一下这几行代码：
LOCAL_PATH := $(call my-dir)
一个Android.mk file首先必须定义好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 := helloworld
LOCAL_MODULE变量必须定义，以标识你在Android.mk文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。注意编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为'foo'的共享库模块，将会生成'libfoo.so'文件。
LOCAL_SRC_FILES := helloworld.c
LOCAL_SRC_FILES变量必须包含将要编译打包进模块中的C或C++源代码文件。注意，你不用在这里列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。

在Android中增加本地程序或者库，这些程序和库与其所载路径没有任何关系，只和它们的Android.mk文件有关系。Android.mk和普通的Makefile有所不同，它具有统一的写法，主要包含一些系统公共的宏。
在一个Android.mk中可以生成多个可执行程序、动态库和静态库。
1，编译应用程序的模板：
#Test Exe
LOCAL_PATH := $(call my-dir)
#include $(CLEAR_VARS)
LOCAL_SRC_FILES:= main.c
LOCAL_MODULE:= test_exe
#LOCAL_C_INCLUDES :=
#LOCAL_STATIC_LIBRARIES :=
#LOCAL_SHARED_LIBRARIES :=
include $(BUILD_EXECUTABLE)
（菜鸟级别解释：:=是赋值的意思，$是引用某变量的值）LOCAL_SRC_FILES中加入源文件路径，LOCAL_C_INCLUDES 中加入所需要包含的头文件路径，LOCAL_STATIC_LIBRARIES加入所需要链接的静态库（*.a）的名称，LOCAL_SHARED_LIBRARIES中加入所需要链接的动态库（*.so）的名称，LOCAL_MODULE表示模块最终的名称，BUILD_EXECUTABLE表示以一个可执行程序的方式进行编译。
2，编译静态库的模板：
#Test Static Lib
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= /
helloworld.c
LOCAL_MODULE:= libtest_static
#LOCAL_C_INCLUDES :=
#LOCAL_STATIC_LIBRARIES :=
#LOCAL_SHARED_LIBRARIES :=
include $(BUILD_STATIC_LIBRARY)
一般的和上面相似，BUILD_STATIC_LIBRARY表示编译一个静态库。
3，编译动态库的模板：
#Test Shared Lib
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= /
helloworld.c
LOCAL_MODULE:= libtest_shared
TARGET_PRELINK_MODULES := false
#LOCAL_C_INCLUDES :=
#LOCAL_STATIC_LIBRARIES :=
#LOCAL_SHARED_LIBRARIES :=
include $(BUILD_SHARED_LIBRARY)
一般的和上面相似，BUILD_SHARED_LIBRARY表示编译一个静态库。
以上三者的生成结果分别在如下，generic依具体target会变：
out/target/proct/generic/obj/EXECUTABLE
out/target/proct/generic/obj/STATIC_LIBRARY
out/target/proct/generic/obj/SHARED_LIBRARY
每个模块的目标文件夹分别为：
可执行程序：XXX_intermediates
静态库： XXX_static_intermediates
动态库： XXX_shared_intermediates
另外，在Android.mk文件中，还可以指定最后的目标安装路径，用LOCAL_MODULE_PATH和LOCAL_UNSTRIPPED_PATH来指定。不同的文件系统路径用以下的宏进行选择：
TARGET_ROOT_OUT：表示根文件系统。
TARGET_OUT：表示system文件系统。
TARGET_OUT_DATA：表示data文件系统。
用法如：
CAL_MODULE_PATH:=$(TARGET_ROOT_OUT)

❾ android中jni开发怎么生成头文件

总共有三种方式生成Jni头文件，但归根结底只有一种，只是操作方法不一样，我在这里做一下记录，方便下次使用。
1.1
1.利用Android Studio的Terminal，进入你自己的Android工程文件的app/src/main目录，例如(D:\Users\AndroidStudio\Application\app\src\main)
在Terminal中输入命令
cd app\src\main
这样就进入到了main目录，可以使用dir命令查看当前目录有哪些文件
总共有三种方式生成Jni头文件

2. 在Terminal中输入命令
javah -d jni -jni -classpath ..\..\build\intermediates\classes\debug com.example.lenovo.application.JniClass
解释：
-d<dir> 输出目录，后面跟上要生成的目录名
-jni 生成Jni样式的标头文件
-classpath<path> 指定加载类的路径，后面跟上你要生成头文件的这个类的路径，例如：
..\..\..\build\intermediates\classes\debug（这个是类所在的路径）
com.example.lenovo.application.JniClass（类的包名）

注意，要生成.class文件，要Make Project

3.如果前面没有出错的话，就能看到jni文件和生成的头文件

其实jni目录可以不用命令生成，Android Studio已经为我们准备好了。

这样就能快速的生成jni目录了。
然后在Terminal中进入到该目录，输入命令
cd app\src\main\jni

在执行如下命令
javah -d jni -jni -classpath ..\..\build\intermediates\classes\debug com.example.lenovo.application.JniClass
这样也能生成头文件

利用Windows的cmd生成jni头文件
1.进入到你自己Android工程目录下的app\build\intermediates\classes\debug

2.然后Shift加鼠标右键，点击红色方框的内容

3.出现cmd命令行，输入如下命令
javah -jni com.example.lenovo.application.JniClass

4.会在当前目录生成*.h头文件，把它拷贝进jni目录就可以了。
jni目录可以按照上面的方法创建

至此，生成jni头文件的三种方法讲解完毕。

❿ android 封装成.so文件后头文件怎么交互

慢慢地楼主发现，这样做也有其不可忽视的弊端：
1.对于Android来说，使用.so就要写JNI接口，这样“可移植”性就非常不好（虽然我们也不做什么跨平台的事...）；
2.一旦库中接口发生变化，数个端就要配合做改动，可谓牵一发而动全身，作为上层开发人员这样非常被动；
3.Java/Android提供的一些便利的API，作为使用c/c++开发的库本身就享受不到，这样会增加一部分成本和风险；

4.这样的方式，在开发过种中，编写.so库的同事也会非常头疼，Android提供的native调试工具是非常难用的，大多数情况要加大量的log来定位问题；
5.在需要上层与库发生交互时，比如native代码回调上层，native层有心跳在监听状态等，这些情况需要大量、稳定的JNI代码做支撑，给Android程序员带来一些额外的成本；