日志搜索关键词：

Crash,FATAL,AEE_EXP,aborting,reason,bootstat,reboot,shutdown,died,AndroidRuntime

---------------------------------------

android shell dmesg > kernel_exeption.txt 与 Mtk的debuglogger中的kernel 日志区别：
两者都可以抓取 kernel日志，但前者 buffer有限，不能抓取前面的日志，但 debuglogger中的kernel 就不存在此问题。

Reboot rootcause

1.JE on the system process

   search keywords “FATAL EXCEPTION IN SYSTEM PROCESS:”in main_log

2.NE on the system process

   search keywords “Fatal signal”in main_log

3.SWT on the system process

   Search keywords “WATCHDOG KILLING SYSTEM PROCESS”in main_log

4.KE occurs

   Search keywords “Kernel panic”in kernel_log

Backtrace 

Backtrace 又分成Java backtrace，Native Backtrace，Kernel Backtrace。它是分析死机的非常重要的手段，借助Backtrace，我们可以快速的知道，对应的process/thread在当时正在执行哪些动作，卡住哪里等。可以非常直观的分析死机现场。

1 Java Backtrace抓取的方式

一般进程出现无响应的问题，Android系统会发送SIGQUIT（3）信号给该进程，收到这个信号会，进程会将当前的调用栈打印在trace.txt文件里。

手动抓取进程的Backtrace方法如下：

adb shell kill -3 pid

adb pull /data/anr

2 Native Backtrace 抓取方式

  Natice层的进程发生异常后一般都在/data/tombstones目录下生成文件（墓碑文件），该文件描述了该进程当前的Backtrace，不过是链接地址，需要进行解析。

  addr2line等 tool 来解析抓回的Native Backtrace，从而知道当时正在执行的native代码，

  arm-linux-androideabi-addr2line-f -C -e symbols address

     各种场景抓log

[1]   Preloader & LK阶段（没有logo或卡在logo界面）开机log

未进入 android状态，抓取uart log

[2]   Kernel阶段（有logo或开机动画)开机log

抓取uart log  或是android shell dmesg 

[2]   Android阶段（有开机动画）开机log

Adbd进程起来后，可以使用GAT抓取开机log（录制前先关机）。

若mtklogger可用，可以通过设置mobile log开机自启动录制开机log。

停止录制状态下mtklogger->settings->mobile log->start automticaly

若TP无法使用，可以参考FAQ06939使用adb命令控制mtklogger录制。

[2]   user 版本抓开机向导前LOG或者不开机log

编译一版eng版本对应软件，做如下修改：

alps/system/core/rootdir/init.rc

on property:ro.debuggable=1

    # Give writes to anyone for the trace folder on debug builds.

    # The folder is used to store method traces.

    chmod 0773 /data/misc/trace

    start console

//add begin

on property:ro.debuggable=0

    # Give writes to anyone for the trace folder on debug builds.

    # The folder is used to store method traces.

    chmod 0773 /data/misc/trace

    start console

setprop persist.sys.usb.config mass_storage,adb //add end

alps/kernel-3.18/drivers/misc/mediatek/mtprof/bootprof.c

#ifdef CONFIG_MT_PRINTK_UART_CONSOLE

    //mt_disable_uart();

#endif

alps/build/make/core/main.mk

ifeq (true,$(strip $(enable_target_debugging)))  # Target is more debuggable and adbd is on by default

  ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1  # Enable Dalvik lock contention logging.

  ADDITIONAL_BUILD_PROPERTIES += dalvik.vm.lockprof.threshold=500   # Include the debugging/testing OTA keys in this build.

  INCLUDE_TEST_OTA_KEYS := true

else # !enable_target_debugging

  # Target is less debuggable and adbd is off by default

  ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1

endif # !enable_target_debugging

编译好后，user版本刷入eng版本的lk+boot， 抓取uart 或者上层log

如需抓取开机向导前的log，由于系统还未正式起来，请焊uart线，uart log中输入adb logcat &将上层log输出到uart log中

实际应用总结

 [1]   可正常开机

Answer：MTKlogger基本足矣

[2]   卡logo，不开机

Answer：刷入eng的lk和boot，再跳线抓取uart log，并开启logcat抓取从开机到异常出现时的所有底层和上层log

如果偶尔可以开机，第一时间进入系统提取db信息

如上述方式无法提取到关键db，则需要通过flashtool来回读db的原始raw分区，再通过自制expdb解压工具展开

debug阶段，手机如何抓取有效log

[3]   无ctp情况下如何调试手机

Answer：连接adb，通过adb发送ctp报点与手势，来操作手机

[4]   无lcd情况下如何调试手机

Answer：使用GAT工具，实时抓取手机内部frame buffer，投影到电脑上，并用adb命令操作手机

[5]   UART Log量太大，无法找出重要log怎么办

Answer：采用adb logcat方式实时过滤带关键字关键level的log （包括kernel log）

实际案例（不开机类）

[1]   文件系统损坏导致挂载失败

System mount fail 导致 service 起不来，readback system分区对比看是否文件破坏。

[138:kworker/u16:2]device-mapper: verity: 179:30: metadata block 716579 is corrupted

[246:init]JBD2: IO error reading journal superblock

[246:init]EXT4-fs (dm-0): error loading journal

[246:init]fs_mgr: __mount(source=/dev/block/dm-0,target=/system,type=ext4)=-1  <<===文件系统挂载失败

[246:init]EXT4-fs (mmcblk0p31): VFS: Can't find ext4 filesystem

经常遇到无法开机的问题，低概率、难复现，而且软、硬体跨度大，不易掌握与追踪；

事后分析:

部分有硬件实际损坏、系统映像档被破坏，或用户拔电池导致系统核心文件损坏…等几种原因。

其中一部分导致无法开机的问题是由于不当操作使得文件损坏导致的。

PS:产线也会报小概率不开机的问题。

Donwload完整性检查和开机检查客制化

检查kernel log是否有emmc i/o error相关log

如果是单机问题检查emmc相关供电或作替换物料交叉实验

[ 5.030802] <0>.(0)[165:mmcqd/0]mmcblk0: error -110 transferring data, sector 5448262, nr 442, cmd

response 0x900, card status 0x0

[ 5.032358] <0>.(0)[165:mmcqd/0]blk_update_request: I/O error, dev mmcblk0, sector 5448262

[ 5.130190] <0>.(0)[179:init]EXT4-fs (dm-0): unable to read superblock

[ 5.131325] <0>.(0)[179:init]fs_mgr: __mount(source=/dev/block/dm-0,target=/system,type=ext4)=-1  <<===文件系统挂载失败

preloader hang by mem test fail

[50:31:154] [MEM] complex R/W mem test fail :FFFFFFFF

[50:31:155] <ASSERT> memory.c:line 105 0

[50:31:155] PL fatal error

[50:31:155] PL delay for Long Press Reboot

[50:31:159] power key is pressed

[50:36:117] [PLF]Emergency Dwld mode(timeout: 5s)

[50:36:119] mtk_arch_reset at pre-loader!

场景追溯

此问题发生的背景，是产线样机？研发样机？还是客退机？

问题发生概率如何？有固定的复现路径吗？目前遇到的问题是在什么测试下发生的？

问题发生是在一台机器，还是多台机器都有遇到？---- 如果是单机问题该memory硬件问题可能性大

用料是否为MTK QVL上已经验证OK的？其他项目上是否已经使用过？

————————————————

版权声明：本文为CSDN博主「王小溪灬」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：

https://blog.csdn.net/sinat_41196089/article/details/86138838