Android : Camera2/HAL3 框架分析

一、Android O上的Treble机制：

　　在 Android O 中，系统启动时，会启动一个 CameraProvider 服务，它是从 cameraserver 进程中分离出来，作为一个独立进程 [email protected] 用来控制 camera HAL，cameraserver通过 HIDL 机制于camera provider进行通信。HIDL源自于 Android O 版本加入的 Treble 机制，它的主要功能是将 service 与 HAL 隔离，以方便 HAL 部分进行独立升级，类似于 APP 与 Framework 之间的 Binder 通信机制，通过引入一个进程间通信机制而针对不同层级进行解耦（从 Local call 变成了 Remote call）。如下图：

　　　　　　

　　

cameraserver 与 provider 这两个进程启动、初始化的调用逻辑，如下图：

　　　　　　

二、Camera HAL3的框架更新：

　1.Camera HAL3 构建连路的过程，如下图（红色虚线是上行路线，黑色虚线则是下行路线）：

　　

　2.从 App 到 CameraService的调用流程

　　从 Application 连接到 CameraService，这涉及到 Android 架构中的三个层次：App 层，Framework 层，Runtime 层。其中，App 层直接调用 Framework 层所封装的方法，而 Framework 层需要通过 Binder 远程调用 Runtime 中 CameraService 的函数。
　　这一部分主要的函数调用逻辑如下图所示：
　　


　　在 App 中，需要调用打开相机的API如下:

  • CameraCharacteristics：描述摄像头的各种特性，我们可以通过CameraManager的getCameraCharacteristics(@NonNull String cameraId)方法来获取。
  • CameraDevice：描述系统摄像头，类似于早期的Camera。
  • CameraCaptureSession：Session类，当需要拍照、预览等功能时，需要先创建该类的实例，然后通过该实例里的方法进行控制（例如：拍照 capture()）。
  • CaptureRequest：描述了一次操作请求，拍照、预览等操作都需要先传入CaptureRequest参数，具体的参数控制也是通过CameraRequest的成员变量来设置。
  • CaptureResult：描述拍照完成后的结果。

　　例如打开camera的java代码：

　mCameraManager.openCamera(currentCameraId, stateCallback, backgroundHandler);

　　Camera2拍照流程如下所示：

　　

　　

　(1)Framework CameraManager ：/frameworks/base/core/java/android/hardware/camera2/CameraManager.java

　　最初的入口就是 CameraManager 的 openCamera 方法，但通过代码可以看到，它仅仅是调用了 openCameraForUid 方法。

@RequiresPermission(android.Manifest.permission.CAMERA)
public void openCamera(@NonNull String cameraId,
        @NonNull final CameraDevice.StateCallback callback, @Nullable Handler handler)
        throws CameraAccessException {

    openCameraForUid(cameraId, callback, handler, USE_CALLING_UID);
}

　　下面的代码忽略掉了一些参数检查相关操作，最终主要调用了 openCameraDeviceUserAsync 方法。

public void openCameraForUid(@NonNull String cameraId,
        @NonNull final CameraDevice.StateCallback callback, @Nullable Handler handler,
        int clientUid)
        throws CameraAccessException {
    /* Do something in*/
    ......
    /* Do something out*/
    openCameraDeviceUserAsync(cameraId, callback, handler, clientUid);
}

　　参考如下注释分析：

