很多Camera开发者遇到辣手问题第一反应是提个Case给原厂但提的Case质量参差不齐——有的半天就拿到解决方案有的来回沟通两周还卡着。差别在哪可能在于你提交的Case是否一次到位。一、提Case前先自己排查在提Case之前先回答自己几个问题❓问题能稳定复现吗——如果只是偶发一次原厂也很难分析❓日志采集完整吗——只有一句Camera打不开是不够的❓自己排查到哪一步了——展示你的排查过程原厂会更重视❓是平台Bug还是集成问题——有些Bug其实是自己改出来的核心原则Case的初始信息越完整解决速度越快。原厂工程师拿到一个描述清晰日志完整复现路径明确的Case可能半天就能定位而一个问题描述模糊日志残缺的Case可能来回沟通5轮都还在确认问题现象。二、日志采集清单提Case必须附带的日志和信息按优先级排列2.1 必须采集P0级日志类型采集方式用途完整logcatadb logcat -b all full_log.txt应用层HAL层日志Kernel日志adb shell dmesg dmesg.txtKMD驱动层日志Camx详细日志开启overrideLogLevelsGroupMaskPipeline/Node级别日志Tombstone/data/tombstones/Crash堆栈信息设备信息平台型号Android版本Build号环境定位2.2 建议采集P1级日志类型采集方式用途Systrace/Perfetto抓取Camera期间的trace性能/时序问题分析Image Dump开启Image Dump配置画面异常问题分析Camera配置XML导出当前Camera配置配置参数分析dmesg ramdumpKernel Panic时采集底层Crash分析2.3 Camx日志采集命令# 1. 开启Camx全量日志adb shell setprop vendor.debug.camera.overrideLogLevels 0x3Fadb shell setprop vendor.debug.camera.overrideLogGroup 0xFFFFFFFF# 2. 复现问题前的准备adb shell setprop vendor.debug.camera.loglevel 3# 3. 开始抓取日志清空旧日志后开始adb logcat -cadb logcat -b all full_camera_log.txt # 4. 复现问题# 5. 复现后立即停止抓取# CtrlC 停止logcat# 6. 采集dmesgadb shell dmesg dmesg.txt# 7. 采集tombstoneadb 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日志发现XX2. 尝试了XX方法结果XX3. 初步定位到XX模块## 环境信息- 平台[高通平台型号]- Android版本[如 Android 14]- Camera版本[Camx版本号]- 相关Sensor[sensor型号]- 是否有定制修改[是/否如是有哪些]## 附件清单- [x] 完整logcat日志- [x] dmesg日志- [x] Tombstone文件- [x] Camx配置文件- [ ] Systrace如有四、Case分类与优先级不同类型的Case处理策略也不同Case类型优先级预期响应时间重点信息Blocker阻塞开发P024小时影响进度必须提供复现路径Crash必现崩溃P12-3工作日Tombstone 完整日志偶发CrashP25工作日多次复现的日志 复现条件画质问题P25工作日Image Dump 截图 Tuning参数性能问题P31-2周Systrace 性能数据对比功能咨询P31-2周清晰的问题描述五、常见Case类型与排查重点5.1 Camera打不开这是最常见的Blocker级别Case。排查重点# 检查Camera服务是否正常启动adb shell dumpsys media.camera_provider# 检查Camera HAL是否注册成功adb shell ls -la /vendor/lib64/hw/camera.qcom.soadb shell lsof | grep camera# 检查Sensor是否被识别adb shell cat /proc/device-tree/modeladb shell dmesg | grep -i sensor# 检查权限adb shell ls -la /dev/video*adb shell ls -la /dev/media*关键日志关键词camera_open、acquire_device、probe、power_on5.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 15.3 Camera卡顿/掉帧# 抓取Systraceadb 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_mdladb shell logcat | grep -E cam_req_mgr|skip_frame|not_ready六、Case沟通技巧提了Case之后跟原厂的沟通效率同样关键6.1 响应及时原厂回复后24小时内回应否则Case可能被降级需要补充信息时一次性提供完整不要挤牙膏原厂提供Patch后尽快验证并反馈结果6.2 信息对齐每次回复都带上Case编号和问题摘要提供新的日志时说明这是做了XX操作后采集的验证Patch后提供验证结果验证方法验证日志6.3 升级机制如果Case长时间没进展可以通过以下方式升级P0/P1级别Case超过响应时间 → 联系对接FAE升级来回沟通3轮以上仍未定位 → 申请原厂工程师电话会议影响项目交付节点 → 通过商务渠道升级七、Case状态流转状态含义你的动作OpenCase已提交等待原厂分派工程师In Progress原厂分析中及时补充信息Waiting on Customer等你的回复尽快响应超时会自动关闭Patch Provided原厂给了修复补丁尽快验证并反馈结果ClosedCase已关闭确认问题已解决重要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天微信扫码 · 加入星球