androidso库调用

1. Android 动态链接库 So 的加载

前言

在Android项目中，尝试在NativeActivity中动态加载.so文件时遇到了"Caused by: java.lang.IllegalArgumentException: Unable to find native library using classloader: dalvik.system.PathClassLoader"异常。本文将解析Android动态链接库.so的加载过程和原理，帮助理解整个流程并为后续学习热修复提供帮助。

Android动态链接库.so的加载有两种方式：通过调用System.load(String filename)方法传递路径，或调用loadLibrary(String libname)方法传递.so名称。

本文将深入分析从添加.so文件到成功加载的整个过程，包括加载的类加载器来源、.so文件的来源以及加载原理。通过解析源码，我们可以清晰地了解动态加载.so文件的流程。

在加载.so文件的过程中，系统会调用JNI_OnLoad方法，并根据JNI版本进行初始化。JNI版本需在JNI_OnLoad方法中指定，常见的版本有JNI_VERSION_1_2、JNI_VERSION_1_4和JNI_VERSION_1_6。

解决加载.so文件的问题时，关键在于确保.so文件路径在类加载器的libs路径中。可以通过反射的方式将存放.so文件的路径添加到类加载器的nativeLibraryDirectories中，从而解决异常问题。

本文详细解析了Android动态链接库.so的加载流程和原理，不仅帮助理解异常产生的原因，还提供了解决方法。通过深入学习，开发者能够更好地掌握动态加载.so文件的技术，提升项目开发效率。

2. Android怎么调用第三方SO动态链接库

对于Android调用第三方SO动态链接库，我们可以从两个主要的方案来考虑。第一个方案是直接将SO文件放置于libs/armeabi目录下，然后在代码中通过System.loadLibrary("xxx")来加载，紧接着定义public native static int xxx_xxx_xxx()方法，这样就可以直接调用xxx_xxx_xxx()方法了。

第二种方案则更为复杂，它涉及到自己创建SO文件，这个SO文件会调用第三方的SO。为了实现这一点，需要创建一个Java类文件，生成对应的.h文件，编写C源文件并包含生成的.h文件，实现相应的方法，最后使用Android NDK开发包中的ndk-build脚本生成对应的.so共享库。

关于网上讨论的第二种方案，即自己引用so库的说法，我们需要考虑几个因素。首先，这个SO是否符合JNI调用规范，例如是否直接支持特定类型。如果不符合，我们只能选择第二种方案。如果符合，那么是否希望这个SO直接暴露给JAVA层也是需要考虑的因素。如果不想，同样只能选择第二种方案。

通常情况下，当你只有SO文件，这表明这是一个由他人提供的库，你可以要求对方提供配套的JAVA调用文件。因此，在实际操作中，我们首先需要检查SO文件是否符合JNI调用规范，以及根据自身的需求决定是否需要直接暴露给JAVA层。

第二种方案之所以更为灵活，是因为它可以应对各种情况，尤其是当直接调用第三方SO文件存在困难时。而如果SO文件符合JNI规范，且你愿意将其直接暴露给JAVA层，那么直接调用的方法将更为简便。

在尝试从JAVA调用时，最简单的判断方法是查看SO里的函数名是否遵循Java_XXX_XXX_XXX的格式。如果符合，你可以自己编写配套的JAVA文件，注意函数名的转换规则，或者向SO提供方索要。如果不符，则需要采取第二种方案。

总的来说，选择哪种方案取决于你的具体需求和第三方SO文件的具体情况。在实际应用中，合理选择方案能够有效提升开发效率。

3. 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/下，这也是系统加载动态库时搜索的路径。

4. android没有jni文件，怎么使用第三方.so文件

在Android开发中，若遇到没有JNI文件而需要使用第三方.so文件的情况，有几种方式可以实现。最直接的方式是将第三方的.so文件直接放置于libs/armeabi目录下，然后在代码中使用System.loadLibrary("xxx")加载。同时，需要定义一个public native static的方法，例如public native static int xxx_xxx_xxx()，之后便可以调用此方法进行操作。

另一种较为复杂的方案是创建自己的SO文件，该文件中调用第三方的SO文件。具体步骤包括建立Java类文件，生成对应的.h文件，编写包含该.h文件的C源代码并实现相应方法，最后利用Android NDK开发包中的ndk-build脚本生成相应的.so共享库。这一过程涉及较多的开发步骤，但能够实现更灵活的调用。

除了上述方法，还有针对Android应用的安全防护措施。例如DEX加壳保护，这是一种通过将DEX文件隐藏，并生成类似于虚像的壳文件来防止黑客利用反编译工具获取App源码的技术。此外，爱加密（http://www.ijiami.cn/）还提供了一种SO库保护功能，旨在保障C/C++层代码的安全。同时，爱加密还提供了资源文件保护、XML主配文件保护等措施，确保应用在动态和静态环境下的安全性。

通过这些安全防护措施，开发者可以有效提高应用的安全性，防止恶意攻击者通过各种手段获取应用源码或破解应用。这些技术手段不仅适用于第三方.so文件的使用场景，同样适用于其他类型的Android应用开发需求。