背景

现在越来越多应用包含一些第三方C/C++算法库, 比如图像处理, 人脸检测, 语音识别等等. 第三方提供的算法库都是C/C++动态库(.so), 不同的提供商提供的接口存在差异, 主要分为以下两种:

提供Java接口和so库

这种类型调用很简单, 把so库放到打包到apk或者Android系统中, 通过Java接口调用即可, JNI部分代码提供商都写好了.

只提供C/C++接口和so库

此类型调用稍微麻烦些, 需要自己写编译规则和JNI代码

由于一般算法库既可能集成在App中, 也有可能集成在Android系统中, 所以大部分算法提供商都是只提供C/C++接口, 这样就更省事, 只是在App集成稍微麻烦些,下面就讲一下这两种方式如何集成和调用.

App中调用C/C++算法库

由于提供的算法库中并没有JNI部分代码, 所以我们需要自己写JNI代码, 并在native方法中调用算法提供的接口, 最终会产生两个so库, 一个包含我们的native代码, 另一个就是算法库, 集成步骤如下:

1.编写JNI代码

这部分可参看资料很多, 本文不做介绍,直接略过,可参考我之前写的文章:Android JNI 函数注册的两种方式(静态注册/动态注册)

2.编写Android.mk和Application.mk

so库是通过NDK编译产生的, 我们需要编写编译规则,其中主要注意的有两点, 1. 算法商提供的so是以预置的方式(prebuild)进行编译的. 2.我们写的native代码也是编译成so文件, 并且要依赖于算法so库.

假设算法提供的so库名字为libalgo.so, 提供的头文件为algo.h, 可供调用的方法为 const char* getVersion(), 我们写的代码在test.cpp中 , jni目录结构如下:

jni

│─Android.mk

│─Application.mk

│─test.cpp

│

├─include

│── algo.h

│

├─lib

│── libalgo.so

Android.mk代码如下:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := algo

LOCAL_SRC_FILES := lib/libalgo.so

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include

#预编译算法库

