解决Camera HAL层无法多次回调数据到App

一、问题描述
在一个双摄项目中, 需要在HAL(使用 API1/HAL1)层集成Bokeh功能(双摄虚化), 同时需要将相关双摄数据回调到App存储, 用于集成Refocus功能(即可以在相册中重新选择虚化焦点和虚化强度). 因此需要回传的数据有, bokeh效果图, 主摄原图, depth数据, bokeh效果图可以走主摄jpeg回调直接返回到App,剩余的两个数据当初考虑使用jpeg callback或者postview callback分两次传回App, 但在实际实施过程中过, 使用postview 回传数据时, App始终只能接受到一次数据, 使用jpeg回传除了bokeh效果图, 其他数据也接收不到,也就是两个回调接口都只能回调一次数据, 这就导致功能没法完成, 这篇文章主要是讲解决这个问题的思路.

二、解决思路
在解决问题前, 我们已知的信息是: 回调接口使用肯定没有问题, 因为数据的确可以回调, 只是每个回调接口只能回调一次数据而已. 因此最大可能性是回调的数据在某个位置被丢弃了, 所以要解决问题, 就得一步一步看数据回调流程.
我们主要关注的文件有 :

frameworks/base/core/java/android/hardware/Camera.java

frameworks/base/core/jni/android_hardware_Camera.cpp

frameworks/av/camera/Camera.cpp
frameworks/av/services/camera/libcameraservice/api1/CameraClient.cpp
frameworks/av/services/camera/libcameraservice/device1/CameraHardwareInterface.h

这几个文件中都有数据回调相关的函数(dataCallback), 具体是那些函数就不一一介绍了, 主要讲下解决的思路,
至此, 我们一般有两种方法来定位此问题:

详细阅读每个文件中和数据回调相关的函数, 看看那些地方会丢弃回到数据
在每个文件的回调函数中关键位置打印一些Log, 编译刷机, 跑下原始流程, 看Log在哪里出现异常
显然第一种方式更利于理解整体流程, 而第二种方式则能更快定位并解决问题, 但都是不错的解决方案.

三、问题分析
由于我当时项目比较紧急, 所以用的第二种方式解决问题, 通过打印Log, 最终定位到是在CameraClient.cpp中, 回调数据被丢弃了.

关键函数如下:

