很多Camera开发者遇到辣手问题第一反应是"提个Case给原厂"，但提的Case质量参差不齐——有的半天就拿到解决方案，有的来回沟通两周还卡着。差别在哪？可能在于你提交的Case是否"一次到位"。
一、提Case前：先自己排查
在提Case之前，先回答自己几个问题：
- ❓ 问题能稳定复现吗？——如果只是偶发一次，原厂也很难分析
- ❓ 日志采集完整吗？——只有一句"Camera打不开"是不够的
- ❓ 自己排查到哪一步了？——展示你的排查过程，原厂会更重视
- ❓ 是平台Bug还是集成问题？——有些"Bug"其实是自己改出来的
核心原则：Case的初始信息越完整，解决速度越快。原厂工程师拿到一个"描述清晰+日志完整+复现路径明确"的Case，可能半天就能定位；而一个"问题描述模糊+日志残缺"的Case，可能来回沟通5轮都还在确认问题现象。
二、日志采集清单
提Case必须附带的日志和信息，按优先级排列：
2.1 必须采集（P0级）
| | |
|---|
| adb logcat -b all > full_log.txt | |
| adb shell dmesg > dmesg.txt | |
| 开启overrideLogLevels+GroupMask | |
| | |
| | |
2.2 建议采集（P1级）
2.3 Camx日志采集命令
# 1. 开启Camx全量日志
adb shell "setprop vendor.debug.camera.overrideLogLevels 0x3F"
adb shell "setprop vendor.debug.camera.overrideLogGroup 0xFFFFFFFF"
# 2. 复现问题前的准备
adb shell "setprop vendor.debug.camera.loglevel 3"
# 3. 开始抓取日志（清空旧日志后开始）
adb logcat -c
adb logcat -b all > full_camera_log.txt &
# 4. 复现问题
# 5. 复现后立即停止抓取
# Ctrl+C 停止logcat
# 6. 采集dmesg
adb shell dmesg > dmesg.txt
# 7. 采集tombstone
adb shell ls -la /data/tombstones/
adb pull /data/tombstones/ ./tombstones/三、Case描述模板
一个好的Case描述，应该让原厂工程师不看日志就能理解问题。推荐使用以下模板：
# Case描述模板
## 问题概述
[一句话描述问题现象]
例如：打开后摄预览后3秒，Camera HAL Crash，日志显示ISP Overflow
## 复现步骤
1. [第一步操作]
2. [第二步操作]
3. [问题出现]
例如：
1. 打开Camera App，切换到后摄
2. 预览正常显示约3秒
3. 切换到夜景模式
4. Camera HAL Crash
## 复现概率
[必现/偶发（概率X/X）]
## 影响范围
[影响哪些场景、哪些Sensor、哪些模式]
## 自己的排查过程
1. 检查了XX日志，发现XX
2. 尝试了XX方法，结果XX
3. 初步定位到XX模块
## 环境信息
- 平台：[高通平台型号]
- Android版本：[如 Android 14]
- Camera版本：[Camx版本号]
- 相关Sensor：[sensor型号]
- 是否有定制修改：[是/否，如是有哪些]
## 附件清单
- [x] 完整logcat日志
- [x] dmesg日志
- [x] Tombstone文件
- [x] Camx配置文件
- [ ] Systrace（如有）四、Case分类与优先级
不同类型的Case，处理策略也不同：
| | | |
|---|
| | | |
| | | |
| | | |
| | | Image Dump + 截图 + Tuning参数 |
| | | |
| | | |
五、常见Case类型与排查重点
5.1 Camera打不开
这是最常见的Blocker级别Case。排查重点：
# 检查Camera服务是否正常启动
adb shell dumpsys media.camera_provider
# 检查Camera HAL是否注册成功
adb shell ls -la /vendor/lib64/hw/camera.qcom.so
adb shell lsof | grep camera
# 检查Sensor是否被识别
adb shell cat /proc/device-tree/model
adb shell "dmesg | grep -i sensor"
# 检查权限
adb shell ls -la /dev/video*
adb shell ls -la /dev/media*关键日志关键词：camera_open、acquire_device、probe、power_on
5.2 预览黑屏/花屏
排查重点：
# 检查数据流是否正常
adb shell "logcat | grep -E 'SOF|EOF|buffer_done|buf_done'"
# 检查ISP是否正常工作
adb shell "logcat | grep -E 'IFE|VFE|overflow|error'"
# 检查Sensor配置
adb shell "logcat | grep -E 'sensor_config|stream_config|exposure'"
# 开启Image Dump查看画面
adb shell "setprop vendor.debug.camera.dump 1"5.3 Camera卡顿/掉帧
# 抓取Systrace
adb shell atrace --async_start -b 8192 -c -t 10 camera gfx
# 检查帧率
adb shell "logcat | grep -E 'frame_id|SOF|fps|skip'"
# 检查CRM请求管理
adb shell "echo 0x10 > /sys/module/cam_debug_util/parameters/debug_mdl"
adb shell "logcat | grep -E 'cam_req_mgr|skip_frame|not_ready'"六、Case沟通技巧
提了Case之后，跟原厂的沟通效率同样关键：
6.1 响应及时
6.2 信息对齐
- 验证Patch后，提供验证结果 + 验证方法 + 验证日志
6.3 升级机制
如果Case长时间没进展，可以通过以下方式升级：
- P0/P1级别Case超过响应时间 → 联系对接FAE升级
- 来回沟通3轮以上仍未定位 → 申请原厂工程师电话会议
七、Case状态流转
重要：Waiting on Customer状态下如果超过7天不回复，Case会被自动关闭。需要重新打开的话又要走一遍流程，浪费时间。
八、提Case检查清单
提交Case前，对照检查：
# 提Case前检查清单
[ ] 问题描述清晰（一句话+详细步骤）
[ ] 复现步骤可稳定复现（或注明概率）
[ ] 完整logcat日志（从打开Camera到问题出现）
[ ] dmesg日志
[ ] Tombstone文件（如有Crash）
[ ] Camx详细日志（GroupMask已开启）
[ ] 环境信息完整（平台+版本+Sensor+配置）
[ ] 自己的排查过程已说明
[ ] 影响范围已说明
[ ] Case优先级标注正确小结
提Case看似简单，但Case质量直接决定了解决速度。总结成一句话：描述清晰、日志完整、排查到位、响应及时。
在实际工作中，一个高质量的Case可能半天就拿到Patch，而一个低质量的Case可能来回两周还在确认"这个问题到底怎么复现"。把时间花在Case准备上，远比来回沟通更高效。
更多Camera开发实战内容
欢迎加入知识星球「小驰成长圈」
120+ Camera工程师 · 340+ 实战内容 · 已运营1565天
微信扫码 · 加入星球
评论 (0)