『Android Q 源码分析』-Android 10.0 Wa
2020-03-10 本文已影响0人
ContentPane
概览
（本文系统源码基于Andoroid 10.0.0-r16）
Watchdog的中文叫“看门狗”，最早引入Watchdog是在单片机系统中，由于单片机的工作环境容易受到外界磁场的干扰，导致程序“跑飞”，造成整个系统无法正常工作，因此，引入了一个“看门狗”，对单片机的运行状态进行实时监测，针对运行故障做一些保护处理，譬如让系统重启。这种Watchdog属于硬件层面，必须有硬件电路的支持。
Linux也引入了Watchdog，在Linux内核下，当Watchdog启动后，便设定了一个定时器，如果在超时时间内没有对/dev/Watchdog进行写操作，则会导致系统重启，通过定时器实现的Watchdog属于软件层面。
Android设计了一个软件层面Watchdog，用于保护一些重要的系统服务，当出现故障时，通常会让Android系统重启。由于这种机制的存在，就经常会出现一些system_server进程被Watchdog杀掉而发生系统重启的问题。
原理就是每到达一定的时间，获取正在监控的锁(Monitor.monitor())，能否获得锁从而判断是否产生了死锁。
Watchdog流程
<center style="font-size:13px;color:#C0C0C0;">Watchdog流程</center>
Watchdog初始化
首先我们可以看到WatchDog是继承于Thread类，而实际上WatchDog也是单线程运行的。
public class Watchdog extends Thread {}
接下来我们可以看下Watchdog的构造函数：
frameworks/base/services/core/java/com/android/server/Watchdog.java
private Watchdog() {
// 设置线程名字为watchdog
super("watchdog");
// Initialize handler checkers for each common thread we want to check.
// 请注意，我们目前没有检查后台线程，因为它可能会持有较长时间运行的操作,
// 而不能保证那里的操作的及时性。
// FgThread monitor
mMonitorChecker = new HandlerChecker(FgThread.getHandler(),
"foreground thread", DEFAULT_TIMEOUT);
mHandlerCheckers.add(mMonitorChecker);
// main thread monitor
mHandlerCheckers.add(new HandlerChecker(new Handler(Looper.getMainLooper()),
"main thread", DEFAULT_TIMEOUT));
// UiThread monitor
mHandlerCheckers.add(new HandlerChecker(UiThread.getHandler(),
"ui thread", DEFAULT_TIMEOUT));
// IoThread monitor
mHandlerCheckers.add(new HandlerChecker(IoThread.getHandler(),
"i/o thread", DEFAULT_TIMEOUT));
// DisplayThread monitor
mHandlerCheckers.add(new HandlerChecker(DisplayThread.getHandler(),
"display thread", DEFAULT_TIMEOUT));
// AnimationThread monitor
mHandlerCheckers.add(new HandlerChecker(AnimationThread.getHandler(),
"animation thread", DEFAULT_TIMEOUT));
// SurfaceAnimationThread monitor
mHandlerCheckers.add(new HandlerChecker(SurfaceAnimationThread.getHandler(),
"surface animation thread", DEFAULT_TIMEOUT));
// BinderThreadMonitor 主要用于检测binder线程是否达到连接上限16个
// >= 16个则阻塞线程等待mThreadCountDecrement唤醒
addMonitor(new BinderThreadMonitor());
// 用于对fd数量进行检测 只会在userdebug或者eng版本开启
// 值是厂商设置的 达到这个值 - 12 就会在/data/anr/ dump fd的信息
mOpenFdMonitor = OpenFdMonitor.create();
assert DB ||
DEFAULT_TIMEOUT > ZygoteConnectionConstants.WRAPPED_PID_TIMEOUT_MILLIS;
}
可以看出我们在创建出Watchdog的时候先把一些重要的线程加到Watchdog的mHandlerCheckers里面，当Watchdog执行run()方法的时候就会依次对mHandlerCheckers里面的HandlerChecker对象进行轮询，查看是否有超时的线程。有的话一般都是重启来解决。
那我们在哪里调用这个设置为private的构造函数呢？就是在本类的getInstance()中
public static Watchdog getInstance() {
if (sWatchdog == null) {
sWatchdog = new Watchdog();
}
return sWatchdog;
}
我们现在再看深一层，那究竟谁调用了getInstance()方法呢？我们动用ctrl +
鼠标点一下就弹出一系列的调用者。查看一番之后，可以观察到是SystemServer调用了我们Watchdog的getInstance()方法进行初始化。
frameworks/base/services/java/com/android/server/SystemServer.java
private void startBootstrapServices() {
final Watchdog watchdog = Watchdog.getInstance();
watchdog.start();
// ...
}
在调用了初始化的getInstance()之后就马上调用了watchdog的start()方法，其实也就是父类Thread的start()方法，这时候我们的“看门狗”就跑起来了（执行了run()方法）,而且可以看到watchdog是在startBootstrapServices()中的第一句就进行初始化了，SystemServer中初始化服务的顺序是这样的：
startBootstrapServices();startCoreServices();startOtherServices();
这说明了watchdog在众多的服务中，优先级还是很高的，那有没有同学会想到是为什么呢？答案就是很多服务的超时结束机制都是依赖watchdog提供的，所以watchdog必须要比其他服务早初始化。
我们再来看一下WatchDog的init()方法，因为依赖于ActivityManagerService，所以我们将在ActivityManagerService初始化之后再执行这个方法。
public void init(Context context, ActivityManagerService activity) {
mActivity = activity;
context.registerReceiver(new RebootRequestReceiver(),
new IntentFilter(Intent.ACTION_REBOOT),
android.Manifest.permission.REBOOT, null);
}
可以看到这里通过context注册了一个广播接收器，而这个RebootRequestReceiver用来接收重启的广播来进行手机重启的，是Watchdog中定义的一个内部类，RebootRequestReceiver的代码如下：
final class RebootRequestReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context c, Intent intent) {
if (intent.getIntExtra("nowait", 0) != 0) {
rebootSystem("Received ACTION_REBOOT broadcast");
return;
}
Slog.w(TAG, "Unsupported ACTION_REBOOT broadcast: " + intent);
}
}
void rebootSystem(String reason) {
Slog.i(TAG, "Rebooting system because: " + reason);
IPowerManager pms = (IPowerManager)ServiceManager.getService(Context.POWER_SERVICE);
try {
// 这里是手机重启而不是系统重启
pms.reboot(false, reason, false);
} catch (RemoteException ex) {
}
}
HandlerChecker
我们再来看看在Watchdog中相对比较重要的HandlerChecker内部类是长什么样子的。
/**
* Used for checking status of handle threads and scheduling monitor callbacks.
*/
public final class HandlerChecker implements Runnable {
// 需要检测的线程对应的handler
private final Handler mHandler;
// 进行日志打印的时候知道是哪个handler出现问题
private final String mName;
// 超时时间
private final long mWaitMax;
// 检测的Monitor数组
private final ArrayList<Monitor> mMonitors = new ArrayList<Monitor>();
// 还未加入mMonitors中的Monitor
// 等待mCompleted为true的时候才一次性加入mMonitors中
private final ArrayList<Monitor> mMonitorQueue = new ArrayList<Monitor>();
// 是否检查完成的标志位 空闲的话默认为true
private boolean mCompleted;
// 目前正在检查的Monitor
private Monitor mCurrentMonitor;
// 检查开始的时间
private long mStartTime;
// mPauseCount > 0则说明这个HandlerChecker处于暂停状态
private int mPauseCount;
HandlerChecker(Handler handler, String name, long waitMaxMillis) {
mHandler = handler;
mName = name;
mWaitMax = waitMaxMillis;
mCompleted = true;
}
// 注释1
void addMonitorLocked(Monitor monitor) {
// We don't want to update mMonitors when the Handler is in the middle of checking
// all monitors. We will update mMonitors on the next schedule if it is safe
mMonitorQueue.add(monitor);
}
// 注释2
public void scheduleCheckLocked() {
if (mCompleted) {
// Safe to update monitors in queue, Handler is not in the middle of work
mMonitors.addAll(mMonitorQueue);
mMonitorQueue.clear();
}
// 待检测的mMonitors为零且looper正在从队列中轮询任务
// 或者正在暂停的情况下 不要进行一些数据的重置
if ((mMonitors.size() == 0 && mHandler.getLooper().getQueue().isPolling())
|| (mPauseCount > 0)) {
mCompleted = true;
return;
}
if (!mCompleted) {
// we already have a check in flight, so no need
return;
}
mCompleted = false;
mCurrentMonitor = null;
mStartTime = SystemClock.uptimeMillis();
// 往handler前面插入任务（插队）
mHandler.postAtFrontOfQueue(this);
}
// 是否超时
boolean isOverdueLocked() {
return (!mCompleted) && (SystemClock.uptimeMillis() > mStartTime + mWaitMax);
}
// 通过mStartTime、mWaitMax和mCompleted 进行状态的判断
// 前 mWaitMax/2 秒为WAITING状态，后mWaitMax/2为WAITED_HALF状态
// 大于mWaitMax为超时状态也就是OVERDUE状态
public int getCompletionStateLocked() {
if (mCompleted) {
return COMPLETED;
} else {
long latency = SystemClock.uptimeMillis() - mStartTime;
if (latency < mWaitMax/2) {
return WAITING;
} else if (latency < mWaitMax) {
return WAITED_HALF;
}
}
return OVERDUE;
}
public Thread getThread() {
return mHandler.getLooper().getThread();
}
public String getName() {
return mName;
}
// 获取Blocked状态的描述
// 在哪个名字的HandlerChecker中 或者 当前handler执行哪个monitor
String describeBlockedStateLocked() {
if (mCurrentMonitor == null) {
return "Blocked in handler on " + mName + " (" + getThread().getName() + ")";
} else {
return "Blocked in monitor " + mCurrentMonitor.getClass().getName()
+ " on " + mName + " (" + getThread().getName() + ")";
}
}
@Override
public void run() {
// 一旦我们到达这里，我们确保即使我们调用#addMonitorLocked也不会改变mMonitors，
// 因为我们首先将新的监视器添加到mMonitorQueue中，
// 并在下一次mCompleted为真时将它们移到mMonitors中，此时我们已经完成了这个方法的执行。
// 所以这里用了两个数组分别存储Monitor
final int size = mMonitors.size();
for (int i = 0 ; i < size ; i++) {
synchronized (Watchdog.this) {
mCurrentMonitor = mMonitors.get(i);
}
mCurrentMonitor.monitor();
}
synchronized (Watchdog.this) {
mCompleted = true;
mCurrentMonitor = null;
}
}
// 暂停这个HandlerChecker
public void pauseLocked(String reason) {
mPauseCount++;
// Mark as completed, because there's a chance we called this after the watchog
// thread loop called Object#wait after 'WAITED_HALF'. In that case we want to ensure
// the next call to #getCompletionStateLocked for this checker returns 'COMPLETED'
mCompleted = true;
Slog.i(TAG, "Pausing HandlerChecker: " + mName + " for reason: "
+ reason + ". Pause count: " + mPauseCount);
}
// 继续这个HandlerChecker
public void resumeLocked(String reason) {
if (mPauseCount > 0) {
mPauseCount--;
Slog.i(TAG, "Resuming HandlerChecker: " + mName + " for reason: "
+ reason + ". Pause count: " + mPauseCount);
} else {
Slog.wtf(TAG, "Already resumed HandlerChecker: " + mName);
}
}
}
从注释1开始，可以看到大部分方法后缀都加上了Locked，这是因为在Watchdog调用的时候都会加上synchronize锁，保证不会发生多线程并发导致的问题。
而注释2的scheduleCheckLocked()方法在Watchdog中以间隔30s执行一次。
以下是实现了Monitor接口的类：
实现了Monitor的接口的类
<center style="font-size:13px;color:#C0C0C0;">实现了Monitor的接口的类</center>
WatchDog中比较重要的几个函数
// 设置activityController 用处在后面Watchdog的run()方法会介绍到
public void setActivityController(IActivityController controller) {
synchronized (this) {
mController = controller;
}
}
// 设置watchdog超时后是否能重启手机
public void setAllowRestart(boolean allowRestart) {
synchronized (this) {
mAllowRestart = allowRestart;
}
}
// 在FgThread中添加对monitor的监控
public void addMonitor(Monitor monitor) {
synchronized (this) {
mMonitorChecker.addMonitorLocked(monitor);
}
}
// 添加需要监控的handler 超时时间默认为60s
public void addThread(Handler thread) {
addThread(thread, DEFAULT_TIMEOUT);
}
// 添加需要监控的handler 可以自定义超时时间
public void addThread(Handler thread, long timeoutMillis) {
synchronized (this) {
final String name = thread.getLooper().getThread().getName();
mHandlerCheckers.add(new HandlerChecker(thread, name, timeoutMillis));
}
}
// 暂停当前正在运行的线程的监视操作。在执行可能错误触发watchdog的长时间运行的操作之前非常有用。
// 每个调用都需要一个匹配的{@link #resumeWatchingCurrentThread}调用。
public void pauseWatchingCurrentThread(String reason) {
synchronized (this) {
for (HandlerChecker hc : mHandlerCheckers) {
if (Thread.currentThread().equals(hc.getThread())) {
hc.pauseLocked(reason);
}
}
}
}
// 恢复watchdog的检测状态
public void resumeWatchingCurrentThread(String reason) {
synchronized (this) {
for (HandlerChecker hc : mHandlerCheckers) {
if (Thread.currentThread().equals(hc.getThread())) {
hc.resumeLocked(reason);
}
}
}
}
// 计算HandlerChecker的状态 只要一个handler中有其中一个HandlerChecker超时了
// 那Watchdog就超时了
private int evaluateCheckerCompletionLocked() {
int state = COMPLETED;
for (int i=0; i<mHandlerCheckers.size(); i++) {
HandlerChecker hc = mHandlerCheckers.get(i);
state = Math.max(state, hc.getCompletionStateLocked());
}
return state;
}
// 获取哪个HandlerChecker超时，并加入数组返回
private ArrayList<HandlerChecker> getBlockedCheckersLocked() {
ArrayList<HandlerChecker> checkers = new ArrayList<HandlerChecker>();
for (int i=0; i<mHandlerCheckers.size(); i++) {
HandlerChecker hc = mHandlerCheckers.get(i);
if (hc.isOverdueLocked()) {
checkers.add(hc);
}
}
return checkers;
}
// 获取每个超时HandlerChecker的超时原因，并组成String返回
private String describeCheckersLocked(List<HandlerChecker> checkers) {
StringBuilder builder = new StringBuilder(128);
for (int i=0; i<checkers.size(); i++) {
if (builder.length() > 0) {
builder.append(", ");
}
builder.append(checkers.get(i).describeBlockedStateLocked());
}
return builder.toString();
}
WatchDog.run()
接下来我们就看一下Watchdog的核心代码，run()方法
@Override
public void run() {
// 是否在等待的前半段时间 true则为等待的后半段时间
boolean waitedHalf = false;
// 死循环
while (true) {
final List<HandlerChecker> blockedCheckers;
// 超时原因 用于日志打印
final String subject;
// 是否允许system_server重启 默认为true
// 可以通过watchdog.setAllowRestart()重新设置值
final boolean allowRestart;
// 调试进程连接数 有的话会赋值为2
int debuggerWasConnected = 0;
synchronized (this) {
// CHECK_INTERVAL为30s
long timeout = CHECK_INTERVAL;
// 逐一执行每个HandlerChecker的scheduleCheckLocked()方法
for (int i=0; i<mHandlerCheckers.size(); i++) {
HandlerChecker hc = mHandlerCheckers.get(i);
hc.scheduleCheckLocked();
}
if (debuggerWasConnected > 0) {
debuggerWasConnected--;
}
// 这里用uptimeMillis() 是因为只会在设备唤醒的时候计算超时，
// 设备休眠计算时间会导致错误重启
long start = SystemClock.uptimeMillis();
while (timeout > 0) {
if (Debug.isDebuggerConnected()) {
debuggerWasConnected = 2;
}
try {
// 等待30s
wait(timeout);
// Note: mHandlerCheckers and mMonitorChecker may have changed after waiting
} catch (InterruptedException e) {
Log.wtf(TAG, e);
}
if (Debug.isDebuggerConnected()) {
debuggerWasConnected = 2;
}
// 有可能wait到一半的时候发生了InterruptedException 导致时间没有走完
// 只要没有消耗完timeout的值 就继续等待
timeout = CHECK_INTERVAL - (SystemClock.uptimeMillis() - start);
}
// fd是否达到了限制的数量
boolean fdLimitTriggered = false;
if (mOpenFdMonitor != null) {
fdLimitTriggered = mOpenFdMonitor.monitor();
}
// fd数量限制没有达到
if (!fdLimitTriggered) {
final int waitState = evaluateCheckerCompletionLocked();
// 都完成了的话 继续下个循环 本次循环结束
if (waitState == COMPLETED) {
waitedHalf = false;
continue;
} else if (waitState == WAITING) {
// 在等待的前半段时间 继续下个循环 本次循环结束
continue;
} else if (waitState == WAITED_HALF) {
if (!waitedHalf) {
Slog.i(TAG, "WAITED_HALF");
// 我们等了一半的死锁探测时间。
// 获取堆栈跟踪并等待另一半。
ArrayList<Integer> pids = new ArrayList<Integer>();
pids.add(Process.myPid());
ActivityManagerService.dumpStackTraces(pids, null, null,
getInterestingNativePids());
waitedHalf = true;
}
continue;
}
// 到这里的时候已经有handler超时了
// 获取超时的HandlerChecker
blockedCheckers = getBlockedCheckersLocked();
// 获取超时的HandlerChecker的信息
subject = describeCheckersLocked(blockedCheckers);
} else {
// fd数量限制达到了
blockedCheckers = Collections.emptyList();
subject = "Open FD high water mark reached";
}
allowRestart = mAllowRestart;
}
// 如果我们到这里，这意味着系统很可能挂起。
// 首先从系统进程的所有线程收集堆栈跟踪。然后杀死这个进程，
// 这样系统才会重新启动。
EventLog.writeEvent(EventLogTags.WATCHDOG, subject);
ArrayList<Integer> pids = new ArrayList<>();
pids.add(Process.myPid());
if (mPhonePid > 0) pids.add(mPhonePid);
// 打印java线程和native线程堆栈
final File stack = ActivityManagerService.dumpStackTraces(
pids, null, null, getInterestingNativePids());
// 挂起5s确保堆栈能写入到文件中
SystemClock.sleep(5000);
// 让kernel dump全部的blocked线程 和 cpu信息
doSysRq('w');
doSysRq('l');
// 尝试把error加到dropbox下，但假设ActivityManager自己会死锁
// 当这种情况发生时, 导致以下语句死锁，watchdog作为一个整体将会失效
Thread dropboxThread = new Thread("watchdogWriteToDropbox") {
public void run() {
// 如果其中一条被观察的线程在Watchdog init()方法执行前被挂起
// 我们则没有一个有效的AMS，所以不能把log打印存储到dropbox路径下
if (mActivity != null) {
mActivity.addErrorToDropBox(
"watchdog", null, "system_server", null, null, null,
subject, null, stack, null);
}
StatsLog.write(StatsLog.SYSTEM_SERVER_WATCHDOG_OCCURRED, subject);
}
};
dropboxThread.start();
try {
// 等待2s 让dropboxThread返回
dropboxThread.join(2000);
} catch (InterruptedException ignored) {}
IActivityController controller;
synchronized (this) {
controller = mController;
}
// 如果ActivityController不为null
if (controller != null) {
Slog.i(TAG, "Reporting stuck state to activity controller");
try {
// 由于挂起system process而禁用dump 防止controller在报告错误的时候被挂起
Binder.setDumpDisabled("Service dumps disabled due to hung system process.");
// 1 = keep waiting, -1 = kill system
int res = controller.systemNotResponding(subject);
if (res >= 0) {
Slog.i(TAG, "Activity controller requested to coninue to wait");
waitedHalf = false;
continue;
}
} catch (RemoteException e) {
}
}
// 只有在没有debugger连接的情况下才会杀死进程。
if (Debug.isDebuggerConnected()) {
debuggerWasConnected = 2;
}
if (debuggerWasConnected >= 2) {
Slog.w(TAG, "Debugger connected: Watchdog is *not* killing the system process");
} else if (debuggerWasConnected > 0) {
Slog.w(TAG, "Debugger was connected: Watchdog is *not* killing the system process");
} else if (!allowRestart) {
Slog.w(TAG, "Restart not allowed: Watchdog is *not* killing the system process");
} else {
Slog.w(TAG, "*** WATCHDOG KILLING SYSTEM PROCESS: " + subject);
WatchdogDiagnostics.diagnoseCheckers(blockedCheckers);
Slog.w(TAG, "*** GOODBYE!");
// 结束进程 watchdog存在于system_server进程之下
// 因为watchdog就是在system_server初始化的
Process.killProcess(Process.myPid());
System.exit(10);
}
waitedHalf = false;
}
}
文章到这里就完了，基本上只是对参考文章进行代码的上更新（Android Q），结构大致一样。仅作为学习记录用途。
