干车载测试这几年最让人血压升高的瞬间不是测出BUG而是BUG复现了、日志没抓到。中控屏卡死、蓝牙断连、倒车影像黑屏这类问题在整车上往往几十分钟才出现一次错过一轮日志就得再等下一轮复现窗口。所以圈子里有句话日志抓得好下班早日志抓得烂加班到两点。adb logcat看似基础但真正想在车载环境下高效抓取日志并快速定位问题需要的不只是几条命令而是一套从环境准备、抓取策略到问题排查链路的完整思路。这篇文把我这些年实车调试的经验整理出来适合刚转行车载测试的新人也适合在台架和路测现场跟问题死磕的兄弟参考。1. 先把车机当独立系统看车载环境下logcat抓取的三个特殊前提很多人用手机上的经验直接套车机结果第一天就翻车。车机不是手机它是多屏多用户、带整车服务、运行大量vendor进程的Android系统抓log之前必须理解它和手机的本质差异。1.1 车机不是手机系统服务树比想象中更复杂手机里的Android跑的是Launcher App 系统服务而车机上跑的是Launcher App CarService VehicleHal 各种域控制器代理。系统服务的数量比手机多一个量级vendor进程也多得多。这就带来两个直接后果第一logcat里的内容量远大于手机而且大量是你不认识的tag。车机一开机光CarService、VehicleHal、VHAL、EvsCamera、AudioPolicy这类系统级tag就能刷屏更别提厂商自研的xx_hal、xx_service、xx_car等自定义tag。全量抓下来的log体积半小时可能就上GB磁盘压力非常大。第二缓冲区被vendor日志打满几乎是常态。main和system缓冲区是环形的容量有限如果vendor日志一直在高频输出等到真出了问题你再去看logcat关键信息可能早就被冲掉了。所以车载测试里拿到的logcat八成都是幸存者偏差——你以为抓到了现场实际只抓到一堆无关噪声。理解这一点之后抓日志的思维就得转变手机上可以先抓再看车机上必须先设计好抓取策略再动手。抓log前先问自己三个问题这次要定位的功能域是什么这个功能涉及哪个系统服务或vendor进程我需要在哪个缓冲区里找线索想清楚再动手效率完全不一样。1.2 量产态和工程态不同阶段日志抓取权限不一样车载项目通常存在两种软件版本形态工程版本通常带debug属性允许adb root日志权限开放和量产版本user版本adb权限受限很多系统内存读不到。这两个状态下能抓到的日志范围完全不同。工程版本上你可以在adb shell里执行su或adb root能直接读/data/anr、/data/tombstones、/data/system/dropbox这些关键目录也能通过setprop动态调整日志级别。量产版本上adb root基本不可用这些目录没有权限访问甚至设备可能只在售后诊断模式下才开放adb通道。所以接到测试任务时先确认当前车机版本属于哪种状态。一条命令看系统属性adb shell getprop ro.build.type # user / userdebug / eng adb shell getprop ro.debuggable # 1 或 0 adb shell getprop ro.product.device # 确认具体车型/平台如果拿到的是量产版本且权限受限不要硬刚也别直接下结论说日志抓不到。惯用方案是联系厂商在编译开关里打开persist.log.tag.*的日志权限或者在测试车上刷入开放日志的测试版本。这个沟通要提前做不要等到测试当天才发现抓不了日志。1.3 车载日志抓取要先设计后执行建立你自己的作战卡实车测试的复现窗口非常珍贵尤其是偶现问题可能一整天只有一两次复现机会。这时候最忌讳的就是现场临时想命令、现场试参数。我自己习惯维护一张日志抓取作战卡每次测试前花两分钟过一遍待确认项具体内容备注目标功能域蓝牙/导航/倒车影像/空调/网络决定过滤tag范围涉及的进程/服务从进程列表里先捞出来adb shell ps -A需要的缓冲区main / system / events / crash按需组合不要总是-b all复现前置条件冷启动/热启动/特定车速/特定场景尽量清单化时间基准方案录像/拍照记录车机时间错位了就很难对齐存储空间本地磁盘预留logcat全量1小时可能几百MB到1GB这张卡不复杂但能逼着你在操作前把方案过一遍避免到现场手忙脚乱。我也见过不少人用更简单的做法一条adb logcat logcat.txt从头抓到尾问题真出现了再拿日志分析。这种做法偶尔能行但碰到日志量大、缓冲区被冲、需要过滤特定tag的时候基本就是听天由命。2. 从连接开始排查adb到车机的常见屏障与解决手段工具链没准备好后面全是空中楼阁。车载adb连接这一环坑比手机调试多得多单独拎出来说。2.1 adb工具链安装与版本检查adb的安装本身不难Windows下官网下载Platform Tools解压后配置环境变量Linux/Mac下用包管理器装也行。关键是版本。车机上跑的Android版本跨度很大有的平台还是Android 9/10有的已经上了Android 13/14adb版本太老可能没法识别新设备太新也可能和旧设备通信有兼容问题。装完之后第一步永远是adb version确认版本没问题后用USB线连接车机和电脑。车载环境里USB连接有一个很大的特殊点车机上的USB口经常不止一个而且不同USB口的功能不同——有的只支持U盘读取有的才支持adb调试。插错口会一直显示no devices这时候先换个口试别急着怀疑驱动。有个容易忽略的坑很多车机的USB口电压不稳插上之后设备反复在device和offline之间横跳。解决方法是找一个带独立供电的USB Hub把车机到Hub再到电脑的链路稳定下来。2.2 连接异常对症处理unauthorized/offline/no devices下面这张表是我整理的车载adb连接最常见的异常和解决办法基本覆盖了90%的现场情况异常现象常见原因处理手段unauthorized车机端USB调试授权弹窗未确认到车机屏幕上点击允许USB调试勾选始终允许offline驱动异常或USB供电不稳定adb kill-server adb start-server换USB口加独立供电Hubno devices未开开发者模式/USB口不对/线材不支持数据检查车机开发者模式换USB 2.0数据线更换USB口反复连接断开车机端休眠策略或USB口供电不足进入车机设置关闭USB休眠或用网络adb连接正常但logcat无输出日志缓冲区被关或权限受限adb shell getpropunauthorized在手机上很常见在车机上更麻烦尤其某些车机在量产状态下根本没有弹窗界面或者弹窗被系统界面吞掉。这时候可以在电脑上重新发起连接adb kill-server adb start-server adb devices如果车机屏幕还是没反应可以试试在车机端把USB调试关掉再重开触发一次新的授权流程。线材也是一个容易被忽略的变量。USB 3.0的线在部分车机上反而容易出兼容问题手边常备一根短一点的USB 2.0数据线能解决很多奇怪的连接问题。2.3 多设备与车机内部多系统并存时的目标锁定实车台架上电脑上可能同时挂着好几台设备IVI主机、仪表、后排娱乐屏、甚至独立的AVM环视盒子。adb devices会列出多个serial这时候你必须用-s参数指定目标设备adb devices adb -s 192.168.1.100:5555 shell getprop ro.product.device adb -s 具体的serial logcat -v threadtime车机多系统的场景比手机复杂得多。比如有的车上有两个Android系统一个跑中控娱乐一个跑仪表它们是两台独立的设备都通过以太网暴露adb端口。这时候adb connect IP:5555连的是哪个系统要看车机的网络分区设计别搞混了。还有更隐蔽的情况同一台IVI上通过虚拟机/容器技术隔离了多个系统实例adb devices只显示一个设备但内部进程差异巨大。定位问题时先执行一遍adb shell ps -A | grep -E android|com.android.car看看当前连接的到底是哪个世界再动手抓日志。连接稳定之后养成一个习惯先把基础信息抓一份作为后续分析的时间线和环境基线。adb shell getprop getprop_factory.txt adb shell date adb shell uptime adb shell df -hdate和uptime尤其重要后面分析日志时序全靠它们。3. 让logcat按你的思路输出抓取命令的组合用法与过滤技巧adb logcat很多人会用但用得糙。一条命令从头抓到尾是最低效的方式抓回来的文件大、噪声多、关键信息被淹没。真正高效的姿势是理解缓冲区、理解过滤参数、理解落盘策略让logcat为你输出干净但完整的内容。3.1 缓冲区不是只有一个main/system/events/crash先搞清楚一个底层事实logcat读取的是内核日志缓冲区而这个缓冲区分了好几块main应用层日志大部分App的Log.d/w/e输出都在这里system系统服务日志System.out和很多系统进程的日志在这里events事件日志系统关键事件应用启动、崩溃、ANR、Activity切换等crash崩溃日志专门记录应用崩溃的堆栈信息我的抓取经验是涉及应用层问题的看maincrash涉及系统服务蓝牙、音频、CarService的看systemmain涉及系统生命周期事件应用死亡、启动、ANR的必须看events。常用命令# 抓全部缓冲区 adb logcat -b all -v threadtime # 抓指定缓冲区 adb logcat -b main -b system -v threadtime # 只看事件日志 adb logcat -b events -v threadtime-b all最省事但不是所有车机都支持部分定制系统只支持main和system。可以先执行adb logcat -b all -g看看是否报错或者直接逐条-b指定。这里有个很实用的命令adb logcat -g它显示各缓冲区当前分配的大小。低内存车机上main缓冲区可能只有256KB甚至更小稍微一刷就没了。可以用下面的方法把缓冲区调大adb logcat -G 8M-G参数直接设置缓冲区大小实测在很多车机上有效。如果-G被权限拦了就需要在开发者选项或者厂商工程菜单里找日志记录器缓冲区大小手动调到4M或8M。这个动作必须在复现问题之前做否则日志早就被冲掉了。3.2 时间戳、优先级、进程与Tag的四维过滤logcat的过滤维度可以拆成四个时间、级别、进程、标签。每个维度都有对应的参数组合起来才能高效筛出你需要的内容。时间维度和格式# 输出带时间戳推荐threadtime包含线程号 adb logcat -v threadtime # 只取最近的200行后退出适合快速看现场 adb logcat -d -t 200 # 从某个时间点开始持续输出用-T配合绝对时间 adb logcat -T 07-25 10:30:00.000-v threadtime是我在车载测试里用最多的格式既有日期时间又有进程号和线程号拿到崩溃堆栈后顺着线程号能捋出完整调用链。跨天测试时threadtime默认不带年份如果测试跨了年份边界才需要额外注意通常够用。级别过滤# 只看warning级别以上 adb logcat *:W # 只看error级别屏蔽所有其他 adb logcat *:E级别从低到高是V/D/I/W/E/F/S实际排查时我通常先看E和F再根据上下文扩大到W。进程和标签过滤# 按进程号过滤 adb logcat --pid1234 # 按标签组合过滤比如只看蓝牙和音频相关其他全静默 adb logcat -s BluetoothHeadset:I AudioPolicy:E *:S-s是一个高频组合参数它把内部所有tag设成Silent只显式打开你关心的tag。这在车载环境里太实用了——系统里vendor tag太多只有精准打开目标tag日志才会干净到一眼能看出问题。还有个隐藏技巧先用不带过滤的命令抓一段然后把文件拉到电脑上分析比在线过滤更稳妥。原因后面讲。3.3 连续抓取与二次分析的工程习惯先落盘再过滤很多新人喜欢这样操作adb logcat | grep KETWORD直接在终端过滤。这在短时间调试时没问题但有两个致命缺陷第一终端的管道缓冲会丢日志。logcat输出量大grep处理速度跟不上中间的数据会被丢弃你以为没日志其实是丢在管道里了。第二过滤条件一旦设错现场就废了。比如你只过滤了BluetoothHeadset结果真正问题出在audio_hal里日志全被*:S屏蔽了。所以我的习惯永远是两步走第一步全量落盘adb logcat -v threadtime -b all logcat_$(date %Y%m%d_%H%M%S).txt第二步在电脑上二次过滤分析# 找崩溃堆栈 grep -n -E FATAL EXCEPTION|AndroidRuntime|am_crash logcat_*.txt # 找ANR相关 grep -n -E ANR in|am_anr logcat_*.txt # 找指定进程的所有日志C代表上下文前后各5行 grep -n -C 5 btaudio_offload logcat_*.txt # 用awk提取指定时间窗口的内容 awk $2 07-25 10:30:00 $2 07-25 10:35:00 logcat_*.txt全量落盘的好处是任何时候想重新换个角度分析数据都在手上不会被现场过滤条件限制死。车载问题偶发率高同样的日志你可能会翻好几遍每次用不同关键字去搜很多问题的根因就是这么从看似没线索里翻出来的。落盘还有一个容易被忽略的坑Windows下直接adb logcat file.txt重定向PowerShell默认会以UTF-16格式写文件导致文件体积翻倍且部分分析工具解析异常。建议在Windows上用cmd窗口执行或者用adb logcat -v threadtime logcat.txt 21把错误流一起重定向避免终端中文乱码影响分析。4. 从崩溃堆栈到系统服务四个真实车载问题的日志定位链路命令是工具定位才是目的。这一章用我实测遇到过的四类典型问题完整走一遍从现象到根因的日志排查链路。每个问题的处理思路有共性也有各自的特殊情况。4.1 问题定位的通用四步法现象拆解→选定目标→时间线对齐→上下文扩展不管问题多诡异我排查时都强制自己按四步走现象拆解把用户看到的异常翻译成系统层面的现象。比如中控卡了系统层面可能是主进程ANR或SystemUI进程被杀或SurfaceFlinger卡顿翻译不准确后面的日志查找方向全是错的。选定目标根据系统现象决定看哪个缓冲区、哪些tag、哪个进程。这一步需要懂一点系统架构至少知道什么功能归谁管。时间线对齐拿到测试现场记录的复现时间点建议精确到秒在日志里把时间窗口前后1到2分钟的内容全部拉出来看。不要只看异常崩溃那一行崩溃前的几十行往往才是真正的诱因。上下文扩展找到可疑点之后扩大范围找相关tag的日志比如看到蓝牙断连就把同时间的bt_btif、BluetoothHeadset、AudioPolicy、Binder相关日志全部捞出来横向看才能还原完整链路。四步法是骨架下面几个案例往里填肉。4.2 车载应用ANR导致中控卡死的定位现象用户报告中控屏幕操作后无响应转圈圈过一会儿弹XX应用无响应。第一步现象拆解。这几乎可以确定是主线程超时ANR可能是应用主线程在做耗时操作也可能是Binder调用等待系统服务超时。车机上第二种情况非常多因为车载系统服务链路长、跨进程多。第二步选定目标。先找到ANR相关的日志# 事件日志里的ANR记录 adb logcat -b events | grep am_anr # 主日志里的ANR关键字 adb logcat -d -v threadtime | grep -E ANR in|am_anrevents缓冲区里的am_anr事件会直接给出哪个进程ANR了以及CPU负载、等待原因的关键信息非常开门见山。第三步时间线对齐。拿到ANR时间点后用grep -C 20把前后日志全部拉出来grep -n -C 20 ANR in com.xxx.launcher logcat_full.txt通常这里能看到卡住的具体原因比如主线程在等待CarService的某个Binder调用返回而CarService侧卡在VehicleHal的同步调用上。第四步上下文扩展。车机上ANR和手机有一个显著不同手机ANR多半是应用自身问题了车机ANR常常是系统服务雪崩导致的。比如多个应用同时等待蓝牙服务返回蓝牙服务卡死导致导航、音乐、电话全都无响应。所以ANR问题不要局限在一个进程里看拉到全局日志里看系统服务整体健康状况才能找到真正根因。如果怀疑有系统服务卡死还需要一条命令adb shell dumpsys activity service com.android.cardumpsys会显示服务的binder线程池、调用栈、pending调用结合logcat里的ANR堆栈基本能锁定卡在哪个服务调用上。4.3 蓝牙断连问题从tag过滤到协议栈细节现象测试中手机连接车机蓝牙播放音乐偶尔出现音乐中断、连接掉线有时自动重连成功有时必须手动重连。第一步现象拆解。蓝牙断连涉及蓝牙协议栈、音频通路、电源管理三个可能方向。音乐中断可能是A2DP链路问题也可能是音频通路切换导致。第二步选定目标。蓝牙日志在logcat里由多个tag共同组成常见的有BluetoothHeadset蓝牙电话/音频连接管理、bt_btif蓝牙协议栈接口层、btif_avA2DP/AVRCP传输、AudioPolicyManager音频策略。因为涉及系统服务重点看system缓冲区。抓取命令adb logcat -b system -v threadtime | grep -E BluetoothHeadset|bt_btif|btif_av|AudioPolicy生产环境里tag命名会因厂商定制有差异更稳妥的做法是全量落盘后在PC上统一过滤grep -n -E bluetooth|bluetooth_a2dp|audio_a2dp|btif_av logcat_full.txt | grep -i -E disconnect|close|error|timeout|hung第三步时间线对齐。在日志里找到断连时间点往前看几秒钟重点看有没有底层报错或者远端设备断开事件。第四步上下文扩展。这类问题的难点在于断连的诱因常常出现在断连前很久。比如蓝牙底层的射频问题、与Wi-Fi的2.4G互相干扰、电源管理在低功耗状态下切断了蓝牙供电。这些内容不会直接出现在logcat里需要你看到断连的代码路径后再去确认外部环境因素。日志里如果出现btif_av相关的A2DP_DISCONNECT或协议栈错误码可以进一步抓蓝牙服务的实时状态adb shell dumpsys bluetooth_manager adb shell dumpsys audio | grep -A 20 A2DP蓝牙问题在车载里经常是日志上只看到断连结果看不到诱因这时候不要死磕logcat把测试现场的录像、车外的干扰源、当时的电源状态一起对齐往往能拼出完整图景。4.4 倒车影像黑屏/延迟的排查组合拳现象挂R挡后中控倒车影像偶尔黑屏有时延迟2秒才出画面。第一步现象拆解。倒车影像链路是摄像头→视频输入→AVM/解码器→Android Surface显示跨了硬件和软件两个域。黑屏可能出在视频源端也可能出在显示合成端。logcat里经常查不到直接的错误信息因为链路里很多环节不在Android系统内。第二步选定目标。先看Android显示相关的日志和状态# 查看SurfaceFlinger的layer列表确认倒车影像的surface是否存在 adb shell dumpsys SurfaceFlinger | grep -i svc|rear|avm|camera # 查看媒体和相机服务状态 adb shell dumpsys media.camera第三步时间线对齐。在logcat里找对应时间点的SurfaceFlinger、HWComposer、CameraProvider相关日志确认surface是否有创建和更新。第四步上下文扩展。这个问题是典型的跨域难点。Android侧一切正常但画面出不来很可能问题出在MCU或独立视频处理器上。这时候logcat能提供的信息有限你需要看/data/tombstones里有没有视频相关native crash看内核日志dmesg里摄像头驱动、ISP相关报错联调MCU日志确认硬件侧是否真的输出了视频流adb shell dmesg | grep -i -E camera|isp|mipi|error经验之谈倒车影像类问题不要一上来就死磕logcat先把Android显示链路是否正常确认掉把脏水泼回硬件侧之前要有日志证据。最烦的情况是Android侧正常、硬件侧也正常最后发现是视频延迟参数配置问题——这种就只能靠时间线对齐来发现录像上画面出现的秒数精确对比才有说服力。4.5 偶发CarService崩溃导致空调/车控失效现象测试车控功能空调调节、座椅调节时偶发整个车控界面无响应重启车机后恢复。第一步现象拆解。车控功能由CarService统一管理上层App通过接口调用底层由VehicleHal与CAN总线通信。功能整体失效指向CarService进程异常大概率是崩溃或看门狗超时。第二步选定目标。先看崩溃日志# 查看Java层崩溃 adb logcat -d -v threadtime | grep -E FATAL EXCEPTION|AndroidRuntime # 查看事件日志里的进程死亡事件 adb logcat -b events | grep -E am_crash|am_proc_diedam_crash事件会直接告诉你CarService通常进程名是com.android.car由于什么异常崩溃了。典型的崩溃堆栈会显示在FATAL EXCEPTION后面。第三步时间线对齐。找到崩溃时间点后往前翻重点看崩溃前是否有系统服务间的相互等待、Binder调用超时、或者底层HAL返回异常值的日志grep -n -C 10 FATAL EXCEPTION logcat_full.txt grep -n -C 5 com.android.car logcat_full.txt | grep -i -E error|timeout|null|exception第四步上下文扩展。车载环境里CarService崩溃有一个很常见的模式底层一个传感器/执行器返回了非法值比如电压超范围、CAN消息超时VehicleHal把异常上传CarService里某个属性回调没做空值保护NPE直接崩溃。所以看到崩溃堆栈之后不要只看Java层的抛错行反手回查HAL层当时的属性上报情况grep -n -E vehicle.hal|VehicleHal|PropertyId|errorCode logcat_full.txt这类问题复现率不高日志里通常只有一次崩溃记录所以要把握住那几行关键堆栈。这也是为什么我一直强调全量落盘——如果当时只过滤了某个tag崩溃堆栈大概率就被漏掉了。5. 进阶姿势和logcat配合使用的其他日志源与抓取脚本logcat是主角但不是唯一的主角。车机问题很多是系统级甚至硬件级的单靠logcat会走进死胡同。这一章把logcat周边的日志源梳理一遍再给一个能直接用的抓取脚本方案。5.1 logcat之外必须掌握的四个日志源内核日志dmesg/ pstorelogcat管的是Android用户态dmesg管的是内核态。驱动崩溃、硬件访问失败、休眠唤醒异常、存储错误全在dmesg里。# Android shell里执行 adb shell dmesg # 上一次重启的原因和崩溃现场 adb shell cat /sys/fs/pstore/console-ramoops adb shell cat /proc/last_kmsg # 部分平台支持这里要特别提醒量产车机上dmesg可能需要root权限没有权限时可以在bugreport里附带内核日志或者请厂商在测试版里打开权限。车载环境里pstore里那个console-ramoops别看名字绕口它记录的是上一次系统重启前的内核日志车机偶发重启的问题全靠它定位。tombstone和dropbox/data/tombstones目录存的是native崩溃的现场比如Camera HAL、SurfaceFlinger这些C进程崩溃后堆栈信息都在这里。/data/system/dropbox目录存的是系统级别的异常事件包括应用崩溃、ANR、watchdog超时。adb shell ls -lt /data/tombstones/ adb shell cat /data/tombstones/tombstone_00 adb shell ls -lt /data/system/dropbox/ adb shell cat /data/system/dropbox/system_app_crash*.txt需要root权限才能访问这些目录在userdebug版本上可以用adb root再操作。这两个目录是logcat的重要补充因为logcat只记录日志输出不记录完整的内存堆栈而tombstone是进程死亡那一刻的内存快照分析native崩溃必须看它。event log再强调一次events缓冲区很多人不重视但它记录了Android系统的关键生命周期事件包括进程启动、死亡、ANR、Activity切换、Binder调用等。用下面的方式一眼扫出问题adb logcat -b events | grep -E am_anr|am_crash|am_proc_died|am_kill这条命令在日常回归测试里特别好用比一条条翻main日志快太多。我每次跑完一轮测试第一件事就是拿event log扫一遍看有没有进程在被系统悄悄杀掉——很多界面突然卡一下的偶发问题真相就是后台进程被杀后重新创建的瞬间。车载特有的MCU层日志提醒如果问题在logcat、dmesg、tombstone里都找不到任何线索但故障确实存在这时候要考虑问题可能出在MCU或者独立功能域控制器上。比如车窗升降失灵、某些CAN信号异常Android系统只是收到一个上层结果真正的逻辑跑在MCU里。MCU日志通常需要用CAN工具或者硬件调试器抓logcat完全接触不到。车载测试工程师如果只懂Android日志分析遇到这种问题会卡很久至少要知道日志不在logcat里这个可能性。5.2 一条命令打包全量现场bugreportadb bugreport是把车机整机状态打包成zip的最快方式里面包含了logcat全量、dumpsys各服务状态、event log、ANR记录、部分dropbox文件等几乎所有允许导出的系统信息。adb bugreport bugreport_$(date %Y%m%d_%H%M%S).zipbugreport生成的zip包里有大量文本主要有FS/data/logs/或类似目录下的日志文件dumpsys结果包含SurfaceFlinger、activity、audio、bluetooth等服务状态anr目录下的ANR tracebugreport-*.txt汇总文件bugreport的缺点也很明显生成时间长可能几分钟、文件体积大数百MB、信息过于庞杂。它不是日常抓log的首选而是问题已经发生了需要给研发打包全量现场时的终极大招。更适合偶现问题的初步信息收集研发拿到手先做全局判断再决定深入查哪个方向。5.3 一键抓取脚本把流程固化成团队习惯每个团队都应该有一套标准化抓取脚本而不是让每个测试员在现场敲命令凭手感。下面这个脚本是我在Linux/Mac环境下常用的结构#!/bin/bash # usage: ./grab_logs.sh [serial] [output_dir] SERIAL${1:-local} OUTDIR${2:-logs_$(date %Y%m%d_%H%M%S)} mkdir -p $OUTDIR echo [1/4] Snapshot basic info... adb -s $SERIAL shell getprop $OUTDIR/getprop.txt adb -s $SERIAL shell date $OUTDIR/device_time.txt adb -s $SERIAL shell uptime $OUTDIR/uptime.txt echo [2/4] Grabbing logcat (all buffers)... adb -s $SERIAL logcat -v threadtime -b all $OUTDIR/logcat.txt LOGCAT_PID$! echo [3/4] Grabbing kernel log... adb -s $SERIAL shell dmesg $OUTDIR/dmesg.txt echo [4/4] Waiting logcat capture. Press CtrlC to stop. wait $LOGCAT_PID echo Logs saved to: $OUTDIRWindows下PowerShell版本思路一致注意重定向编码问题$serial xxx $outDir logs_$(Get-Date -Format yyyyMMdd_HHmmss) New-Item -ItemType Directory -Path $outDir | Out-Null adb -s $serial shell getprop | Out-File $outDir\getprop.txt -Encoding utf8 adb -s $serial logcat -v threadtime -b all | Out-File $outDir\logcat.txt -Encoding utf8脚本化之后新人也能快速上手团队内部复现问题的效率明显提升。我在实际项目里还会在脚本里加一步录像时间校准开始抓日志的同时拍一张车机屏幕显示当前时钟的照片这样后续做跨日志时间线对齐时有个硬基准。6. 长时路测与耐久测试日志轮转与分段的工程化方案一个问题如果只在路测时偶现一次那抓日志的窗口就是几十秒。但车载测试里还有大量长时耐久场景比如连续跑8小时路测、高温环境静置测试、充电循环测试。这种场景下日志抓取的难点完全不同不是怕抓不到而是怕日志太大把磁盘撑爆、连接中断后数据全丢。6.1 长时抓取的最大风险文件膨胀与连接中断全量logcat在车机上的输出速度很惊人实际测下来一小时几百MB很正常全天路测轻松上GB。直接把输出重定向到一个文件会有两个问题第一磁盘写满。测试电脑的可用空间是有限的一旦写满日志停止、测试也受影响。第二单文件过大分析时打开都费劲grep一遍要等半天。更麻烦的是连接中断。车辆在路测中会经过各种环境USB连接可能出现瞬时断开adb logcat进程直接退出前面抓的日志全部作废。网络adb也一样车机Wi-Fi/以太网在移动过程中不稳定断连后即便重连中间那段日志已经是空白。所以长时路测的抓取策略核心是两条分段落盘、自动恢复。6.2 基于PC端的日志轮转方案分段落盘与自动重连一个简单可行的思路是循环超时控制。用timeout命令控制每次logcat抓取时长抓够一段时间后主动断开重新连接再抓下一段#!/bin/bash # 每5分钟切一段日志循环重连 SERIALxxx OUTDIRlogs_$(date %Y%m%d_%H%M%S) mkdir -p $OUTDIR SEGMENT0 while true; do echo [$(date %H:%M:%S)] Segment $SEGMENT start... timeout 300 adb -s $SERIAL logcat -v threadtime -b all $OUTDIR/logcat_$(date %H%M%S).txt echo [$(date %H:%M:%S)] Segment $SEGMENT done, reconnect... adb reconnect sleep 2 SEGMENT$((SEGMENT1)) done每个段之间会有几秒的日志缝隙路测场景下通常可以接受。如果需要无缝衔接可以在重连后用-T参数从上个段最后的时间点回溯抓取但-T对时间格式要求高且部分系统解析不可靠我实际项目里多数是接受这个缝隙用录像补。分段文件的好处是后续分析方便直接用文件名定位时间段# 查看某个小时段的日志 grep -n -C 10 BT disconnect logcat_143500.txt6.3 保证时间线可对齐的小技巧时间基准统一长时测试里不同日志源的时间戳可能各自为政logcat用Android系统时间dmesg用内核时间通常是启动后的相对秒数视频录像用拍摄设备时间CAN日志用测试工具时间。如果不在测试开始前统一时间基准事后对齐就是一场灾难。我的做法是测试开始前做三件事校准车机时间adb shell date查看当前时间与测试电脑/录像设备对表必要时用adb shell date MMDDhhmm[[yy]ss]校准。录像设备拍摄车机时钟测试开始时用录像/拍照设备对着车机主界面拍3秒把车机显示时间录进去。记录测试脚本的启动时间在抓取脚本里输出一行日志包含device_time.txt和本地时间。这样事后无论是拿logcat和录像对齐还是拿dmesg和CAN日志对齐都有一个可靠的时间锚点。还有一个容易忽视的细节车机如果发生重启Android时间可能跳变。测试前先把auto_time关掉或者确认车机时间源可靠否则日志里前后时间戳对不上很容易误判。我踩过一次坑车机重启后自动同步了网络时间日志里出现了时间倒退整个时间线全乱了最后还是靠录像才把时间轴拼回去。长时路测结束后日志分析也同样遵循前面的原则先看events缓冲区扫关键事件再根据异常时间点到对应分段文件里做精细分析。分段文件多的时候批量处理比逐个打开高效得多# 跨所有分段文件搜异常 grep -l FATAL EXCEPTION logs_20250725/*.txt grep -n -C 5 am_anr logs_20250725/*.txt | head -50所有这些技巧最终都指向同一个目标在问题出现的那一刻手上有完整、可分析、可对齐的日志。车载测试的日志工作本质上不是记录而是为事后还原现场做准备。现场还原度越高问题定位越快测试周期就越短。最后再分享一个个人习惯。我每次路测前都会在车库里先做一次15分钟的试抓专门验证三件事adb连接稳定性、磁盘写入速度、日志分段脚本是否正常。这15分钟花得很值因为它避免了我半夜在现场对着一个断开连接的终端干瞪眼。也建议你把这些流程做成团队的标准操作文档新人来了照做就能上手不用每个人重新踩一遍坑。