系统异常埋点
2015-07-10 17:42
274 查看
DropBoxManager会在以下时机抓取相关信息:
a、出异常关机前
SystemServer会收集以下类型报错:watchdog、anr、wtf、lowmem、native_crash、crash
TAG = watchdog、anr、wtf、lowmem、native_crash、crash
此时是通过ActivityManagerService.addErrorToDropBox()接口来收集信息并添加到DropBox中,可在addErrorToDropBox()中做拦截以抓取更多的日志:
b、原生对/data/tombstones目录注册了一个观察者
TAG = SYSTEM_TOMBSTONE
如果系统抛一个tombstone未导致关机,那么就会将此次报错add到DropBox中,这是通过DropBoxManager.addText()接口添加信息到DropBox中的。
这个逻辑在frameworks/base/core/java/com/android/server/BootReceiver.java文件中。
c、frameworks/base/core/java/com/android/server/BootReceiver.java中存在开机后抓取异常信息的逻辑
整机重启后(Kernel和Flyme):TAG = SYSTEM_BOOT
Flyme重启: TAG = SYSTEM_RESTART
从Recovery启动: TAG = SYSTEM_RECOVERY_LOG
开机扫描/data/tombstones目录:TAG = SYSTEM_TOMBSTONE
开机后原生逻辑已经抓取了一些信息,但不够多和细。
建议:
在SYSTEM_BOOT时,不用抓什么日志,因为整机重启,所有信息被冲掉;
在SYSTEM_RESTART时,可尝试抓取Android和kernel日志,这时可能会抓取到有用信息,但是由于开机已经有一段时间了,异常日志可能已被冲掉;
在SYSTEM_RECOVERY_LOG时,这个按原生的来就行;
a、出异常关机前
SystemServer会收集以下类型报错:watchdog、anr、wtf、lowmem、native_crash、crash
TAG = watchdog、anr、wtf、lowmem、native_crash、crash
此时是通过ActivityManagerService.addErrorToDropBox()接口来收集信息并添加到DropBox中,可在addErrorToDropBox()中做拦截以抓取更多的日志:
12883 public void addErrorToDropBox(String eventType, 12884 ProcessRecord process, String processName, ActivityRecord activity, 12885 ActivityRecord parent, String subject, 12886 final String report, final File logFile, 12887 final ApplicationErrorReport.CrashInfo crashInfo) { 12888 // NOTE -- this must never acquire the ActivityManagerService lock, 12889 // otherwise the watchdog may be prevented from resetting the system. 12890
b、原生对/data/tombstones目录注册了一个观察者
TAG = SYSTEM_TOMBSTONE
如果系统抛一个tombstone未导致关机,那么就会将此次报错add到DropBox中,这是通过DropBoxManager.addText()接口添加信息到DropBox中的。
sTombstoneObserver = new FileObserver(TOMBSTONE_DIR.getPath(), FileObserver.CLOSE_WRITE) { @Override public void onEvent(int event, String path) { try { File file = new File(TOMBSTONE_DIR, path); if (file.isFile()) { addFileToDropBox(db, prefs, headers, file.getPath(), LOG_SIZE, "SYSTEM_TOMBSTONE"); } } catch (IOException e) { Slog.e(TAG, "Can't log tombstone", e); } } };
这个逻辑在frameworks/base/core/java/com/android/server/BootReceiver.java文件中。
c、frameworks/base/core/java/com/android/server/BootReceiver.java中存在开机后抓取异常信息的逻辑
整机重启后(Kernel和Flyme):TAG = SYSTEM_BOOT
Flyme重启: TAG = SYSTEM_RESTART
从Recovery启动: TAG = SYSTEM_RECOVERY_LOG
开机扫描/data/tombstones目录:TAG = SYSTEM_TOMBSTONE
开机后原生逻辑已经抓取了一些信息,但不够多和细。
建议:
在SYSTEM_BOOT时,不用抓什么日志,因为整机重启,所有信息被冲掉;
在SYSTEM_RESTART时,可尝试抓取Android和kernel日志,这时可能会抓取到有用信息,但是由于开机已经有一段时间了,异常日志可能已被冲掉;
在SYSTEM_RECOVERY_LOG时,这个按原生的来就行;
相关文章推荐
- mybatis ---- 级联查询 一对多 (集合映射)
- 使用libcurl库把域名转化IP
- 二维数组最大面积的问题(动态规划)
- 网速慢的原因和解决方案
- 360或其他双核浏览器下在兼容模式用chrome内核渲染的方法
- Android、IOS开发思路及项目文件结构
- iOS 中的 NSTimer
- 个人常用iOS第三方库以及XCode插件介绍
- C++ primer 5 笔记1 chapter 1 begin
- POJ 2106 Boolean Expressions(模拟+LL1)
- Oracle-BPM(三)
- ViewAnimator 之(二)ViewFlipper
- WebStorage当做简单数据库
- ThreadLocal
- 快速备份和还原 MySQL 数据库的另一种方法
- 在引入的css或者js文件后面加参数的作用
- 360或其他双核浏览器下在兼容模式用chrome内核渲染的方法
- mongdb性能优化收集
- Redis持久化配置
- MongoDB数据库的备份,恢复与迁移,回滚 (优秀)