1. android framework层中的watchdog，它属于一种软件Watchdog实现。 a.接收系统内部reboot请求,重启系统。 b.监护SystemServer进程,防止系统死锁, 确保ActivityManagerService、WindowManagerService和 PowerManageService发生死锁后，退出SystemServer进程，让init进程重启它，让系统回到可用状态。2. 分析framework/base/services/java/com/android/server/watchdog.java, watchdog实际上是一个thread3. WatchDog如何启动， run@Frameworks/base/services/java/com/android/server/SystemServer.java WatchDog是在SystemServer进程中被初始化和启动的。在SystemServer 被Start时，各种Android服务被注册和启动，其中也包括了WatchDog的初始化和启动。代码如下： Watchdog.getInstance().init(context, battery, power, alarm,ActivityManagerService.self()); 在SystemServer Run函数的后半段，将检查系统是否已经准备好运行第三方代码，并通过SystemReady接口通知系统已经就绪。在ActivityManagerService的SystemReady接口的CallBack函数中实现WatchDog的启动，代码如下 Watchdog.getInstance().start();
4. 在WatchDog启动之后，开始跑run函数。该函数内部为一个无限循环。 public void run() { boolean waitedHalf = false; while (true) { mCompleted = false; mHandler.sendEmptyMessage(MONITOR); … while (timeout > 0 && !mForceKillSystem) { try { wait(timeout); } catch (InterruptedException e) { } timeout = TIME_TO_WAIT – (SystemClock.uptimeMillis() – start); //TIME_TO_WAIT的默认时间为30s。此为第一次等待时间，WatchDog判断对象是否死锁的最长处理时间为1Min。 } … } } 一开始就会发送一个MONITOR的Message，由HeartbeatHandler负责接收并处理。同时会等待30秒，等待HeartbeatHandler的处理结果。然后才会进行下一步动作。 在HeartbeatHandler中将会作如下处理： public void handleMessage(Message msg) { switch (msg.what) { case MONITOR: { … final int size = mMonitors.size(); for (int i = 0 ; i < size ; i++) { mCurrentMonitor = mMonitors.get(i); mCurrentMonitor.monitor(); }//依次去调用监护对象的monitor接口，实现对其的监护。如果monitor中的synchronized(..)不能及时返回，则表明该监护对象被lock了 synchronized (Watchdog.this) { mCompleted = true; mCurrentMonitor = null; }//如果监护的对象都正常，则会很快运行到这里，并对mCompleted赋值为true，表示对象正常返回。mCompleted值初始为false。 同时在run函数中：if (mCompleted && !mForceKillSystem) { // The monitors have returned. waitedHalf = false; continue; }//如果所有对象在30s内能够返回，则会得到mCompleted = true;则本次监护就结束，返回继续下一轮监护。 如果在30s内，monitor对象未能返回，mCompleted 值即为false，则会运行到该语句： if (!waitedHalf) { // We’ve waited half the deadlock-detection interval. Pull a stack // trace and wait another half. ArrayList<Integer> pids = new ArrayList<Integer>(); pids.add(Process.myPid()); ActivityManagerService.dumpStackTraces(true, pids, null, null); waitedHalf = true; continue; }//会调用ActivityManagerService.java中的dumpStackTraces接口函数。 该动作发生在第一次等待的30s时间内，monitor对象未返回，由于在调用完ActivityManagerService.java的dumpStackTraces接口函数后，将waitedHalf赋值为true。并返回继续下一轮监护。若紧接着的下一轮监护，在30s内 monitor对象依旧未及时返回，此时 if (mCompleted && !mForceKillSystem){ … } if (!waitedHalf){ … }//此时这两个语句都不会运行，则会直接运行到下面部分。这表示系统的监护对象有死锁现象发生，SystemServer进程需要kill并重启。 // If we got here, that means that the system is most likely hung. … // Pull our own kernel thread stacks as well if we’re configured for that if (RECORD_KERNEL_THREADS) { dumpKernelStackTraces();//–>dumpKernelStacks@frameworks/base/core/jni/android_server_watchdog.cpp,后面会分析 } // Only kill/crash if the debugger is not attached. if (!Debug.isDebuggerConnected()) { if (Build.TYPE.equals("eng") || Build.TYPE.equals("userdebug")) { Slog.w(TAG, "*** WATCHDOG KILLING THE SYSTEM: " + name); // Give some extra time to make sure CrashMonitorService reacts to // the dropbox entry before the crash SystemClock.sleep(2000); forceCrashDump();//通过写入"c"到"/proc/sysrq-trigger"产生kernel crash,启动kernel crash dump } else { Slog.w(TAG, "*** WATCHDOG KILLING SYSTEM PROCESS: " + name); Process.killProcess(Process.myPid()); System.exit(10);//在剩下的30s内，做一些收尾工作，如重新初始化trace file。最后直接将SystemServer进程kill，并且退出系统。Init进程会重新启动SystemServer进程，让其回到可用状态。System.exit(?)应该是退出进程？？？会终止该java程序的JVM } } else { Slog.w(TAG, "Debugger connected: Watchdog is *not* killing the system process"); }
绊脚石乃是进身之阶。