private CameraDevice openCameraDeviceUserAsync(String cameraId,
        CameraDevice.StateCallback callback, Handler handler, final int uid)
        throws CameraAccessException {
    CameraCharacteristics characteristics = getCameraCharacteristics(cameraId);
    CameraDevice device = null;

    synchronized (mLock) {

        ICameraDeviceUser cameraUser = null;

        android.hardware.camera2.impl.CameraDeviceImpl deviceImpl =   //实例化一个 CameraDeviceImpl。构造时传入了 CameraDevice.StateCallback 以及 Handler。
                new android.hardware.camera2.impl.CameraDeviceImpl(
                    cameraId,
                    callback,
                    handler,
                    characteristics,
                    mContext.getApplicationInfo().targetSdkVersion);

        ICameraDeviceCallbacks callbacks = deviceImpl.getCallbacks(); //获取 CameraDeviceCallback 实例，这是提供给远端连接到 CameraDeviceImpl 的接口。

       try {
            if (supportsCamera2ApiLocked(cameraId)) {  //HAL3 中走的是这一部分逻辑，主要是从 CameraManagerGlobal 中获取 CameraService 的本地接口，通过它远端调用（采用 Binder 机制） connectDevice 方法连接到相机设备。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//注意返回的 cameraUser 实际上指向的是远端 CameraDeviceClient 的本地接口。
                // Use cameraservice‘s cameradeviceclient implementation for HAL3.2+ devices
                ICameraService cameraService = CameraManagerGlobal.get().getCameraService();
                if (cameraService == null) {
                    throw new ServiceSpecificException(
                        ICameraService.ERROR_DISCONNECTED,
                        "Camera service is currently unavailable");
                }
                cameraUser = cameraService.connectDevice(callbacks, cameraId,
                        mContext.getOpPackageName(), uid);
            } else {
                // Use legacy camera implementation for HAL1 devices
                int id;
                try {
                    id = Integer.parseInt(cameraId);
                } catch (NumberFormatException e) {
                    throw new IllegalArgumentException("Expected cameraId to be numeric, but it was: "
                            + cameraId);
                }

                Log.i(TAG, "Using legacy camera HAL.");
                cameraUser = CameraDeviceUserShim.connectBinderShim(callbacks, id);
            }
        } catch (ServiceSpecificException e) {
            /* Do something in */
            ......
            /* Do something out */
        }

        // TODO: factor out callback to be non-nested, then move setter to constructor
        // For now, calling setRemoteDevice will fire initial
        // onOpened/onUnconfigured callbacks.
        // This function call may post onDisconnected and throw CAMERA_DISCONNECTED if
        // cameraUser dies during setup.
        deviceImpl.setRemoteDevice(cameraUser); //将 CameraDeviceClient 设置到 CameraDeviceImpl 中进行管理。
        device = deviceImpl;
    }

    return device;
}

　(2)CameraDeviceImpl : /frameworks/base/core/java/android/hardware/camera2/Impl/CameraDeviceImpl.java

　　在继续向下分析打开相机流程之前，先简单看看调用到的 CameraDeviceImpl 中的setRemoteDevice 方法，主要是将获取到的远端设备保存起来：

/**
 * Set remote device, which triggers initial onOpened/onUnconfigured callbacks
 *
 * <p>This function may post onDisconnected and throw CAMERA_DISCONNECTED if remoteDevice dies
 * during setup.</p>
 *
 */
public void setRemoteDevice(ICameraDeviceUser remoteDevice) throws CameraAccessException {
    synchronized(mInterfaceLock) {
        // TODO: Move from decorator to direct binder-mediated exceptions
        // If setRemoteFailure already called, do nothing
        if (mInError) return;

        mRemoteDevice = new ICameraDeviceUserWrapper(remoteDevice); //通过 ICameraDeviceUserWrapper 给远端设备实例加上一层封装。

        IBinder remoteDeviceBinder = remoteDevice.asBinder(); //使用 Binder 机制的一些基本设置。
        // For legacy camera device, remoteDevice is in the same process, and
        // asBinder returns NULL.
        if (remoteDeviceBinder != null) {
            try {
                remoteDeviceBinder.linkToDeath(this, /*flag*/ 0); //如果这个binder消失，为标志信息注册一个接收器。
            } catch (RemoteException e) {
                CameraDeviceImpl.this.mDeviceHandler.post(mCallOnDisconnected);

                throw new CameraAccessException(CameraAccessException.CAMERA_DISCONNECTED,
                        "The camera device has encountered a serious error");
            }
        }

        mDeviceHandler.post(mCallOnOpened); //需此处触发 onOpened 与 onUnconfigured 这两个回调，每个回调都是通过 mDeviceHandler 启用一个新线程来调用的。
        mDeviceHandler.post(mCallOnUnconfigured);
    }
}

　（3）Runtime：通过 Binder 机制，我们远端调用了 connectDevice 方法（在 C++ 中称为函数，但说成方法可能更顺口一些），这个方法实现在 CameraService 类中。

　（4）CameraService：/frameworks/av/services/camera/libcameraservice/CameraService.cpp

