本篇文章主要介绍 ​​Android​​ 开发中的部分知识点,通过阅读本篇文章,您将收获以下内容:


一、AEE 系统机制简介
二、AEE 重启异常分类介绍
三、重启问题之 Kernel Exception
四、重启问题之 Watchdog Timeout
五、重启问题之 Hardware Reboot


一、 AEE 系统机制简介

1.MTK AEE 系统

AEE 是 ​​MTK​​​平台自研,用于侦测​​Android​​​手机系统异常重启的一套系统机制,当​​AEE系统​​ 侦测到异常后会生成 db 文件.

2.db 文件存储路径

MTK 重启db 文件保存的路径如下:

​/data/aee_exp​​ 或 ​​data/vendor/mtklog/aee_exp​

​Android 8.0​​ 之后由于系统安全机制导致​​db​​无法保存到​​MTK log​​中

​user​​版本 中​​AEE​​仅仅侦测引起的重启故障,例如:​​KE/system server , NE/system server ,JE/SWT​​。

3.AEE 异常侦测机制

​AP​​​层重启时候,​​AEE​​​系统会在​​db​​​生成后会发生​​am​​​ 广播(​​com.mediatek.log2server.EXCEPTION_HAPPEND​​​),但系统重启类异常(​​KE / HW reboot/ HWT​​​)不会发送广播,因为​​AMS​​还无法使用。

另外,​​AEE​​​会开机后判断异常重启,当异常重启后会设置​​debug.mtk.aee.db​​​的 ​​property​​​,由于不是​​persist​​​的,关机就丢失,因此只有异常重启后才有这个​​property​​存在。

因此,我们可以通过检查​​debug.mtk.aee.db​​的方法来获取系统是否发生了异常重启。

4.重启异常 debug.mtk.aee.db 读取方法

  • 1.java 层:

​android.os.SystemProperties.get("debug.mtk.aee.db", "")​

  • 2.native层:

​int property_get(const char* key, char* value, const char* def);​

  • 3.通过adb shell

​adb shell getprop debug.mtk.aee.db​

二、AEE 重启异常分类介绍

1.AEE 重启异常分类 如下:


  • 1.KE
  • 2.HWT
  • 3.HWT Reboot
  • 4.NE
  • 5.JE
  • 6.SWT

上面的类型可能会变化,具体请参考kernel代码:​​kernel-4.4/drivers/misc/mediatek/include/mt-plat/aee.h​​​里的​​AE_EXP_CLASS​​。

2.AEE 输出内容

当有异常发生时候,会生成​​dbg​​​文件,通过特殊的工具可以解压这个​​dbg​​文件。

关注微信公众号: ​​程序员Android​

回复 aee 即可获取解析重启​​db log​​的工具。

MTK平台手机重启问题分析_重启

关注微信公众号:程序员Android 回复 aee 即可获取解析工具

3.dbg文件

​db.fatal.00.JE.dbg.DEC​​​ 这个文件夹使用​​aee_extract.exe​​​抽取​​aee db​​​压缩文件生成的,这个工具在​​gat-win32-3\prebuilt\spsstools\bin\aee_extract.exe​​可以找到。

MTK平台手机重启问题分析_重启_02

db 文件解压后部分内容

4.ZZ_INTERNAL 简介

​ZZ_INTERNAL​​​ 包含重启的简单信息,如需获取更多信息,需要解压​​dbg​​文件。

MTK平台手机重启问题分析_android_03

ZZ_INTERNAL

5.KE、JE、NE、SWT分类

这种类型最好分类,因为有调用栈,有进程名,分类可以做的很细致。

KE db如果存在​​SYSTRACKER_DUMP​​​文件,表示存在​​bus hang​​,也可以单独列出来。

6. HWT分类

不能以当前​​CPU​​​的调用栈分类。因为最后调用​​BUG​​​的​​CPU​​​是随机的。同样的调用栈,可能是不同的​​root cause​​​,应该按卡住的​​CPU​​的调用栈进行分类

从​​SYS_LAST_KMSG​​看​​Kick bit、check bit​​得出无喂狗​​CPU​​,可能存在多个或没有。

从​​SYS_LAST_KMSG​​提取无喂狗​​CPU​​的调用栈

7.HW reboot分类

可以通过​​__exp_main.txt​​​里的​​Exception Type​​分类


  • HW reboot
  • Thermal reboot
  • SPM reboot
  • ATF crash

​Type​​​为​​HW reboot​​​可以进一步细分( 按​​SYS_REBOOT_REASON​​里字段信息 )


  • last pc,看各个​​Core​​停止的位置
  • deepidle/sodi3/sodi/spm_suspend,如果非​​0​​表示当时处于​​low power​​场景

三、重启问题快速分析归类指南之 ​​Kernel Exception​​

