企业官网建设流程全解析

刚转到Camera BSP时，我花了大量时间抱着sensor datasheet啃寄存器，以为只要把i2c读写和上电时序弄对，问题就能解决。结果真正拿到一套MTK平台代码时，整个人是懵的：几十个进程、几百个接口、一堆vendor扩展，连一个“预览黑屏”的问题都不知道该从哪里下手。后来被一位同事点醒——不要急着看驱动，先花一周时间把Android平台的Camera架构吃透。如今回头看，这一步是最值得的投入。

这一篇就把“Android平台架构”这条主线理清楚。面向的读者是准备做或者刚接触MTK平台Camera BSP的开发者，也适合FAE和技术支持同学。我会尽量少讲空泛的概念，多用实际开发和调试中的例子，讲清楚应用层到sensor之间究竟发生了什么，以及我们平时改的驱动、调的3A、配的dts，到底挂在架构的哪个环节上。

1. 为什么BSP工程师要先啃Android架构：先看懂地图再动手

1.1 我踩过的第一个坑：把黑屏问题当sensor驱动问题查

刚开始接触项目时，我遇到过一台设备预览黑屏。第一反应就是看sensor驱动是否有问题：上电时序对不对、mclk有没有、RESET拉的够不够久。查了两天，硬件同事也帮忙量了波形，都没问题。后来偶然打开logcat，发现App层的CameraDevice一直拿不到，整个open流程压根没走到HAL。问题出在上一层：上一个测试进程异常退出，CameraService里的client状态没清理干净，新的client申请被阻塞了。

这个案例给了我一个特别深刻的教训：Camera BSP并不只是“驱动工程师”，我们的工作边界虽然聚焦在底层，但问题现象永远会横跨多个软件层次。如果你连“哪一层该看什么”都不知道，很容易在错误的地方浪费几天时间。

1.2 BSP到底要管哪几块

“BSP”这个词在不同公司定义不太一样，但MTK平台下一般包含这些内容：

• sensor驱动：上电、时钟、i2c配置、寄存器初始化、stream on/off；
• ISP相关配置：RAW图数据通路、pipeline里的各种模块开关；
• 3A效果集成：AE、AF、AWB的算法库和参数加载，以及对应的metadata；
• tuning处理：效果调优，包括亮度、色彩、降噪、HDR等；
• 稳定性问题：闪屏、花屏、卡顿、功耗、异常crash；
• 产线相关：Sensor的OTP读取、eFuse配置、烧录信息校验等。

这些工作各有各的侧重点，但有一个共同点：它们都要和Android上层的Camera框架打交道，都要通过HAL3模型暴露能力，都要在metadata和buffer的流转中完成自己的任务。不懂上层架构，你连“为什么sensor的配置没生效”都解释不清。

1.3 架构思维能带来什么

我认为架构思维对于BSP工程师的核心价值，是建立“调用链意识”。遇到任何bug，你第一反应不是“sensor驱动改了再说”，而是先问：这个现象发生在哪一层？是App没发请求？还是Framework没传下来？是HAL没开pipeline？还是驱动没出图？

一旦能回答这个问题，接下去的排查范围就从“整个系统”缩小到“某个层次的某个模块”。配合log、dump、断点，基本都能快速定位。这也是本系列文章存在的意义——先把地图画清楚，再开始走路。

2. Android Camera架构全景：一条请求从App走到sensor要过几道门

2.1 七个层级一次说清

Android Camera整体可以分成这么几层，从顶层到底层：

1. App层：用户看到的拍照界面，调用Camera2 API；
2. Java Framework层：android.hardware.camera2包下的一系列服务封装；
3. Native Framework层：CameraService，真正的核心调度者；
4. CameraProvider进程：通过HIDL/AIDL接口与CameraService通信；
5. HAL层：厂商实现的Camera HAL，MTK的pipeline就在这一层；
6. 内核驱动层：V4L2框架，sensor驱动、ISP驱动等；
7. 硬件层：实际的光学模组、sensor、ISP芯片。

BSP工程师日常打交道最多的是第5、6、7层，但如果你完全不了解3、4层在做什么，就很容易遇到“上面说没图，下面说出图了”这种互相甩锅的对话。

2.2 核心抽象模型：Request、Stream、Buffer

Android Camera HAL3设计上最核心的几个概念：

• CaptureRequest：一次拍摄请求。里面描述曝光时间、ISO、对焦位置、输出target列表等；
• Stream：输出数据流的描述，包括宽高、格式、使用场景；
• Surface / Buffer：真正存放图像数据的载体，通常是GraphicBuffer。

可以这样理解：你打开相机预览，App创建了若干输出target，然后不断向CameraService发送CaptureRequest。请求到达HAL后，HAL层必须按照请求里的要求，把sensor采集的数据经过ISP处理，再填到你要求的buffer里，并且通过Result metadata把本次拍摄的参数返回给上层。

