Camera HAL3的整体架构和流程(一)

本文深入解析MTK平台的CameraHAL3架构,包括ICameraProvider,ICameraDevice和ICameraDeviceSession的实现原理,以及Pipeline结构,如P1Node、P2CaptureNode、P2StreamingNode和JPEGNode的功能与作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

本文基于Android P的Camera HAL3架构,以MTK平台为例,分析Camera HAL3的体系结构和调用流程。本文是描述关于MTK平台如何重写Android所定义的ICameraProvider, ICameraDevice, ICameraDeviceSession HIDL interfaces并实现Camera HAL3。

这篇文章只是帮助了解HAL层的结构,不涉及具体的代码。

Camera整体架构

下图是Android Camera的整个架构。

Android Camera 整体结构

首先上层的APK应用通过Activity或Service来调用相机功能,分别获取APIv2中的CameraDevice和CameraManager。翻译成大白话就是获取相机设备和相机管理器,有了相机设备(CameraDevice)才能拍照,而相机管理器(CameraManager)就是用来管理预览,拍照,存储等命令的。

然后怎样才能获得这两个东西呢,通过Binder的方式来获取,图中蓝色部分可以看成客户端,灰色部分也就是图中的CameraService是服务端,他们之间属于进程间通信

最后CameraService再通过HIDL接口调用到HAL(Hardware Abstract Layer)层,HAL继续往下一次是Driver层和HW(HardWare)层,就不赘述了,在获取到该相机设备或管理器后调用Callback接口。

如果你不懂Binder和HIDL是什么,请看HIDL是什么,Binder是什么?

总结一下:APK应用–>CameraAPI2(客户端)–>CameraService(服务端)–>HAL

HAL3的内部架构

大概介绍完了Android Camera的整体结构,接下来是HAL结构的具体内容。

HAL(Hardware Abstract Layer)硬件抽象层,顾名思义,是用来抽象硬件的。HAL是硬件依赖的,不同的 CPU(例如MTK和Qualcomm) 的 HAL 是不同的,但HAL 也有相同的地方,那就是 HAL 的目的——为上层软件提供一致的 API

有了HAL层,上层软件就可以做到硬件无关。应用程序可以直接使用 HAL 提供的 API 来操作硬件,而不用管硬件的上电方式,更新组件等差异问题。

下图是MTK平台的HAL结构。

HAL具体结构

MTK HAL分为MiddlewarePipeline(含HWNode,FeaturePipe)。

Middleware

其中Middleware主要包括一些接口:ICameraProvider,ICameraDevice,ICameraDeviceSession

  • ICameraProvider
    ICameraProvider会枚举可用的Camera Device,并提供有关设备状态更改(例如连接,断开连接等)的更新。ICameraProvider负责生成相机设备服务名称列表,然后可以在以后打开。
  • ICameraDevice
    ICameraDevice是Android框架中的CameraService用来操作相机设备的。 ICameraDevice接口的实例可以通过ICameraProvider :: getCameraDeviceInterface_vN_x()方法获取,其中N是ICameraDevice接口的版本。
  • ICameraDeviceSession
    ICameraDeviceSession翻译过来就是相机设备会话,它由ICameraDevice创建,顾名思义,它的作用是建立相机设备与上层的会话。

总结:
ICameraProvider通过getCameraDeviceInterface_v3_x()来获取ICameraDevice实例,此时还没有对设备进行上电操作,当上层应用获得相机设备实例后,通过ICameraDevice的open函数来对设备进行上电,然后再create一个ICameraSession的实例来让应用操作Device实例。
在这里插入图片描述

Pipeline结构

在这里插入图片描述

Pipeline由PipeModel, HWNode, FeaturePipe组成,其中PipeModel会针对不同的用户场景来创建对应的HWNode,而不同的HWNode又需要不同的FeatureNode来响应。

PipeModel在后续的文章会讲到,应当先了解PipeModel的输入和输出是:

  • input:应用请求
  • output:图像流和原始数据

HWNode负责整合硬件功能,软件算法和第三方算法,其中各个Node的作用如下:

  • P1Node
    它是pipeline的根节点
    输入数据来自上一层
    输出是接下来的P2CaptureNode和P2StreamingNode
    使用ISP-P1

  • P2CaptureNode
    将RAW数据转化为YUV
    支持裁剪
    使用ISP-P2
    处理所有第三方算法(通过CaptureFeaturePipe)

  • P2StreamingNode
    将RAW数据转化为YUV
    支持裁剪
    使用ISP-P2
    处理所用第三方算法(通过StreamingFeaturePipe)

  • JPEGNode
    将YUV转化为JPEG
    输入数据为P2StreamingNode或者P2CaptureNode
    输出数据给应用

下一篇文章是Camera HAL的调用流程,微信公众号将同步更新该系列文章。

在这里插入图片描述

### 安装UIAutomator2驱动器以实现Appium Android自动化 #### 基本设置 为了使UiAutomator2驱动能够在Android设备上运行测试,需满足些前提条件。确保已安装Java Development Kit (JDK),并配置好环境变量;还需下载并配置Android SDK工具以及其内部组件如Platform Tools, Build-tools等[^1]。 #### Emulator Setup 对于模拟器的准备来说,在启动之前要确认已经通过`android sdk manager`安装了必要的系统镜像文件,并利用命令`avdmanager create avd ...`创建虚拟设备实例。另外,建议开启硬件加速来提高性能表现。 #### Real Device Setup 当涉及到真实物理装置时,则应启用开发者选项下的USB调试模式以便于连接电脑端进行操作。同时允许未知来源的应用程序安装权限也是必不可少的个环节。如果打算采用无线方式链接的话,可以考虑借助Docker容器化解决方案——即提到过的`Appium Docker for Android`项目[^3]。 #### 更新Settings能力参数 在会话初始化阶段可以通过传递特定的能力属性给服务器端来自定义行为逻辑。例如调整MJPEG流缩放因子或是控制响应体大小等方面的需求都可以在此处指定相应的键值对组合[^4]。 ```json { "desiredCapabilities": { "platformName": "Android", "deviceName": "emulator-5554", // 或者真实的设备名称 "automationName": "UiAutomator2", "app": "/path/to/your.apk" }, "settings": { "mjpegScalingFactor": 10, "shouldUseCompactResponses": true } } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值