当手机重启时候,​​Kernel​​​重启异常信息会保存在手机​​/data/aee_exp​​​或 ​​data/vendor/mtklog/aee_exp​​​中的​​db​​文件中。

1.Kernel Exception重启分类如下:


  • 1.Kernel Panic
  • 2.Watchdog Timeout
  • 3.Hardware Reboot

2.Kernel Panic

即​​Linux kernel​​​发生了无法修复的错误,从而导致 ​​panic​​。通过查看 SYS_KERNEL_LOG 的内容.

​kernel Panic​​ 进一步可以分为如下几类:


  • 1.普通的​​data abort​
  • 2.​​oom​​主动触发的​​panic​
  • 3.​​undefined instruction​​,未定义指令异常
  • 4.​​bad mode​​异常,即​​PC​​处于一个无效的​​virtual address​

3. 普通的data abort

从​​SYS_KERNEL_LOG​​中,可以检索到如下关键信息:

​Unable to handle kernel NULL pointer dereference at virtual address XXXXXXXX​

如上的​​XXXXXXXX​​代表某个非法地址。这种类型是最多的。

4. oom 主动触发的panic

从​​SYS_KERNEL_LOG​​中,可以检索到如下关键信息:

​Kernel panic - not syncing: Out of memory and no killable processes...​

此种类型的​​panic​​​一般是某个​​process​​​或者​​APK​​​耗尽了​​memory​​​资源,从而​​kernel​​​主动触发的​​panic​​重启。

5.undefined instruction,未定义指令异常

从​​SYS_KERNEL_LOG​​中,可以检索到如下关键信息:

​Internal error: Oops - undefined instruction​

此类异常较为少见,可能是​​CPU/DRAM​​ 不稳定或者受干扰导致的问题。

6.bad mode异常,即PC处于一个无效的virtual address

从​​SYS_KERNEL_LOG​​中,可以检索到如下关键信息:

​Bad mode in Synchronous Abort handler detected​

​[14820.652408]-(1)[682:VSyncThread_0][<ffffffc000088f90>] bad_mode+0x78/0xb0​

此类异常较为少见,可能的原因是​​stack​​错乱,或者未注册回调函数引起。

四、重启问题快速分析归类指南之 Watchdog Timeout

看门狗超时有两种


  • 1.底层看门狗超时​​HWT​
  • 2.上层​​hang_detect​​ 触发看门狗超时​​SWT​

1.底层看门狗超时​​HWT​

从​​SYS_KERNEL_LOG​​中,可以检索如下关键信息

  • arm64 平台
PC is at aee_wdt_atf_info+0x4c8/0x6dc
LR is at aee_wdt_atf_info+0x4c0/0x6dc
  • arm32 平台
PC is at aee_wdt_irq_info+0x104/0x12c
LR is at aee_wdt_irq_info+0x104/0x12c

此类异常较为常见,多见于底层频繁​​irq/bus​​​卡死,导致​​kicker​​​无法被​​schedule​​​,从而引起​​watch dog​​​触发中断,引导系统进入​​FIQ​​​处理流程,最终​​call​​​到​​BUG​​触发重启。

2. 上层​​hang_detect​​​ 触发看门狗超时​​SWT​

从​​SYS_KERNEL_LOG​​中,可以检索( 关键字 :hang_detect)

[ 2131.086562] (0)[77:hang_detect][Hang_Detect] we should triger HWT ...
...
[ 2180.467416]-(0)[77:hang_detect]PC is at aee_wdt_irq_info+0x154/0x170
[ 2180.467426]-(0)[77:hang_detect]LR is at aee_wdt_irq_info+0x154/0x170
...

此异常类型较为常见,多见于​​GPU/SD卡/eMMC​​​无法满足​​surfacelinger/system_server​​​的通讯需求,从而导致​​上层卡死​​​,进而主动​​触发看门狗超时重启​​。

五、重启问题快速分析归类指南之 Hardware Reboot

​Hardware reboot​​​是​​watch dog​​​直接发出​​reset​​信号,导致整个系统重启;在重启之前,并没有触发任何异常处理流程。

一般情况下,​​hardware reboot​​​对应的​​db​​​不会有​​SYS_KERNEL_LOG​​​ 可以排查,只能从​​SYS_LAST_KMSG​​​获知异常之前​​kernel​​​的动作,以及从​​SYS_REBOOT_REASON​​​获知异常时的​​CPU​​寄存器值和其它参数。

从​​ZZ_INTERNAL​​ 档案,可以知道发生了​​hardware reboot​

例如 如下部分​​log​​:

​Hardware Reboot,0,0,99,/data/core/,0,,HW_REBOOT,Fri Jul 3 14:31:53 CST 2015,1​