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

1.MTK 平台AEE 搜集重启问题介绍

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

微信公众号：ProgramAndroid

我们不是牛逼的程序员，我们只是程序开发中的垫脚石。

1. MTK 平台AEE 搜集重启问题介绍

MTK AEE 系统

AEE 系统 是 MTK 平台自研的异常重启的侦测和手机系统，当 AEE 侦测到异常后会生成db 文件，路径： /data/aee_exp 或 mtklog/aee_exp（Android O有时候db无法保存到MTK log中），user 版本 中AEE 仅仅侦测引起的重启故障，例如：KE／system server , NE／system server ,JE／SWT 。

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的方法来获取系统是否发生了异常重启。

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

• 1.java 层：

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

1. native层：

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

1. 通过adb shell

adb shell getprop debug.mtk.aee.db

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。

AEE 输出内容

AEE 输出内容

dbg文件

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

db 文件解压后部分内容

ZZ_INTERNAL 简介

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

ZZ_INTERNAL

KE、JE、NE、SWT分类

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

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

HWT分类

不能以当前CPU的调用栈分类。因为最后调用BUG的CPU是随机的。

同样的调用栈，可能是不同的root cause

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

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场景

1. Android Dropbox

2. SWT 导致手机重启问题分析

SWT 导致手机重启问题分析,之前已经有文章分析，点击下方链接既可查看。SWT 导致手机重启问题分析

3. 快速分析归类重启问题

当手机重启时候，Kernel 重启异常信息会保存在手机/data/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进一步可以分为如下几类：

1. 普通的data abort

1. oom 主动触发的panic

3.undefined instruction，未定义指令异常

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

1. 普通的data abort

从SYS_KERNEL_LOG中，可以检索到如下的info:Unable to handle kernel NULL pointer dereference at virtual address XXXXXXXX

2. oom 主动触发的panic

从SYS_KERNEL_LOG中，可以检索到如下的info:Kernel panic - not syncing: Out of memory and no killable processes...

此种类型的panic一般是某个process或者APK耗尽了memory资源，从而kernel主动触发的panic重启。对于这种类型的重启，强烈建议工程师把如上的info填写到eService 的标题中，这样MTK可以对eService进行一次到位的分配。

3.undefined instruction，未定义指令异常

从SYS_KERNEL_LOG中，可以检索到如下的info:

Internal error: Oops - undefined instruction

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

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

从SYS_KERNEL_LOG中，可以检索到如下的info:Bad mode in Synchronous Abort handler detected

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

2.Watchdog Timeout

看门狗超时有两种

• 1.底层看门狗超时

1. 上层hang_detect 触发看门狗超时

1.底层看门狗超时

从SYS_KERNEL_LOG中，可以检索到如下的info:

• for arm64 platform

PC is at aee_wdt_atf_info+0x4c8/0x6dcLR is at aee_wdt_atf_info+0x4c0/0x6dc

• for arm32 platform

PC is at aee_wdt_irq_info+0x104/0x12cLR is at aee_wdt_irq_info+0x104/0x12c

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

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

从SYS_KERNEL_LOG中，可以检索(关键字 ： hang_detect)到如下的info:

[ 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的通讯需求，从而导致上层卡死，进而主动触发看门狗超时重启。对于这种类型的重启，强烈建议工程师把如上的Hang_Detect关键字填写到eService 的标题中，这样MTK可以对eService进行一次到位的分配。

3.Hardware Reboot

hardware reboot是watch dog直接发出reset信号，导致整个系统重启；在重启之前，并没有触发任何异常处理流程。一般情况下，hardware reboot对应的db不会有SYS_KERNEL_LOG 可以排查，只能从SYS_LAST_KMSG获知异常之前kernel的动作，以及从SYS_REBOOT_REASON获知异常时的CPU寄存器值和其它参数。

从ZZ_INTERNAL 档案，可以知道发生了hardware rebootHardware Reboot,0,0,99,/data/core/,0,,HW_REBOOT,Fri Jul 3 14:31:53 CST 2015,1

4.部分手机重启问题解决方案

以下修改方案仅适用于MTK平台芯片厂商

1. Framework 层对象空指针导致手机重启。

Framework 层对象空指针导致手重启

1. Framework 层数组越界导致手机重启

Framework 层数组越界导致手机重启

解决方案

修改WindowContainer 类，避免异常报错。文件路径如下：alps/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java。

避免空指针，捕获抛出的异常

1. 第三方APK 引起的重启问题

奇酷 360 Telecom 空指针引起的重启问题举例。

360 qiku Telecom 空指针引起的重启

1. 高温情况下，Kernel Exception引起的重启问题

手机 电池温度 60度以上高温会触发手机重启，部分异常Log 如下：

高温情况下，Kernel Exception引起的重启问题

解决方案

此问题 需要驱动同事修改底层battery.c 文件中的一个地址，不让其写为dead，就不会重启。具体解决方案还需驱动同事协助帮忙。

1. TimeoutException 导致系统重启

TimeoutException 导致系统重启

从重启的JE trace看，由于在ART GC时，如果检查到某个对象其所属的类型override了finalize函数，会把这个对象添加到referenceQueue中。

Java进程会等待10s钟，如果10s还没有执行完，进程会强制抛出TimeoutException。

一般是由于当时系统IO忙或者memory比较紧张，导致不能及时唤醒这个线程及时往下执行

解决方案/libcore/libart/src/main/java/java/lang/Daemons.java

private static final long MAX_FINALIZE_NANOS = 10L * NANOS_PER_SECOND;
修改为：20L * NANOS_PER_SECOND;

1. Service not registered 异常导致手机重启

Service not registered 重启异常

解决方案\frameworks\base\core\java\android\app\ContextImple.java文件

优化unbindService方法

修改frameworks\base\services\backup\java\com\android\server\backup\TransportManager.java 将异常捕获，防止重启。

将异常捕获

1. 线程死锁导致系统重启

死锁导致重启log简析

TID =1 Block 等待 TID=9 释放锁

TID =1 Block 等待 TID=9 释放锁

TID =9 线程等待TID=20 释放锁

TID =9 线程等待TID=20 释放锁

TID = 20 线程 等待 TID=9 释放锁

TID = 20 线程 等待 TID=9 释放锁

1. 拷贝大文件，IO wait 高导致SWT重启

Aee log

Block IO 很高导致重启

• 解决方案

1. 修改init.rc 文件 system/core/rootdir/init.rc

通过调整内核参数，将写活动的高峰分布成频繁的多次写，每次写入的数据比较少。以这种方式执行的效率比较低，减少了内核组合写操作的机会

    write /proc/sys/vm/dirty_background_ratio  1write /proc/sys/vm/dirty_ratio 2

1. 关闭ANR dump 信息

修改代码如下/vendor/mediatek/proprietary/external/aee/config_external/init.aee.customer.rc

on initsetprop persist.dbg.anrflow 1

1. 关闭 wtf dump文件log信息

当拷贝大型文件到手机中（5G以上），此时手机IO wait 会很高，此时Dump ANR wtf 等信息，会严重影响到IO wait ，如果系统超过1分钟无响应，看门狗会自动重启手机。

dump wtf 会影响到 IO 读写速度

至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。期待您的关注，

至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。期待您的关注，

如有侵权，请联系小编，小编对此深感抱歉，同时小编会立即停止侵权行为。

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

微信公众号：ProgramAndroid

我们不是牛逼的程序员，我们只是程序开发中的垫脚石。

点击阅读原文，获取更多福利