Log总览

Android Log

Android java层和native层 log

main log、system log、radio log、event log

Kernel Log

Linux Kernel内核和驱动log

UART Log

Exception Datebase(db)

系统死机/重启等问题发生时候的原始RAW datajava

Log Tools

mtklogger

PC tool

手机端mtklogger

我的优化

mtklog抓取完整kernel log

默认抓不全缘由

因为Mobilelog service运行要在android system init阶段，而从kernel启动到这个阶段，kernel log已经在不断地送入log ring buffer，log量大的状况下ring buffer就会被覆盖linux

默认抓取到的kernel_log.boot不是从0s开始，对于研发debug阶段,只能靠抓取uart log来获取0s开始的log，很是影响debug效率android

解决方法

alps/kernel-3.18/init/Kconfig

config LOG_BUF_SHIFT

default 17 --- > 21 2^21=2MB buffer

alps/system/core/liblog/include/private/android_logger.h

#define LOG_BUFFER_SIZE (2048 * 1024) #log和logd一致

电脑端PC tool

adb

logcat

介绍

logcat是android中的一个命令行工具，能够用于获得程序的log信息web

常见的日志纪录方法包括：shell

方法

描述

v(String,String) (vervbose)

显示所有信息

d(String,String)(debug)

显示调试信息

i(String,String)(information)

显示通常信息

w(String,String)(waning)

显示警告信息

e(String,String)(error)

显示错误信息

例如：app

//开发过程当中获取log

Log.i("MyActivity","MyClass.getView() - get item number"+position);

//adb获取log

adb logcat

adb logcat输出的日志格式以下：less

I/ActivityManager( 1754): Waited long enough for: ServiceRecord{2b24178c u0 com.google.android.gms/.checkin.CheckinService}svg

实例

adb logcat –b radio

adb logcat –b system

adb logcat –b events

adb logcat –b main

优点

缓冲区强大，不会由于数据量过大而丢失log

过滤性能好

语法简洁，使用方便

提取db

位置

/data/aee_exp

/data/vendor/mtklog/aee_exp

GAT

BugReport

DB puller

Mediatek LogView

各类mode抓mobile log

Normal mode

GAT (user版本只能抓main log，eng版本还能抓到kernel log)