对BSP人员来说，CaptureRequest就是一份“上层命令书”。很多sensor行为不正常，其实是因为某一个request里的参数设置得不合法。比如预览分辨率要求的格式与sensor输出格式不匹配，HAL会在pipeline入口就直接拒绝，表现为“预览黑屏”。这种问题改驱动是没有用的。

2.3 命令流和图像流是两条通道

理解Camera架构时，很多人会混淆两条数据通路：

• 控制/事件通路：App -> CameraService -> HAL -> Driver，主要用来传递request、result、事件；
• 图像buffer通路：sensor -> ISP -> HAL处理 -> BufferQueue -> App/Display/Encoder。

这两条路相互独立，但又紧密配合。出错时表现也不一样：命令流出问题，通常是open失败、请求超时、3A不收敛；buffer出问题，往往是预览卡顿、花屏、颜色不对、黑屏。排查时先判断是哪条通路，能大幅缩小范围。

2.4 Treble架构带来的进程隔离

Android 8之后引入Treble，Camera HAL跑在独立的CameraProvider进程中，而不像以前那样和CameraService在同一个进程里。好处是框架升级时不需要重新编译厂商代码，代价是HAL和Framework之间多了一层IPC调用。到了Android 13之后，很多平台又从HIDL迁移到AIDL接口。

这件事对BSP直接的影响是：你调试的HAL进程是独立的，crash之后不会拖垮整个系统；但如果某个HIDL/AIDL接口版本对不上，上层和下层就会“通信失败”。常见现象是CameraService能发现Provider，但open设备时返回错误。遇到这类问题，先核对接口版本，比去查sensor驱动有意义得多。

3. MTK平台上架构的代码落点与调试入口

3.1 在MTK代码树里找到坐标

MTK平台的代码通常会放在vendor/mediatek目录下，HAL实现、sensor驱动、tuning相关工具大多都在这里。不同项目、不同Android版本的目录结构会有些差异，但思路是一致的：

• CameraProvider/Device相关代码：负责HIDL/AIDL service的创建，以及HAL Device的open、close、processCaptureRequest；
• HAL pipeline相关代码：负责创建sensor node、ISP node、后处理node，以及buffer的管理；
• sensor驱动相关代码：在kernel侧，通常以i2c设备驱动的方式挂载，通过V4L2 subdev的方式注册；
• tuning相关代码：存放3A参数、效果参数和校准数据。

第一次进到这么大的代码树，不建议从头到尾读。我的方法是：用“调用链”为导向去看，比如从HIDL层的openDevice函数一直跟到driver层，走通一遍主流程，剩下的细节以后再慢慢补。

3.2 Sensor驱动、ISP与3A是怎么挂进架构的

MTK的sensor驱动属于V4L2 subdev框架，有自己的i2c_address、上电时序、寄存器配置表。HAL层通过标准接口来操作它：比如设置sensor模式、设置曝光增益、触发stream on/off。你改sensor驱动时，实际上是在给上层的plumber提供一些固定API去拨动硬件开关。

ISP层的pipeline，负责把sensor输出的RAW数据做各种处理：去噪、坏点校正、白平衡、色彩矩阵、缩放到预期尺寸。3A算法则不断计算曝光、对焦和白平衡参数，通过HAL写回sensor和ISP。

要注意的是，这三者的时钟域差异很大。传感器输出有帧率、曝光行数、竖直blanking；ISP处理有pipeline延迟；3A计算又有自己的周期。哪一环跟不上，画面就可能闪烁或卡顿。BSP的工作很多时候是在调这些“节奏”。

3.3 几个值得练熟的调试入口

• adb shell dumpsys media.camera：查看CameraService状态、当前打开的client、配置的stream、活跃的request；
• logcat：关注ActivityManager、CameraService、CameraProvider、以及MTK自身打印的相关TAG；
• vendor log工具：MTK平台一般有整套log抓取脚本和开关，通常可以抓取HAL层和driver层的详细log；
• dump图像/导出raw：验证pipeline每一级输出是否正常；
• systrace/perfetto：分析帧耗时和buffer走流转。

很多新人容易只看logcat报错，不会用dumpsys。但实际上dumpsys media.camera可以清晰看到“App要了什么格式、HAL给没给、当前有没有在处理request”，是排查黑屏和卡顿的第一神器。

3.4 注意MTK的vendor tag与扩展接口

HAL3里，除了Google定义的标准metadata之外，MTK还扩展了大量vendor tag，用来传递自己特有的参数，比如某些ISP开关、降噪模式、特定的sensor控制项。应用层想用这些能力，要先去查询vendor tag的availability，然后设置到CaptureRequest里。

对BSP来说，vendor tag往往是“上层诉求”和“底层能力”之间的接口。如果你改了一个新功能，比如夜景模式，却没有在vendor tag层暴露出来，App那边怎么调都没用。所以开发时一定要先确认：这个能力是不是已经通过metadata暴露给上层了。

