背景
现在越来越多应用包含一些第三方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库, 并且加载动态库时会自动加载对应依赖的动态库.