Status CameraService::connectDevice(
        const sp<hardware::camera2::ICameraDeviceCallbacks>& cameraCb,
        const String16& cameraId,
        const String16& clientPackageName,
        int clientUid,
        /*out*/
        sp<hardware::camera2::ICameraDeviceUser>* device) {

    ATRACE_CALL();
    Status ret = Status::ok();
    String8 id = String8(cameraId);
    sp<CameraDeviceClient> client = nullptr;

　　 //此处调用的 connectHelper 方法才真正实现了连接逻辑（HAL1 时最终也调用到这个方法）。需要注意的是，设定的模板类型是 ICameraDeviceCallbacks 以及 CameraDeviceClient。
    ret = connectHelper<hardware::camera2::ICameraDeviceCallbacks,CameraDeviceClient>(cameraCb, id,
            CAMERA_HAL_API_VERSION_UNSPECIFIED, clientPackageName,
            clientUid, USE_CALLING_PID, API_2,
            /*legacyMode*/ false, /*shimUpdateOnly*/ false,
            /*out*/client);

    if(!ret.isOk()) {
        logRejected(id, getCallingPid(), String8(clientPackageName),
                ret.toString8());
        return ret;
    }

    *device = client; //client 指向的类型是 CameraDeviceClient，其实例则是最终的返回结果。
    return ret;
}

　　connectHelper 内容较多，忽略掉我们还无需关注的地方分析：

template<class CALLBACK, class CLIENT>
Status CameraService::connectHelper(const sp<CALLBACK>& cameraCb, const String8& cameraId,
        int halVersion, const String16& clientPackageName, int clientUid, int clientPid,
        apiLevel effectiveApiLevel, bool legacyMode, bool shimUpdateOnly,
        /*out*/sp<CLIENT>& device) {
    binder::Status ret = binder::Status::ok();

    String8 clientName8(clientPackageName);

    /* Do something in */
    ......
    /* Do something out */

        sp<BasicClient> tmp = nullptr;
        //调用 makeClient 生成 CameraDeviceClient 实例。
        if(!(ret = makeClient(this, cameraCb, clientPackageName, cameraId, facing, clientPid,
                clientUid, getpid(), legacyMode, halVersion, deviceVersion, effectiveApiLevel,
                /*out*/&tmp)).isOk()) {
            return ret;
        }
        //初始化 CLIENT 实例。注意此处的模板类型 CLIENT 即是 CameraDeviceClient，传入的参数 mCameraProviderManager 则是与 HAL service 有关。
        client = static_cast<CLIENT*>(tmp.get());

        LOG_ALWAYS_FATAL_IF(client.get() == nullptr, "%s: CameraService in invalid state",
                __FUNCTION__);

        err = client->initialize(mCameraProviderManager);

    /* Do something in */
    ......
    /* Do something out */

    // Important: release the mutex here so the client can call back into the service from its
    // destructor (can be at the end of the call)
    device = client;
    return ret;
}

　　makeClient 主要是根据 API 版本以及 HAL 版本来选择生成具体的 Client 实例，Client 就沿着前面分析下来的路径返回到 CameraDeviceImpl 实例中，被保存到 mRemoteDevice。

Status CameraService::makeClient(const sp<CameraService>& cameraService,
        const sp<IInterface>& cameraCb, const String16& packageName, const String8& cameraId,
        int facing, int clientPid, uid_t clientUid, int servicePid, bool legacyMode,
        int halVersion, int deviceVersion, apiLevel effectiveApiLevel,
        /*out*/sp<BasicClient>* client) {

    if (halVersion < 0 || halVersion == deviceVersion) {
        // Default path: HAL version is unspecified by caller, create CameraClient
        // based on device version reported by the HAL.
        switch(deviceVersion) {
          case CAMERA_DEVICE_API_VERSION_1_0:
            /* Do something in */
            ......
            /* Do something out */
          case CAMERA_DEVICE_API_VERSION_3_0:
          case CAMERA_DEVICE_API_VERSION_3_1:
          case CAMERA_DEVICE_API_VERSION_3_2:
          case CAMERA_DEVICE_API_VERSION_3_3:
          case CAMERA_DEVICE_API_VERSION_3_4:
            if (effectiveApiLevel == API_1) { // Camera1 API route
                sp<ICameraClient> tmp = static_cast<ICameraClient*>(cameraCb.get());
                *client = new Camera2Client(cameraService, tmp, packageName, cameraIdToInt(cameraId),
                        facing, clientPid, clientUid, servicePid, legacyMode);
            } else { // Camera2 API route : 实例化了 CameraDeviceClient 类作为 Client（注意此处构造传入了 ICameraDeviceCallbacks，这是连接到 CameraDeviceImpl 的远端回调）
                sp<hardware::camera2::ICameraDeviceCallbacks> tmp =
                        static_cast<hardware::camera2::ICameraDeviceCallbacks*>(cameraCb.get());
                *client = new CameraDeviceClient(cameraService, tmp, packageName, cameraId,
                        facing, clientPid, clientUid, servicePid);
            }
            break;
          default:
            // Should not be reachable
            ALOGE("Unknown camera device HAL version: %d", deviceVersion);
            return STATUS_ERROR_FMT(ERROR_INVALID_OPERATION,
                    "Camera device \"%s\" has unknown HAL version %d",
                    cameraId.string(), deviceVersion);
        }
    } else {
        /* Do something in */
        ......
        /* Do something out */
    }
    return Status::ok();
}

