对手机系统而言,因为肩负着接听电话和接收短信的“重任”,所以被寄予7x24小 时正常工作的希望。但是作为一个在嵌入式设备上运行的操作系统,Android运行中必须面对各种软硬件干扰,从最简单的代码出现死锁或者被阻塞,到内存越界导致的内存破坏,或者由于硬件问题导致的内存反转,甚至是极端工作环境下出现的CPU电子迁移和存储器消磁。这一切问题都可能导致系统服务发生难以预料的崩溃和死机。
想解决这一问题,可以从正反两个方向出发,其一是提高软硬件在极端状态下的可靠性,如进行程序终止性验证,或选用抗辐射加固器件。但是基于成本考虑,普通的手机系统很难做到完全不出故障;另一个方法是及时发现系统崩溃并重启系统。手机系统的大部分的故障都会在重启后消失,不会影响继续使用。所以简单的办法是,如果检测到系统不正常了,将设备重新启动,这样用户就能继续使用了。那么如何才能判断系统是否正常呢。在早期的手机平台上通常的做法是在设备中增加一个硬件看门狗,软件系统必须定 时的向看门狗硬件中写值来表示自己没出故障(俗称“喂狗”),否则超过了规定的时间看门狗就会重新启动设备。
硬件看门狗的问题是它的功能比较单一,只能监控整个系统。早期的手机操作系统大多是单任务的,硬件看门狗勉强能胜任。Android的SystemServer是一个非常复杂的进程,里面运行的服务超过五十种,是最可能出问题的进程,因此有必要对SystemServer中运行的各种线程实施监控。但是如果使用硬件看门狗的工作方式,每个线程隔一段时间去喂狗,不但非常浪费CPU,而且会导致程序设计更加复杂。因此Android开发了WatchDog类作为软件看门狗来监控SystemServer中的线程。一旦发现问题,WatchDog会杀死SystemServer进程。
SystemServer的父进程Zygote接收到SystemServer的死亡信号后,会杀死自己。Zygote进程死亡的信号传递到Init进程后,Init进程会杀死Zygote进程所有的子进程并重启Zygote。这样整个手机相当于重启一遍。通常SystemServer出现问题和kernel并没有关系,所以这种“软重启”大部分时候都能够解决问题。而且这种“软重启”的速度更快,对用户的影响也更小。
转自:http://blog.csdn.net/fu_kevin0606/article/details/64479489
1. Watchdog 简介
Android 为了保证系统的高可用性,设计了Watchdog用以监视系统的一些关键服务的运行状况,如果关键服务出现了死锁,将重启SystemServer;另外,接收系统内部reboot请求,重启系统。
总结一下:Watchdog就如下两个主要功能:
- 接收系统内部reboot请求,重启系统;
- 监控系统关键服务,如果关键服务出现了死锁,将重启SystemServer。
被监控的关键服务,这些服务必须实现Watchdog.Monitor接口:
ActivityManagerService
InputManagerService
MountService
NativeDaemonConnector
NetworkManagementService
PowerManagerService
WindowManagerService
MediaRouterService
MediaProjectionManagerService
2. Watchdog 详解
转自:https://www.cnblogs.com/GMCisMarkdownCraftsman/p/6117129.html
android5.1\cts\common\device-side\util\src\com\android\compatibility\common\util\WatchDog.java
package com.android.compatibility.common.util;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
import android.util.Log;
import junit.framework.Assert;
/**
* Used to fail a test if a function takes more than a certain amount of time.
*/
public class WatchDog implements Runnable {
private static final String TAG = WatchDog.class.getSimpleName();
private Thread mThread;/*Semaphores are counting synchronizing
** variables based on a lock and a condition variable. They are lightweight
** contention control for a given count of resources.*/
private Semaphore mSemaphore;
private volatile boolean mStopRequested;
private final long mTimeoutInMilliSecs;
private TimeoutCallback mCallback = null;
public WatchDog(long timeoutInMilliSecs) {
mTimeoutInMilliSecs = timeoutInMilliSecs;
}
public WatchDog(long timeoutInMilliSecs, TimeoutCallback callback) {
this(timeoutInMilliSecs);
mCallback = callback;
}
/** start watch-dog */
public void start() {
Log.i(TAG, "start");
mStopRequested = false;
mSemaphore = new Semaphore(0);
mThread = new Thread(this);
mThread.start();//注释1:生成Thread并启动
}
/** stop watch-dog */
public void stop() {
Log.i(TAG, "stop");
if (mThread == null) {
return; // already finished
}
mStopRequested = true;
mSemaphore.release();
try {
mThread.join();
} catch (InterruptedException e) {
// ignore
}
mThread = null;
mSemaphore = null;
}
/** resets watch-dog, thus prevent it from panic */
public void reset() {
if (!mStopRequested) { // stop requested, but rendering still on-going
mSemaphore.release();
}
}
@Override
public void run() {
while (!mStopRequested) {
try {
boolean success = mSemaphore.tryAcquire(mTimeoutInMilliSecs, TimeUnit.MILLISECONDS);//注释2:超时时间内获取信号量
if (mCallback == null) {
Assert.assertTrue("Watchdog timed-out", success);
} else if (!success) {
mCallback.onTimeout();//注释3:超时回调
}
} catch (InterruptedException e) {
// this thread will not be interrupted,
// but if it happens, just check the exit condition.
}
}
}
/**
* Called by the Watchdog when it has timed out.
*/
public interface TimeoutCallback {
public void onTimeout();
}
}
参考链接: