一、ANR日志生成过程
以Input ANR为例来分析下anr日志的生成过程：
input触发anr之后会通过InputManagerService执行notifyANR，最终交由ActivityManagerService来处理，ActivityManagerService执行appNotResponding是ANR处理的核心位置，通过AppErrors，最终在ActivityManagerService分别干了三件事：
- 写trace到/data/anr/traces.txt。
- 写trace和cpu usage信息到/data/system/dropbox/，然后发送响应广播。
- 发送ANR广播，执行ANR弹窗。
详细四大组件+Input触发ANR流程参考之前文章：Android ANR（二）-触发原理
二、ANR日志收集方式
2.1 低版本：FileObserver+ProcessErrorStateInfo
ProcessErrorStateInfo 获取cause reason
ActivityManager am = (ActivityManager) ctx.getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.ProcessErrorStateInfo> processErrorList = am.getProcessesInErrorState();
if (processErrorList != null) {
for (ActivityManager.ProcessErrorStateInfo errorStateInfo : processErrorList) {
if (errorStateInfo.pid == pid && errorStateInfo.condition == ActivityManager.ProcessErrorStateInfo.NOT_RESPONDING) {
//这两部分构成 cause reason
Log.d("xcrashtest", "shortMsg: " + errorStateInfo.shortMsg);
Log.d("xcrashtest", "longMsg: " + errorStateInfo.longMsg);
return true;
}
}
这是AMS对外暴露的api，从AMS的mLruProcesses中过滤出crash和anr异常的进程，返回对应的错误信息，详细逻辑如下：
ActivityManagerService.java
public List<ActivityManager.ProcessErrorStateInfo> getProcessesInErrorState() {
enforceNotIsolatedCaller("getProcessesInErrorState");
// assume our apps are happy - lazy create the list
List<ActivityManager.ProcessErrorStateInfo> errList = null;
final boolean allUsers = ActivityManager.checkUidPermission(INTERACT_ACROSS_USERS_FULL,
Binder.getCallingUid()) == PackageManager.PERMISSION_GRANTED;
int userId = UserHandle.getUserId(Binder.getCallingUid());
synchronized (this) {
// iterate across all processes
for (int i=mLruProcesses.size()-1; i>=0; i--) {
ProcessRecord app = mLruProcesses.get(i);
if (!allUsers && app.userId != userId) {
continue;
}
if ((app.thread != null) && (app.crashing || app.notResponding)) {
// This one's in trouble, so we'll generate a report for it
// crashes are higher priority (in case there's a crash *and* an anr)
ActivityManager.ProcessErrorStateInfo report = null;
if (app.crashing) {
report = app.crashingReport;
} else if (app.notResponding) {
report = app.notRespondingReport;
}
if (report != null) {
if (errList == null) {
errList = new ArrayList<ActivityManager.ProcessErrorStateInfo>(1);
}
errList.add(report);
} else {
Slog.w(TAG, "Missing app error report, app = " + app.processName +
" crashing = " + app.crashing +
" notResponding = " + app.notResponding);
}
}
}
}
return errList;
}
这里如果是anr，report = app.notRespondingReport，notRespondingReport初始化的地方在AppErrors.appNotResponding中调用的makeAppNotRespondingLocked。
FileObserver来监听/data/anr/目录下对应的trace文件，来读取相关的trace信息。
FileObserver的使用：
fileObserver = new FileObserver("/data/anr/", CLOSE_WRITE) {
public void onEvent(int event, String path) {
//监听回调处理anr
}
}
};
fileObserver.startWatching();//启动监听
fileObserver.stopWatching();//停止监听
FileObserver的startWatching是交给内部的ObserverThread来处理的，最终执行的startWatching是个native方法：
static jint android_os_fileobserver_startWatching(JNIEnv* env, jobject object, jint fd, jstring pathString, jint mask)
{
int res = -1;
#if defined(__linux__)
if (fd >= 0)
{
const char* path = env->GetStringUTFChars(pathString, NULL);
//fd :inotify_init的返回值
//path:要监控的文件路径
//mask:监听文件的哪些事件
//res: 表示对那个文件的监视
res = inotify_add_watch(fd, path, mask);
env->ReleaseStringUTFChars(pathString, path);
}
#endif
return res;
}
inotify是文件系统变化通知机制，在监听到文件系统变化后，会向相应的应用程序发送事件。
该方案因为高版本文件权限的问题，目前只支持<=21的版本。
SELinux(或SEAndroid)将app划分为主要三种类型(根据user不同，也有其他的domain类型)：
- untrusted_app：第三方app，没有android平台签名，没有system权限
- platform_app：有android平台签名，没有system权限
- system_app：有android平台签名和system权限
2.2 高版本：native 注册 SIGNAL_QUIT 信号，ANR发生时接收回调去收集ANR信息
高版本能使用的原因是捕获SIGNAL_QUIT只能基于ART。
接收回调之后，art dump出trace信息，具体anr日志抓取可以参考xcrash的源码: xc_trace.c xc_trace_dumper线程。
对ANR 日志的获取主流方案就是如上两种，Xcrash 和Bugly都是使用的这两种方式。
2.3 ANR-WatchDog
ANR-WatchDog是仿Android WatchDog机制起个单独线程向主线程发送一个变量+1操作，自我休眠自定义ANR的阈值，休眠过后判断变量是否+1完成，如果未完成则告警。有个明显问题是，发送+1 消息的时机可能错过ANR现场，从而抓不到现场堆栈信息。
这方案只是提供了一个新思路，并不能稳定获取到anr线程堆栈信息。