　　至此，打开相机流程中，从 App 到 CameraService 的调用逻辑基本上就算走完了。

　　简图总结:

　　

　　Ps：

  • CameraManagerGlobal 是真正的实现层，它与 JAVA 层的 CameraService 创建连接，从而创建相机的连路。
  • CameraDeviceImpl 相当于运行上下文，它取代了 Android N 之前的 JNI 层。

　3.从 CameraService 到 HAL Service

　　由于 Android O 中加入了 Treble 机制，CameraServer 一端主体为 CameraService，它将会寻找现存的 Provider service，将其加入到内部的 CameraProviderManager 中进行管理，相关操作都是通过远端调用进行的。
　　而 Provider service 一端的主体为 CameraProvider，它在初始化时就已经连接到 libhardware 的 Camera HAL 实现层，并以 CameraModule 来进行管理。
　　进程的启动后，连路的 “载体” 就搭建完成了（需要注意，此时 QCamera3HWI 还未创建），可用下图简单表示：
　　

　　

　　　而在打开相机时，该层的完整连路会被创建出来，主要调用逻辑如下图：

　　

　　　　上回讲到，在 CameraService::makeClient 中，实例化了一个 CameraDeviceClient。现在我们就从它的构造函数开始，继续探索打开相机的流程。
　　　　这一部分主要活动在 Runtime 层，这里分成 CameraService 与 HAL Service 两侧来分析。

　　（1）CameraDeviceClient ：frameworks\av\services\camera\libcameraservice\api2\CameraDeviceClient.cpp

CameraDeviceClient::CameraDeviceClient(const sp<CameraService>& cameraService,
        const sp<hardware::camera2::ICameraDeviceCallbacks>& remoteCallback,
        const String16& clientPackageName,
        const String8& cameraId,
        int cameraFacing,
        int clientPid,
        uid_t clientUid,
        int servicePid) :
    Camera2ClientBase(cameraService, remoteCallback, clientPackageName,
                cameraId, cameraFacing, clientPid, clientUid, servicePid),  //继承它的父类 Camera2ClientBase
    mInputStream(),
    mStreamingRequestId(REQUEST_ID_NONE),
    mRequestIdCounter(0),
    mPrivilegedClient(false) {

    char value[PROPERTY_VALUE_MAX];
    property_get("persist.camera.privapp.list", value, "");
    String16 packagelist(value);
    if (packagelist.contains(clientPackageName.string())) {
        mPrivilegedClient = true;
    }

    ATRACE_CALL();
    ALOGI("CameraDeviceClient %s: Opened", cameraId.string());
}

　　CameraService 在创建 CameraDeviceClient 之后，会调用它的初始化函数：

//对外提供调用的初始化函数接口 initialize。
status_t CameraDeviceClient::initialize(sp<CameraProviderManager> manager) {
    return initializeImpl(manager);
}

//初始化的具体实现函数，模板 TProviderPtr 在此处即是 CameraProviderManager 类。
template<typename TProviderPtr>
//首先将父类初始化，注意此处传入了 CameraProviderManager。
status_t CameraDeviceClient::initializeImpl(TProviderPtr providerPtr) {
    ATRACE_CALL();
    status_t res;

    res = Camera2ClientBase::initialize(providerPtr);
    if (res != OK) {
        return res;
    }

    //这里是关于 FrameProcessor 的创建与初始化配置等等
    String8 threadName;
    mFrameProcessor = new FrameProcessorBase(mDevice);
    threadName = String8::format("CDU-%s-FrameProc", mCameraIdStr.string());
    mFrameProcessor->run(threadName.string());

    mFrameProcessor->registerListener(FRAME_PROCESSOR_LISTENER_MIN_ID,
                                      FRAME_PROCESSOR_LISTENER_MAX_ID,
                                      /*listener*/this,
                                      /*sendPartials*/true);

    return OK;
}

原文地址：https://www.cnblogs.com/blogs-of-lxl/p/10651611.html

时间： 2024-11-09 19:27:48

Android : Camera2/HAL3 框架分析的相关文章

Android Bitmap 开源图片框架分析（精华三）

