手机重启问题定位指南
极力推荐文章：欢迎收藏
本篇文章主要介绍 Android 开发中的部分知识点，通过阅读本篇文章，您将收获以下内容:
一、 AEE 系统机制简介
一、 AEE 系统机制简介
1.MTK AEE 系统
AEE 是 MTK平台自研,用于侦测Android手机系统异常重启的一套系统机制，当AEE系统侦测到异常后会生成 db 文件.
2.db 文件存储路径：/data/aee_expdata/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", "")
native层：
int property_get(const char* key, char* value, const char* def);
通过adb shell
adb shell getprop debug.mtk.aee.db
二、AEE 重启异常分类介绍
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。
1.AEE 输出内容
当有异常发生时候，会生成dbg文件，通过特殊的工具可以解压这个dbg文件。
关注微信公众号： 程序员Androidaee 即可获取解析重启db log的工具。
关注微信公众号：程序员Android 回复 aee 即可获取解析工具
2.dbg文件
db.fatal.00.JE.dbg.DEC 这个文件夹使用aee_extract.exe抽取aee db压缩文件生成的，这个工具在gat-win32-3\prebuilt\spsstools\bin\aee_extract.exe可以找到。
db 文件解压后部分内容
3.ZZ_INTERNAL 简介
ZZ_INTERNAL 包含重启的简单信息，如需获取更多信息，需要解压dbg文件。
ZZ_INTERNAL
4.KE、JE、NE、SWT分类
这种类型最好分类，因为有调用栈，有进程名，分类可以做的很细致。
KE db如果存在SYSTRACKER_DUMP文件，表示存在bus hang，也可以单独列出来。
5. HWT分类
不能以当前CPU的调用栈分类。因为最后调用BUG的CPU是随机的。同样的调用栈，可能是不同的root cause,应该按卡住的CPU的调用栈进行分类
从SYS_LAST_KMSG看Kick bit、check bit得出无喂狗CPU，可能存在多个或没有。SYS_LAST_KMSG提取无喂狗CPU的调用栈
6.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场景
Android Dropbox
三、重启问题快速分析归类指南之 Kernel Exception
当手机重启时候，Kernel重启异常信息会保存在手机/data/aee_exp或 data/vendor/mtklog/aee_exp 中的db文件中。
Kernel Exception重启分类如下：
1.Kernel Panic
2.Watchdog Timeout
3.Hardware Reboot
1.Kernel Panic
即Linux kernel发生了无法修复的错误，从而导致 panic。通过查看 SYS_KERNEL_LOG 的内容.
kernel Panic 进一步可以分为如下几类：
普通的
data abort
oom主动触发的panic
3.undefined instruction，未定义指令异常
4.bad mode异常，即PC处于一个无效的virtual address
1. 普通的data abort
从SYS_KERNEL_LOG中，可以检索到如下关键信息：Unable to handle kernel NULL pointer dereference at virtual address XXXXXXXXXXXXXXXX代表某个非法地址。这种类型是最多的。
2. oom 主动触发的panic
从SYS_KERNEL_LOG中，可以检索到如下关键信息：Kernel panic - not syncing: Out of memory and no killable processes...
此种类型的panic一般是某个process或者APK耗尽了memory资源，从而kernel主动触发的panic重启。
3.undefined instruction，未定义指令异常
从SYS_KERNEL_LOG中，可以检索到如下关键信息：
Internal error: Oops - undefined instruction
此类异常较为少见，可能是CPU/DRAM 不稳定或者受干扰导致的问题。
4.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/0xb0stack错乱，或者未注册回调函数引起。
四、重启问题快速分析归类指南之 Watchdog Timeout
看门狗超时有两种
1.底层看门狗超时
HWT2.上层
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 rebootlog：Hardware Reboot,0,0,99,/data/core/,0,,HW_REBOOT,Fri Jul 3 14:31:53 CST 2015,1