另外，不同版本Android对vendor tag的管控越来越严格，非SDK接口限制也影响到部分应用。设计新的扩展接口时，尽量不要绕过metadata体系去做私有的socket或sysfs，否则后面CTS测试会很痛苦。这一点我在实际项目中深有体会。

4. 我用“架构分层法”定位问题的操作复盘

4.1 入门期我用的三步法

第一步，走通一条完整调用链。拿一台MTK机器，打开logcat，从App启动相机开始，把“open device、配置stream、发送request、sensor stream on、第一帧出图”这一整套打印全部标记一遍，顺手在代码里找到对应的调用位置，形成自己的笔记。

第二步，把画图变成硬习惯。不管用什么工具，一定要把预览和拍照两条链路各画一张时序图。画图的意义不是给别人看，而是逼自己把每一环的“输入、输出、卡点“想清楚。谁前谁后，哪个环节要等待，一眼就能看到。

第三步，带着真实问题去读代码。只看代码不解决问题，很快就会忘掉。我会给自己出几个小场景：预览花屏会查哪几个点？拍照卡顿怎么解？切前后摄crash怎么定位？然后再去看对应层次的代码，效率要高出不少。

4.2 示例排查过程：某项目在1200万分辨率下预览花屏

我抽一个模拟项目X的case来讲，这类问题在MTK平台上还挺常见的。现象很简单：相机预览在默认分辨率下正常，切到最大分辨率后画面花屏，伴随偶发闪绿。

第一步，先看dumpsys media.camera，确认上层请求的stream配置。没有再猜。结果显示App请求的是NV12格式、宽高为最大分辨率。

第二步，看HAL层log，重点看pipeline有没有对这个格式做特殊处理。结果发现最大分辨率下的buffer对齐不符合平台要求，帧尾有几行是乱的。导致ISP从buffer里取出来时，多取了一部分无效数据。

第三步，再查driver层。sensor输出的RAW其实没问题，是平台为了节省内存把buffer的stride对齐设小了。HAL虽然拿到了buffer，但实际填数据时按另一条对齐规则写入，于是尾部数据错位。

最终改的是HAL层分配buffer时的对齐参数，而不是sensor驱动。这个case再次说明：先分层，再动手，否则你大概率会在驱动里反复折腾，浪费时间。

4.3 复盘：这一套判断顺序为什么有效

有效的原因很简单：每一层只要有一步没走完，后面的数据就不可能出现。从上层往下看，可以快速排除“请求是否正确”；从下层往上看，可以确认“硬件是否出图”。中间的任何一步，都可以用log或者dump buffer来验证。这种排查方式不依赖经验猜测，每一步都有证据支持。

对于BSP新人，我特别推荐把这个判断顺序固化成一张纸条贴在屏幕边：App有没有拿到client？Framework有没有成功发request？HAL有没有建立pipeline？sensor有没有出图？逐层往下走，十次有九次不会跑偏。

5. 常见问题速查与避坑清单

5.1 一张可以抄作业的排查表

5.2 最容易带偏思路的两个习惯

第一个习惯是“一上来全局搜索sensor名字”。很多新人在代码里搜到sensor型号就会陷入一堆寄存器配置里，完全忘了问题根源可能在上层。我见过不少case，sensor驱动代码从头到尾没BUG，问题是Allocator给的buffer数量不够导致预览卡住。

第二个习惯是“只抓logcat，不抓vendor log”。MTK平台的HAL层log量非常大，但很多有效信息默认是关闭的，需要主动打开对应模块的log开关。如果只看系统logcat，你会看到问题出现，但看不到链路内部发生了什么，排查基本靠猜。这一点在定位pipeline问题时尤其明显。

5.3 建议大家养成的三个小习惯

第一，拿到新项目第一周，就把这套架构图和代码路径整理成自己的笔记。不用太完美，能让自己快速找到关键入口就行。

第二，每次遇到问题，别急着改代码，先记录“问题现象、涉及层次、排查步骤、最终原因”。三个月后你会发现它是一笔很大的财富。

第三，对接口版本、metadata变更保持敏感。Android框架一年一大版本，HAL接口也在演进。哪怕你现在只改sensor驱动，也要关注接口变化，否则某天上层升级后，你会发现底层逻辑完全对不上。

关于这部分内容，我个人操作时还有个体会：架构学习不是一遍就能完成的，第一遍是“建立轮廓”，第二遍是“代入问题”，第三遍是“形成直觉”。每次回到这套框架，都能看到之前忽略的东西。所以不要着急，顺着地图一点点走，后面再碰ISP pipeline、sensor上电、3A调光的时候，你会发现自己不再是盲人摸象。下一篇我打算接着写MTK平台sensor驱动的点亮流程，把这篇架构讲到的硬件落点再展开。