主要介绍这三个框架,都挺有名的,其他的框架估计也差不多了 Android-Universal-Image-Loaderhttps://github.com/nostra13/Android-Universal-Image-Loader ImageLoaderhttps://github.com/novoda/ImageLoader Volley(综合框架,包含图片部分)https://github.com/mcxiaoke/android-volley 扯淡时间,可以跳过这段这些开源框架的源码还

Android Bitmap 开源图片框架分析（精华四）

disk缓存主要难点在于内存缓存,disk缓存其实比较简单,就是图片加载完成后把图片文件存到本地方便下次使用 同样,先贴一下官方主页的介绍(主页地址见文章最开始处)和内存缓存差不多,根据算法不同提供了几种类别,可以自行通过ImageLoaderConfiguration.discCache(..)设置<ignore_js_op> 硬盘缓存,保存是以文件的形式框架提供了4种类型,具体算法规则不同,看名字我们大概也能知道对应意思 UnlimitedDiscCache                

Android应用程序框架层和系统运行库层日志系统源代码分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6598703 在开发Android应用程序时,少不了使用Log来监控和调试程序的执行.在上一篇文章Android日志系统驱动程序Logger源代码分析中,我们分析了驱动程序Logger的源代码,在前面的文章浅谈Android系统开发中Log的使用一文,我们也简单介绍在应用程序中使Log的方法,在这篇文章中,我们将详细介绍Android应用程序框架

Android系统中基于Binder的IPC流程框架分析

前言: Activity.Service.BroadcastReceiver.Content Provider是Android的四大应用程序组件,构成一个完整的应用程序的这些组件可以在同一个进程,也可以不在同一个进程,而当这些组件不在同一个进程,需要进行数据交互时就需要一种IPC(Inter-Process Communication)进程间通信机制来完成,而Binder就是提供了IPC功能的一个框架.实现IPC的整个Binder框架包含几个重要组成部分,它们分别是Binder Driver.C

Android Bitmap 开源图片框架分析（精华五）

本帖最后由 boredream 于 2014-5-27 09:07 编辑 ImageLoader和Volley图片部分还包括其他大部分图片框架,基本上图片处理都差不多,区别仅在于部分优化了,而优化方面UIL即Universal-Image-Loader框架做的最好,所以这部分章节算是温习一下图片处理以及寻找下其他框架里面一些不一样的图片处理方式(只关注图片方面) 首先是ImageLoaderhttps://github.com/novoda/ImageLoader主要还是分析图片加载的核心代码部

（转）android平台phonegap框架实现原理

(原文)http://blog.csdn.net/wuruixn/article/details/7405175 android平台phonegap框架实现原理 分类: Android2012-03-28 23:10 2919人阅读 评论(0) 收藏 举报 phonegap平台android框架apiblackberry 最近研究了下phonegap手机快速开发框架原理,重点探究了android平台上的phonegap框架源码,在参考cutesource写的phonegap源码分析后,更加深入理

开源学习--SlideExpandableListView中的列表项动画实现框架分析

前面的话 开源项目Android-SlideExpandableListView是一个简单的介绍列表项动画展示的小型项目,分析这个项目可以对自定义框架及列表类动画实现有个比较清晰的认识,工作中中时常根据需求扩展定义自己的适配器,虽然具体需求不同,但架构类似,本文把最近关于该开源项目的研究心得整理分享,共同学习~ 项目简介 github地址https://github.com/tjerkw/Android-SlideExpandableListView 这是个入门级的列表项动画展示框架,实现效果如

Android tree应用框架

Tomcat源码学习前的准备工作 注:由于网上的帖子大部分没有配套的图片和错误的分析,所有费了半天劲整理了此篇博客,希望大家少走弯路吧 下面我们就开始我们的Tomcat源码学习之旅. 1. 下载Tomcat6.0的源代码 首先,我们得下载Tomcat6.0的源代码.Tomcat源代码的版本控制工具不是CVS,而是Subversion,如果您的机器上没有安装Subversion,请从http://subversion.tigris.org/servlets/ProjectDocumentList?

Android自定义控件一_Canvas分析

自定义控件分为两种一种是自定义ViewGroup控件,一种是自定义View控件:跟踪View的步伐其实能跟到Java实现的最下面我们能发现的也就只有Canvas了,再下去就是C++或C实现了:所以本文主要是站在设计的的角度讲解一下Canvas跟View的关系,再简单分析一下Canvas用法: View作为Android中一切显示视图的父类,我们可看到它的绘制方法draw(Canvas canvas)中,无非也是通过Canvas的绘制来达到各种View的显示,如此Android中各种控件如:Ima