Android问题定位总结_android内核异常堆栈gdb定位

•     ANR问题
原因是：当前进程的ui主线程被阻塞了或处理一些耗时的任务，可以参考google sdk的详细介绍：http://developer.android.com/guide/practices/responsiveness.html里面有anr类型的介绍及其如何从设计上避免ANR问题。
常见包括
1.调用了阻塞函数
2.主线程处理的任务太耗时
3.死锁
4. cpu占用率过高（iowait过高）
在ddms的log中搜索ANR关键字或者/data/system/dropbox找anr字段的文件或者找刚发生问题时/data/anr目录下的trace.txt文件。在J版本上google在bugreport里面也增加更多的手段定位anr问题：1. dumpsys window lastanr 2. 在c++层按键分发的时候也记录了一些信息，可以搜索：Input Dispatcher State at time of last ANR。定位anr问题关键是：一是看cpu占用率，二是看发生问题apk的主线程正在做什么。   如果cpu占用率很高，首先需要弄清楚那个进程在使用cpu，可以通过anr文件看到；也可能需要动态查看系统调用栈，比如adb shell debuggerd -b 进程号 >D:\trace01.txt

参考资料：https://sites.google.com/a/itspaclub.com/www/android-debug/6-how-to-debug-anr
•     system server watchdog问题
Android framework中实现了一个软件狗，可以参考frameworks\base\services\java\com\android\server\Watchdog.java。
基本思想是：通过一个Timer不断检测各个核心service实现的Monitor接口monitor函数，如果此函数长期不返回，则watchdog将kill掉system_server，手机发生重启。查看watchdog检测了那些service，可以搜索Watchdog.getInstance().addMonitor。另外涉及watchdog的两个线程是watchdog和android.server.ServerThread，watchdog负责kill整个系统，monitor函数在ServerThread线程上执行。
发生watchdog的时候在ddms log中会打印；
4.4之后取android.server.ServerThread被"android.fg"代替
Slog.w(TAG, "*** WATCHDOG KILLING SYSTEM PROCESS: " + name);
并且在/data/system/dropbox目录里面生成的watchdog字段的文件，
里面有发生问题的时候各个线程栈。
导致watchdog原因主要有：
1. java线程死锁这个可以从生成的watchdog文件中看到。
2. 调用一些系统调用内核不返回
3. 同另外一个进程通信，另外一个进程不返回（常见的包括vold，Surfaceflinger）
针对后两种原因，可以先从watchdog找到出问题的线程，然后从代码角度分析一下。
对于那些可以复现的问题，可以修改Watchdog.java文件，删除
     Process.killProcess(Process.myPid());
     System.exit(10);
这两句话，编译services.jar，复现后手机将不会重启，进入冻屏状态，
•     tombstone问题
当C/C++代码发生内存访问错误等一些异常的时候，会导致的进程直接终止。如c代码访问空指针了。
google通过一个debuggerd的daemon进程，收集系统发生各种异常信号，如SIGSEGV,SIGBUS等信号，
当捕获到这些信号后，它通过ptrace系统调用，获取发生问题时候的调用栈信息，存放在
/data/tombstones/, framework中通过FileObserver将次目录的文件压缩到/data/system/dropbox目录，
生成tombstone字段的文件。通过这里面的信息，可以看到出问题的时候堆栈信息及其寄存器的值。
分析tombstone问题，首先学习如何反汇编。
另外定位此问题的方法是打开core dump功能，core dump功能是linux标准的一个方法，然后通过gdb进行调试。
https://sites.google.com/a/itspaclub.com/www/android-debug/7-how-to-debug-native-code
•     kernel重启或modem重启
对于应用层来说，也行不要求我们去定位内核重启问题和arm9问题。
但我们必须能够区分出是否是上层问题。对于android层重启来说，其实质就是system_server, zygote,surfaceflinger（I版本以后）
系统核心进程的重新启动。
1. 根据启动显示的界面进行判断，android层重启，只会播放开机动画，而不会出现logo界面。
   开机动画显示的huawei log是一个动态图片。如果看到静态的logo，应该是整机重启。
2. 根据后台抓取的log进行判断，如果开启后台log，会在/mnt/sdcard/bugreports目录下生成很多applogcat-log文件，打开所有的文件，搜索/dev/log关键字
   如果有，查看启动前后的log，看system_server进程号有没有变的很大，如果变的很大（>1000）,则应该是android层重启
3. 查看/data/system/dropbox目录下是否有最新生成的RESTART文件，如果有，通过将数字转为日期，看看是否最新生成。
4. 通过重启后抓取的bugreport文件进行判断，搜索system_server看进程号有没有变的很多或dropbox看有没有重启相关信息
•     5. 另外判断是否为整机重启的简单可靠的方法是：
手机发生重启后，进入Settings->关于手机->状态信息->已开机时间：
如果时间非常小，基本可以判断是整机重启。
1.2 异常相关的log目录  
/data/anr
/data/system/dropbox
/data/dontpanic/
/data/tombstones/
1.3 注意事项  
•     弄清楚当前死机发生的时间
•     确认死机的类型
•     这些方法和技巧能够帮助快速定位出现问题的原因，但问题的真正解决，还需要大家对业务流程的熟练掌握