Monkey测试中卡在开机阶段的问题
1.正常情况下，当手机非第一次重启，kernel的hang_monitor 会正常启动：
2. 当手机发生FWR后，由于kernel会正常执行，所以hang_detect的机制理论上会正常工作；
// hang_detect的工作机制流程
kernel-3.18/drivers/misc/mediatek/aee/aed/monitor_hang.c
以上是在Monkey测试中发现一例卡在开机阶段的问题。分析如下：
灰屏的问题现场debug分析如下：
1. 初步分析问题原因是由于在开启过程中,启动DisplayManagerService后，去等待屏幕亮起时，由于需要与SF进行IPC通信；但SF Binder现场耗尽无法处理，导致一直卡在开机阶段;
//启动display阶段
06-06 17:44:09.958 10128 10128 I SystemServer: WaitForDisplay
06-06 17:44:19.343 10128 10140 I SystemServer: mSFTime=0
06-06 18:14:01.059 10128 10140 I SystemServer: mSFTime=0
//displayManagerService onBootPhase 阶段
06-06 17:44:09.954 10128 10128 I SystemServiceManager: Starting com.android.server.display.DisplayManagerService
06-06 17:44:09.958 10128 10128 I SystemServiceManager: Starting phase 100
//DisplayManagerService 添加默认display
06-06 17:44:09.954 10128 10128 I SystemServiceManager: Starting com.android.server.display.DisplayManagerService
06-06 17:44:09.965 10128 10152 I DisplayManagerService: Display device added: DisplayDeviceInfo{"Built-in Screen":
...
//循环打印，出问题点
06-07 10:44:08.368 10128 10140 I SystemServer: mSFTime=0
2. 没有触发SWT和Hang_detect的原因是 由于Watchdog此时还未注册，不能正常触发；
3. SF binder耗尽的原因是有由于Binder线程都在等锁
如上分析，根因是SF Binder耗尽，但如果触发hang_detect，手机正常重启就不会卡在开机阶段；所以该问题转为 hang_detect功能为何失效
该问题，理论上触发Hang_detect后就不会卡在开机阶段，因为重启下就会恢复正常。
发现存在一种情况并没有触发hang_detect的情况：
当fwr后，monitor hang正好检测到system_server pid的存在，就会disable hang_detect功能，且count +4 ：
static int hang_detect_thread(void *arg)
{
while (1) {
pr_info("[Hang_Detect] hang_detect thread counts down %d:%d, status %d.\n",
hang_detect_counter, hd_timeout, hd_detect_enabled);
system_server_pid = FindTaskByName("system_server");
//当发生FWR时，正好monitor check到这里，发现system_server_pid 不存在
if ((hd_detect_enabled == 1) && (system_server_pid != -1)) {
...
} else {
//由于是FWR，所以正常这里肯定是1，
if (hd_detect_enabled == 1) {
//count 计数 +4
hang_detect_counter = hd_timeout + 4;
//关闭hang_monitor功能
hd_detect_enabled = 0;
}
//每次count reset
reset_hang_info();
}
Log里可以验证这点：
count在11的基础上加4 说明走了else的逻辑，且每次都reset了count的值
<6>[427067.792783] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.
<6>[427067.792783] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.
<6>[427097.796111] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.
<6>[427097.796111] (2)[139:hang_detect][Hang_Detect] hang_detect thread counts down 15:11, status 0.解决方案：
该问题hang_detect存在这种情况，且不止一例，如果以后在kernel文件发现counts 比hd_timeout_count 大4 ，说明kick时，system_server 被重启过。
由于这块属于BSP，给出的建议有如下2种：
1 . 当检测到system_server 不存在时，继续下一次循环
system_server_pid = FindTaskByName("system_server");
+if (system_server_pid != -1) {
+continue;
+}
+if ((hd_detect_enabled == 1)) {
- if ((hd_detect_enabled == 1) && (system_server_pid != -1))
2.去掉如下判断，因为在if条件里还会判断hang_detect的超时机制，还会触发hang_detect
+if ((hd_detect_enabled == 1)) {
- if ((hd_detect_enabled == 1) && (system_server_pid != -1)) 方案由BSP 评估合入。