注: 代码均为 Android 8.0 高通SDM450平台

 void CameraClient::dataCallback(int32_t msgType,
        const sp<IMemory>& dataPtr, camera_frame_metadata_t *metadata, void* user) {
    LOG2("dataCallback(%d)", msgType);

    sp<CameraClient> client = getClientFromCookie(user);
    if (client.get() == nullptr) return;

    if (!client->lockIfMessageWanted(msgType)) return;
    if (dataPtr == 0 && metadata == NULL) {
        ALOGE("Null data returned in data callback");
        client->handleGenericNotify(CAMERA_MSG_ERROR, UNKNOWN_ERROR, 0);
        return;
    }

    switch (msgType & ~CAMERA_MSG_PREVIEW_METADATA) {
        case CAMERA_MSG_PREVIEW_FRAME:
            client->handlePreviewData(msgType, dataPtr, metadata);
            break;
        case CAMERA_MSG_POSTVIEW_FRAME:
            client->handlePostview(dataPtr);
            break;
        case CAMERA_MSG_RAW_IMAGE:
            client->handleRawPicture(dataPtr);
            break;
        case CAMERA_MSG_COMPRESSED_IMAGE:
            client->handleCompressedPicture(dataPtr);
            break;
        default:
          client->handleGenericData(msgType, dataPtr, metadata);

可以看到, 此函数中会造成数据不往上传有两部分 lockIfMessageWanted()函数和本身数据是否为空的判断, 由于数据为空会有error log打印出来, 所以能确定是lockIfMessageWanted()造成数据被丢弃.

 #define CHECK_MESSAGE_INTERVAL 10 // 10ms
bool CameraClient::lockIfMessageWanted(int32_t msgType) {
    int sleepCount = 0;
    while (mMsgEnabled & msgType) {
        if (mLock.tryLock() == NO_ERROR) {
            if (sleepCount > 0) {
                LOG1("lockIfMessageWanted(%d): waited for %d ms",
                    msgType, sleepCount * CHECK_MESSAGE_INTERVAL);
            }

            // If messages are no longer enabled after acquiring lock, release and drop message
            if ((mMsgEnabled & msgType) == 0) {
                mLock.unlock();
                break;
            }

            return true;
        }
        if (sleepCount++ == 0) {
            LOG1("lockIfMessageWanted(%d): enter sleep", msgType);
        }
        usleep(CHECK_MESSAGE_INTERVAL * 1000);
    }
    ALOGW("lockIfMessageWanted(%d): dropped unwanted message", msgType);
    return false;
}

可以直观的看到当mMsgEnabled & msgTyp 为false时, 函数返回false, 导致dataCallback()直接返回, 不往下走了, 而 mMsgEnabled & msgType为false表明此时 msgType 没有被启用, 拍照返回jpeg数据使用的msgType为 CAMERA_MSG_COMPRESSED_IMAGE,因此要分析 CAMERA_MSG_COMPRESSED_IMAGE何时被启用和禁用, 搜索关键字后, 可以看到 CAMERA_MSG_COMPRESSED_IMAGE启用是在takePicture()时, 禁用是在拍照数据返回时handleCompressedPicture()

相关代码如下:

    //启用, takePicture()函数中的代码片段
    // We only accept picture related message types
    // and ignore other types of messages for takePicture().
    int picMsgType = msgType
                        & (CAMERA_MSG_SHUTTER |
                           CAMERA_MSG_POSTVIEW_FRAME |
                           CAMERA_MSG_RAW_IMAGE |
                           CAMERA_MSG_RAW_IMAGE_NOTIFY |
                           CAMERA_MSG_COMPRESSED_IMAGE);
    enableMsgType(picMsgType);
//--------------------------------------------------
    //禁用 handleCompressedPicture()中的代码片段
     if (!mBurstCnt && !mLongshotEnabled) {
        LOG1("handleCompressedPicture mBurstCnt = %d", mBurstCnt);
        disableMsgType(CAMERA_MSG_COMPRESSED_IMAGE);
    }

到此可以看出问题产生的原因是camera framework 本身设计就是拍一次照, 只接受一次数据返回, postview callback也是如此, 多次回调默认是不允许的
解决方案
从上面分析可以看出, 如果不做任何修改, 是没法使用同一个callback在拍照后回调多次数据的,所以解决方法有两种:

1、将所有数据组装到一起, 一次性回到到app
2、修改framework代码, 去除此部分的限制
方法1缺点是要自己组装数据, 并且记录各个数据的大小, 不然app端无法解析数据
方法2高通已经帮我们实现了, 代码如下:

if (!mBurstCnt && !mLongshotEnabled) {
        LOG1("handleCompressedPicture mBurstCnt = %d", mBurstCnt);
        disableMsgType(CAMERA_MSG_COMPRESSED_IMAGE);
    }

高通修改过后, 如果是连拍或者mBurstCnt > 1, 则不会去disable CAMERA_MSG_COMPRESSED_IMAGE这个msg, 而mBurstCnt的值是通过参数获取的, 代码如下:

mBurstCnt = mHardware->getParameters().getInt("num-snaps-per-shutter");
    if(mBurstCnt <= 0)
        mBurstCnt = 1;

因此我们如果要回调多个数据, 则只需在拍照前, 设置num-snaps-per-shutter这个Camera参数, 其值为我们回调数据的数量, 此功能也会用到高通的一些AOST Feature上, 比如 高通的UbiFocus模式下, num-snaps-per-shutter的值为 7 , 也就是说这个功能会回调7次jpeg数据到app, 高通只修改了jpeg 回调这部分内容, 像postview 和其他数据回调则没有修改, 还是只能拍一次照, 回调一次数据.

一、总结
Google原始设计对拍照数据回调有限制, 一次takePicture()每个callback只能返回一次数据, 数据返回后, 相应MSG会被Disable, 导致后面再回调的数据不会回调App.
高通对默认流程做了修改, 可通过设置Camera参数, 控制jpeg callback回调的次数.