Android 手机重启解决方案
本篇文章主要介绍 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", "")
native层：
int property_get(const char* key, char* value, const char* def);
通过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场景
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进一步可以分为如下几类：
普通的data abort
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.底层看门狗超时
上层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/0x6dcfor 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平台芯片厂商
Framework 层对象空指针导致手机重启。
Framework 层对象空指针导致手重启
Framework 层数组越界导致手机重启
Framework 层数组越界导致手机重启
解决方案
修改WindowContainer 类，避免异常报错。文件路径如下：alps/frameworks/base/services/core/java/com/android/server/wm/WindowContainer.java。
避免空指针，捕获抛出的异常
第三方APK 引起的重启问题
奇酷 360 Telecom 空指针引起的重启问题举例。
360 qiku Telecom 空指针引起的重启
高温情况下，Kernel Exception引起的重启问题
手机 电池温度 60度以上高温会触发手机重启，部分异常Log 如下：
高温情况下，Kernel Exception引起的重启问题
解决方案
此问题 需要驱动同事修改底层battery.c 文件中的一个地址，不让其写为dead，就不会重启。具体解决方案还需驱动同事协助帮忙。
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;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 将异常捕获，防止重启。
将异常捕获
线程死锁导致系统重启
死锁导致重启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 释放锁
拷贝大文件，IO wait 高导致SWT重启
Aee log
Block IO 很高导致重启
解决方案
修改init.rc 文件
system/core/rootdir/init.rc
通过调整内核参数，将写活动的高峰分布成频繁的多次写，每次写入的数据比较少。以这种方式执行的效率比较低，减少了内核组合写操作的机会
write /proc/sys/vm/dirty_background_ratio 1
write /proc/sys/vm/dirty_ratio 2关闭ANR dump 信息
修改代码如下/vendor/mediatek/proprietary/external/aee/config_external/init.aee.customer.rc
on init
setprop persist.dbg.anrflow 1关闭 wtf dump文件log信息
当拷贝大型文件到手机中（5G以上），此时手机IO wait 会很高，此时Dump ANR wtf 等信息，会严重影响到IO wait ，如果系统超过1分钟无响应，看门狗会自动重启手机。
dump wtf 会影响到 IO 读写速度
至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。期待您的关注，
至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。期待您的关注，
如有侵权，请联系小编，小编对此深感抱歉，同时小编会立即停止侵权行为。
欢迎关注微信公众号:程序员Android
微信公众号：ProgramAndroid
我们不是牛逼的程序员，我们只是程序开发中的垫脚石。
点击阅读原文，获取更多福利
