系统自动重启异常-总结网上看到的博文

最新推荐文章于 2024-07-12 16:39:41 发布

淡淡的宁静

最新推荐文章于 2024-07-12 16:39:41 发布

阅读量5.2k

点赞数 1

分类专栏： android系统相关

本文链接：https://blog.csdn.net/b1480521874/article/details/78839310

版权

本文详细探讨了Android系统的Watchdog Timeout问题，包括硬件和软件看门狗超时的区分，着重分析了SWT（Software Timeout）的触发条件和处理机制。同时，文章提到了Hang Detect的检测原理，并提供了系统异常时的关键log分析方法，帮助开发者理解和排查系统异常重启的问题。

摘要由CSDN通过智能技术生成

watchdog timeout 有两种，一种是cpu的watchdog timeout，称为HWT（hardware timeout），SWT（software timeout）。

监测cpu的watchdog主要是监测cpu是否卡死，cpu喂狗间隔是20s，而超时时间是30s，也就是说最长能容忍卡住的时间是10s（卡一小会还是可以的），超过这个时间，系统就会复位了。这里还有问题，由于喂狗进程之间没有同步，是否有可能存在刚开始一起喂狗，之后渐渐出现先后呢？误差肯定有的，但在任何30s时间里，喂狗进程都会喂1次狗的（因为喂狗间隔20s，每个CPU肯至少会喂1次狗）。而只要CPU卡死超过10s就复位了。

异常分析之SWT

SWT是指Android Watchdog Timeout，应用层看门狗超时，通常我们说的WDT（Watchdog Timeout）是HWT，硬件看门狗超时。应用层Watchdog主要实现是在frameworks/base/services/java/com/android/server/Watchdog.java里，其实现原理看看这个类就知道，主要逻辑是：

1. Watchdog是单例模式，监控系统几个比较重要的Service，如：MountService、ActivityManagerService、InputManagerService等，这些Service在启动时通过调用Watchdog.getInstance().addMonitor(this); 加入到Watchdog的监控列表中。在ActivityManagerService实现的Watchdog的抽象方法：

/** In this method we try to acquire our lock to make sure that we have not deadlocked */
    public void monitor() {
        synchronized (this) { }
    }

因为在AMS中，很多操作需要线程安全，且使用ActivityManagerService实例的monitor作为锁，所以一个判断service是否有卡死的重要手段就是去看是否能获取到ActivityManagerService实例的monitor，如果长时间获取不到(即看门狗线程没有从monitor方法返回)，就说明很可能卡死了。

可以使用QAAT去分析log，实践证明并不能把所有有用的信息抓出来，还是得自己去细看。分析时需要把所有log都放到QAAt.bat的目录下。

WDT ：watchdog timer

重启和死机问题比较关键的信息是重启开机时抓取的log，而不是重启前的log。

Warning: No aee db file or trace file!!!<