mtklogger(user版本经过*##3646633##*进入工模选择)，会暂时录制到/data/log_temp下，等SD卡ready后再copy到mtklog/mobilelog/APLog路径下

Meta mode(PC meta tool)

会先录制到/data/log_temp/meta/下，等外卡ready后再copy到sdcard1/mtklog/mobilelog/APLog路径下，而后删除源文件(data/log_temp)。

Factory mode(power + down key)

同Meta mode

Recovery mode(power + up key)

先存在tmp/recovery.log，Reboot进入normal后存在cache/recovery

user 版本须要下载eng的recovery.img和boot.img才能抓log

IPO mode

设置IPO关机后，关机期间的log会录制到/data/log_temp/ipo/下，等再次开机后再copy到/mtklog/mobilelog/APLog路径下，而后删除源文件。

GAT

各类场景抓log

Preloader & LK阶段(没有logo或卡在logo界面)开机log

抓取uart log

Kernel阶段(有logo或开机动画)开机log

若是是User版本，先用对应ENG 版本的lk 替换掉user 版本的lk

或者在user load的alps/bootable/bootloader/lk/app/mt_boot/mt_boot.c中，将全部printk.disable_uart=1改为printk.disable_uart=0，而后从新编译lk, download lk 便可。

Android阶段(有开机动画)开机log

Adbd进程起来后，可使用GAT抓取开机log(录制前先关机)。工具

若mtklogger可用，能够经过设置mobile log开机自启动录制开机log。性能

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

若TP没法使用，能够参考FAQ06939使用adb命令控制mtklogger录制。

user build 抓开机向导或者不开机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中

AEE异常机制

AEE介绍

AEE (Android Exception Engine)是安卓的一个异常捕获和调试信息生成机制。

手机发生错误(异常重启/卡死)时生成db文件(一种被加密过的二进制文件)

why do we need AEE

用来保存和记录异常发生时候的全部内存信息，经过调试和仿真这些信息，能够追踪到异常的缘由

DB文件介绍

File

Description

__exp_main.txt

异常类型，调用栈等关键信息

_exp_detail.txt

详细异常信息

SYS_ANDROID_LOG

android buffer log(logcat -d -v time *:v)

SYS_KERNEL_LOG

kernel log

SYS_LAST_KMSG

上次重启前的kernel log

SYS_MINI_RDUMP

相似coredump，能够用gdb/trace32调试

SYS_WDT_LOG

看门狗复位信息

SYS_REBOOT_REASON

重启时的硬件记录的信息

SYS_VERSION_INFO

kernel版本，用于和vmlinux对比，只有匹配的vmlinux才能用于分析这个异常

SYS_ANDROID_EVENT_LOG

android event log(logcat -b events -v time -d *:v)

SYS_ANDROID_RADIO_LOG

android buffer log(logcat -b radio -v time -d *:v)

PROCESS_COREDUMP

native program core dump

SYS_PROPERTIES

system properties

SWT_JBT_TRACES

/data/anr/.

ZZ_INTERNAL

基本异常信息

SYS_CPU_INFO

cpu 信息(top -n 1 -d 1 -m 30 -t)

SYS_MEMORY_INFO

memory information (/proc/meminfo)

重启缘由记录

struct last_reboot_reason

{

uint32_t fiq_step;

uint32_t exp_type; /* 0xaeedeadX: X=1 (HWT), X=2 (KE), X=3 (nested panic) */

uint32_t reboot_mode;

uint32_t last_irq_enter[NR_CPUS];

uint64_t jiffies_last_irq_enter[NR_CPUS];

uint32_t last_irq_exit[NR_CPUS];

uint64_t jiffies_last_irq_exit[NR_CPUS];

uint64_t jiffies_last_sched[NR_CPUS];

char last_sched_comm[NR_CPUS][TASK_COMM_LEN];

uint8_t hotplug_data1[NR_CPUS], uint8_t hotplug_data2;

uint64_t hotplug_data3;

uint32_t mcdi_wfi, mcdi_r15, deepidle_data, sodi_data, spm_suspend_data;

uint64_t cpu_dormant[NR_CPUS];

uint32_t clk_data[8], suspend_debug_flag;

uint8_t cpu_dvfs_vproc_big, cpu_dvfs_vproc_little, cpu_dvfs_oppidx, cpu_dvfs_status;

uint8_t gpu_dvfs_vgpu, gpu_dvfs_oppidx, gpu_dvfs_status;

uint64_t ptp_cpu_big_volt, ptp_cpu_little_volt, ptp_gpu_volt, ptp_temp;

uint8_t ptp_status;

uint8_t thermal_temp1, thermal_temp2, thermal_temp3, thermal_temp4, thermal_temp5;

uint8_t thermal_status;

void *kparams;

};

实际应用总结

usr状态，不一样现象手机如何抓取有效log

可正常开机

A：MTKlogger基本足矣

卡logo，不开机

A：

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

若是偶尔能够开机，第一时间进入系统提取db信息

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

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

无ctp状况下如何调试手机

A：链接adb，经过adb发送ctp报点与手势，来操做手机

无lcd状况下如何调试手机

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

UART Log量太大，没法找出重要log怎么办

A：采用adb logcat方式实时过滤带关键字关键level的log (包括kernel log)

Log分析与调试技巧

Android开机流程图

bootprof

adb shell cat /proc/bootprof or mktlog bootprof file

实际案例(不开机类)

文件系统损坏致使挂载失败

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] 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的？其余项目上是否已经使用过？