include $(PREBUILT_SHARED_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE := test

LOCAL_SRC_FILES := test.cpp

#依赖的算法库

LOCAL_SHARED_LIBRARIES := libalgo

#编译为动态库

include $(BUILD_SHARED_LIBRARY)

Application.mk

#编译arm架构32位so库, 64位为 arm64-v8a

APP_ABI := armeabi-v7a

APP_PLATFORM := android-14

test.cpp部分代码如下:

#include "jni.h"

#include "algo.h"

int test(JNIEnv *env,jclass obj)

{

const char* algoVersion = getVersion();

//其他代码....

return 0;

}

3. 编译运行

在jni目录下执行ndk-build即可生成两个so库, 分别为libtest.so和libalgo.so, 将so打包到apk并在java代码中加载so库

System.loadLibrary("test");

加载后调用对应java native方法即可.

注: NDK编译时候LOCAL_MODULE的名字不需要带lib前缀, NDK会自动补上, 同时Java 加载时也不需要写lib前缀,并且我们只需加载libtest.so, 当加载libtest.so时, 会自动加载libalgo.so

Android系统中通过C/C++调用算法库

对于手机厂商(ODM/OEM)来说, 集成算法都是在直接集成到Android系统中, 这样效率会比较高, 集成的位置一般是HAL层, 比如Camera美颜, 降噪等算法基本都集成在Camera HAL层.Camera HAL层都是C/C++代码, 直接调用相应算法库即可, 但由于Android系统中编译方式是由Android.mk来组成, 并且和NDK中的Android.mk有差异, 因此主要不同点在于mk文件的编写, 步骤如下:

同样假设算法商提供的so库名字为libalgo.so, 提供的头文件为algo.h, 可供调用的方法为 const char* getVersion();

1. 在Android源码中预编译算法库

比如我经常在高通平台HAL层集成Camera相关算法, 则在 hardware/qcom/camera/QCamera2/HAL/ 文件夹下新建目录, 用于存放算法库和头文件,以及Android.mk, 假设目录为 hardware/qcom/camera/QCamera2/HAL/algo/

目录内容如下:

algo

│─Android.mk

│

├─include

│── algo.h

│

├─lib

│── libalgo.so

Android.mk内容

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

#默认不会加上lib前缀

LOCAL_MODULE := libalgo

#不管是release还是debug版本, 都编译这个模块

LOCAL_MODULE_TAGS := optional

#so文件路径以及名字

LOCAL_SRC_FILES := lib/libalgo.so

LOCAL_MODULE_STEM := $(LOCAL_MODULE)

#需要指定文件后缀

LOCAL_MODULE_SUFFIX := $(suffix $(LOCAL_SRC_FILES))

#编译32位算法库

LOCAL_MULTILIB := 32

#表明预编译的是动态库

LOCAL_MODULE_CLASS := SHARED_LIBRARIES

include $(BUILD_PREBUILT)

可以看到源码编译和NDK编译Android.mk的内容有较大差异, 主要表现在如下方面:

LOCAL_MODULE默认不会加上lib前缀

要指定文件后缀

要说明编译的文件类型(动态库, 静态库,apk等等)

预编译使用 BUILD_PREBUILT而不是 PREBUILT_SHARED_LIBRARY

2. 在调用的模块Android.mk中加入依赖库文件

预编译完成后, 要告诉调用模块, 需要依赖这个so库和头文件, 同样以在Camera HAL层调用为例,

修改 hardware/qcom/camera/QCamera2/HAL/Android.mk, 修改内容如下:

#部分代码省略

LOCAL_C_INCLUDES := \

$(LOCAL_PATH)/../util \

$(LOCAL_PATH)/wrapper

# 引入调用算法库的头文件

LOCAL_C_INCLUDES += \

$(LOCAL_PATH)/algo/include

#部分代码省略

LOCAL_SHARED_LIBRARIES += libqdMetaData libqservice libbinder

# 表明当前HAL模块依赖我们要调用的算法库

LOCAL_SHARED_LIBRARIES += libalgo

#部分代码省略

#在最末尾出引入我们预编译的Android.mk, 不然默认系统不会执行我们写的预编译用的Android.mk

include $(LOCAL_PATH)/algo/Android.mk

3. 调用算法库

调用算法库方法和App中一样, 引入头文件调用对应函数即可. 比如在 QCamera2HWI.cpp 中进行调用的话, 修改如下:

// 部分代码省略...

#include

#include

#include

#include

#include "QCamera2HWI.h"

#include "QCameraMem.h"

// 引入算法库对应的头文件

#include "algo.h"

// 在startPreview函数中进行调用

int QCamera2HardwareInterface::startPreview()

{

ATRACE_CALL();

int32_t rc = NO_ERROR;

// 部分代码省略...

// 调用

const char* algoVersion = getVersion();

}

3. 编译运行

完成上述内容后, 直接编译系统刷机运行即可, 也可以模块编译, 即上面的例子中, 可以使用如下命令编译(前提是之前已经全部编译过系统了): mmm hardware/qcom/camera/QCamera2/HAL/

执行完成后, 有两个so库需要push到手机对应位置 camera.xxx.so 和 libalgo.so, camera.xxx.so 是Camera HAL层编译完生成的so, xxx代表使用的平台比如 msm8953, 另一个就是我们集成的算法库, push后需重启手机生效.

如果编译的时候出现一些找不到函数的一些错误, 可以看看这篇文章: 一些算法集成遇到的问题

Android.mk注意事项

集成过程中免不了要写写mk代码, Android.mk编写过程中有些坑, 在此给大家说下我遇到过的坑.

include其他Android.mk时, include语句要放在mk文件末尾

编写Android.mk文件经常需要引入其他目录或者子目录mk文件, 一般做法有两种:

# include指定目录mk

include $(LOCAL_PATH)/Denoise/Android.mk

# include 当前文件夹子目录下的mk

include $(call all-subdir-makefiles)

在mk中使用这两个mk语句都需要放在文件夹末尾,因为mk中的变量是全局的,如果放在文件中间,会改变当前的一些变量值,比如LOCAL_PATH值变为你include的目录了,这样目录就会出错,导致编译失败.

include $(call all-subdir-makefiles)只会引入当前目录下一级子目录的mk, 更深层次mk不会被引入

这个是系统定义的函数, 默认只会引入当前目录下一级的Android.mk, 更深层次的mk需要自己手动引入, 或者每个目录都放一个mk, 其中只写include $(call all-subdir-makefiles)这个语句.

对于在已经赋值过的变量, 追加值使用 +=, := 会覆盖之前的值

使用#注释代码时,如果使用了\, 会把所有代码都注释掉,而不是注释一行

下面的#注释会将所有变量都注释掉,而不是注释QCamera2Factory.cpp这一行.

LOCAL_SRC_FILES := \

# QCamera2Factory.cpp \

QCamera2Hal.cpp \

QCamera2HWI.cpp \

QCameraMem.cpp \

总结

NKD和Android源码中的Android.mk(makefile)的语法有差异, NDK编译只是针对C/C++代码,而Android源码中的Android.mk是用来编译整个系统的.

NDK编译的mk中, LOCAL_MODULE会自动加上前缀lib, 预编译使用PREBUILT_SHARED_LIBRARY, Android系统中LOCAL_MODULE不会被添加前缀, 预编译使用BUILD_PREBUILT, 且要指定后缀名, 编译文件的类型

两种编译方式都需使用LOCAL_SHARED_LIBRARIES 来表明依赖的so库, 并且加载动态库时会自动加载对应依赖的动态库.