Android trouble shooting 整理(转）

转自：http://hi.baidu.com/donghaozheng/blog/item/0e0edfc8d96a54197e3e6fdb.html 

Android trouble shooting 整理2010-09-29 13:30（1） 

[ 01-01 08:39:22.016 1228:0x4cd E/AndroidRuntime ] 
java.lang.Exception: WakeLock finalized while still held: My Tag 
at android.os.PowerManager$WakeLock.finalize(PowerManager.java:337) 
at dalvik.system.NativeStart.run(Native Method) 

WakeLock finalized while still held 表示 WakeLock对象在销毁时仍然被持有。 
因为我的Activity里，只有WakeLock.acquire方法，而没有去release，所以当Activity关闭时，WakeLock仍然被持有（或着说锁着），而WakeLock作为Activity持有对象会随着Activity的销毁而销毁。 


（2） 
转屏时，系统默认会销毁当前的activity然后再重启它。 
可以配置程序只有横屏或竖屏，或者经过配置，当发生旋转时，会调用onConfigurationChanged函数。 

[ 09-27 15:41:25.009   915:0x3a2 I/WindowManager ] 
onOrientationChanged, rotation changed to 0 mBootFinished=true 

[ 09-27 15:41:25.009   915:0x3a2 I/WindowManager ] 
Setting rotation to 0, animFlags=0 

[ 09-27 15:41:25.009   915:0x3a2 I/WindowManager ] 
Config changed: { scale=0.9 imsi=0/0 loc=zh_CN touch=3 keys=1/1/2 nav=1/1 orien=1 layout=34 theme=0} 

[ 09-27 15:41:25.009   915:0x3a2 I/ActivityManager ] 
Config changed: { scale=0.9 imsi=460/0 loc=zh_CN touch=3 keys=1/1/2 nav=1/1 orien=1 layout=34 theme=0} 

[ 09-27 15:41:25.047 1028:0x404 D/GBIme    ] 
onConfigurationChanged 

[ 09-27 15:41:25.094 7405:0x1cf3 I/ActivityThread ] 
server send command to relaunch activity 

[ 09-27 15:41:25.094   915:0x3a2 I/UsageStats ] 
Unexpected resume of com.test.myapp while already resumed in com.test.myapp 

android横竖屏相关知识参考：http://java-admin.javaeye.com/blog/730863 


（3） 
adb logcat    上层的log 
cat proc/kmsg kernel的log，在运行过程中不接串口的情况下，可用此命令来查看。 

（4） 
要看各进程内存使用情况用procrank，看uss列，比ps，top命令都要准确。 
PID      Vss      Rss      Pss      Uss cmdline 
1016   78092K   44912K   23679K   20548K system_server 
1096   34552K   34552K   15191K   13268K com.lge.launcher 
1073   48852K   34560K   13192K   10276K com.android.phone 
1080   26908K   26908K    8799K    7396K android.process.omsservice 
1010   27836K   27836K    8417K    6436K zygote 

总的内存情况用cat proc/meminfo查看 
MemTotal:         514224 kB 
MemFree:          202252 kB 
Buffers:               0 kB 
Cached:           127784 kB 
SwapCached:            0 kB 
Active:           139124 kB 
Inactive:          91904 kB 
Active(anon):     103808 kB 
Inactive(anon):        0 kB 
Active(file):      35316 kB 
Inactive(file):    91904 kB 
Unevictable:           4 kB 
Mlocked:               4 kB 
SwapTotal:             0 kB 
SwapFree:              0 kB 
Dirty:                 0 kB 
Writeback:             0 kB 
AnonPages:        103260 kB 
Mapped:            43396 kB 
Slab:               4780 kB 
SReclaimable:       1576 kB 
SUnreclaim:         3204 kB 
PageTables:         8032 kB 
NFS_Unstable:          0 kB 
Bounce:                0 kB 
WritebackTmp:          0 kB 
CommitLimit:      257112 kB 
Committed_AS:    5533536 kB 
VmallocTotal:     122880 kB 
VmallocUsed:       85588 kB 
VmallocChunk:      32772 kB 

（5） 
应用产生不响应错误时进程信息会存在/data/anr/traces.txt 

（ANR：Application Not Responding） 

（6） 
adb bugreport > bugreport.txt 
含有大量信息，adb的log，kernel的log，内存信息，进程信息等等。 
信息量太大，不太好分析，目前还没用过此log解决过问题。 


（7） 
Android有一个叫Watchdog的程序，它会监视system进程的内存使用情况， 
如果内存使用量超过某个值（比如：20MB）的话，就会把它杀死，然后重启该进程。 
在system进程被杀掉的时候，往往许多其他进程也会随之挂掉，部分重要进程会重启。 

Log1： 
[ 08-02 13:19:43.311   949:0x400 E/AndroidRuntime ] 
*** EXCEPTION IN SYSTEM PROCESS. System will crash. 

[ 08-02 13:19:43.311   949:0x400 E/AndroidRuntime ] 
java.lang.OutOfMemoryError 
         at android.os.Parcel.marshall(Native Method) 
         at com.android.internal.os.BatteryStatsImpl.writeLocked(BatteryStatsImpl.java:3053) 
         at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1742) 
         at com.android.server.am.ActivityManagerService$3.run(ActivityManagerService.java:1642) 

[ 08-02 13:19:43.311   949:0x400 W/Process ] 
killProcess pid=949 
java.lang.RuntimeException 
         at android.os.Process.killProcess(Process.java:730) 
         at com.android.internal.os.RuntimeInit.crash(RuntimeInit.java:374) 
         at com.android.internal.os.RuntimeInit$UncaughtHandler.uncaughtException(RuntimeInit.java:76) 
         at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:887) 
         at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:884) 

[ 08-02 13:19:43.311   949:0x400 I/Process ] 
Sending signal. PID: 949 SIG: 9 


Log2： 
[ 08-02 21:12:01.665 1002:0x41b I/Watchdog ] 
Watchdog is killing the system process 

[ 08-02 21:12:01.665 1002:0x41b W/Process ] 
killProcess pid=1002 
java.lang.RuntimeException 
    at android.os.Process.killProcess(Process.java:730) 
    at com.android.server.Watchdog.run(Watchdog.java:854) 

[ 08-02 21:12:01.665 1002:0x41b I/Process ] 
Sending signal. PID: 1002 SIG: 9 

[ 08-02 21:12:01.680   885:0x375 I/Zygote   ] 
Exit zygote because system server (1002) has terminated 

[ 08-02 21:12:01.878   879:0x36f I/ServiceManager ] 
service 'videophone' died 

[ 08-02 21:12:01.878   879:0x36f I/ServiceManager ] 
service 'phone' died 


system进程是Android的核心进程， 
package名称为Android 
启动起来以后的进程名为"system" 
源码为system/framework/framework-res.apk 
数据存放目录为data/system 
adb里用ps命令看到的名称为system_server 
DDMS中看到的名称为system_process 


（8） 

DDMS Heap监控功能：可监视任意进程的堆信息，包含哪些数据类型，及各种类型的数据量大小，实时刷新。 


以下方法获取某个进程的heap dump（多用于内存泄漏问题） 

Please capture heap dump file as below steps. 

1. Heap dump file is stored at /data/misc. It is necessary to change its permission first. 
# chmod 777 /data/misc 
2. A signal is sent to Dalvik VM, and heap dump with filename as heap-dump-xxx-pid<pid>.hprof is generated at /data/misc. <pid> 

here is system_server pid. 
# kill -10 <pid> 
3. To pull hprof out of device 
$ adb pull /data/misc/heap-dump-xxx-pid<pid>.hprof . 

使用命令hprof-conv（SDK tools中带有）把hprof转成MAT识别的标准的hprof 

　　$ $ANDROID_SRC/out/host/linux-x86/bin/hprof-conv input.hprof output.hprof 

然后可利用Memory Analyzer Tool去分析 


（9） 

用kill -3 <pid> 可立即将该进程的各线程的callstack保存到log中 

#ps 

app_41    1041 853   208428 24296 ffffffff afe0dcc4 S com.guobi.gbime 

#kill -3 1041 

#logcat 
可找到如下信息 
I/dalvikvm( 1041): threadid=7: reacting to signal 3 
I/dalvikvm( 1041): Wrote stack trace to '/local/log/anr/traces.txt' 


----- pid 1041 at 2010-01-01 12:21:51 ----- 
Cmd line: com.guobi.gbime 

DALVIK THREADS: 
"main" prio=5 tid=3 WAIT 
| group="main" sCount=1 dsCount=0 s=N obj=0x40023258 self=0xbdb0 
| sysTid=1041 nice=0 sched=0/0 cgrp=unknown handle=-1343997288 
at java.lang.Object.wait(Native Method) 
- waiting on <0x139168> (a android.os.MessageQueue) 
at java.lang.Object.wait(Object.java:288) 
at android.os.MessageQueue.next(MessageQueue.java:148) 
at android.os.Looper.loop(Looper.java:110) 
at android.app.ActivityThread.main(ActivityThread.java:4436) 
at java.lang.reflect.Method.invokeNative(Native Method) 
at java.lang.reflect.Method.invoke(Method.java:521) 
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:876) 
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:621) 
at dalvik.system.NativeStart.main(Native Method) 

"Thread-8" prio=5 tid=15 TIMED_WAIT 
| group="main" sCount=1 dsCount=0 s=N obj=0x47afa500 self=0x152740 
| sysTid=1097 nice=0 sched=0/0 cgrp=unknown handle=606880 
at java.lang.VMThread.sleep(Native Method) 
at java.lang.Thread.sleep(Thread.java:1306) 
at com.guobi.gbime.lang.UDBThread.run(UDBThread.java:23) 

"Binder Thread #2" prio=5 tid=13 NATIVE 
| group="main" sCount=1 dsCount=0 s=N obj=0x47afbd00 self=0x14ff50 
| sysTid=1061 nice=0 sched=0/0 cgrp=unknown handle=1376016 
at dalvik.system.NativeStart.run(Native Method) 

"Binder Thread #1" prio=5 tid=11 NATIVE 
| group="main" sCount=1 dsCount=0 s=N obj=0x47afbc40 self=0x14b9f8 
| sysTid=1056 nice=0 sched=0/0 cgrp=unknown handle=1358240 
at dalvik.system.NativeStart.run(Native Method) 

"JDWP" daemon prio=5 tid=9 VMWAIT 
| group="system" sCount=1 dsCount=0 s=N obj=0x47af92a0 self=0x14b7c8 
| sysTid=1045 nice=0 sched=0/0 cgrp=unknown handle=1353224 
at dalvik.system.NativeStart.run(Native Method) 

"Signal Catcher" daemon prio=5 tid=7 RUNNABLE 
| group="system" sCount=0 dsCount=0 s=N obj=0x47af91e8 self=0x14b1b0 
| sysTid=1044 nice=0 sched=0/0 cgrp=unknown handle=1274872 
at dalvik.system.NativeStart.run(Native Method) 

"HeapWorker" daemon prio=5 tid=5 VMWAIT 
| group="system" sCount=1 dsCount=0 s=N obj=0x44dbbe88 self=0x14ad40 
| sysTid=1043 nice=0 sched=0/0 cgrp=unknown handle=1353384 
at dalvik.system.NativeStart.run(Native Method) 

----- end 1041 ----- 

看过几个log，其中都有"main" "Binder Thread #2" "Binder Thread #1" "JDWP" "Signal Catcher" "HeapWorker" 这几个线程， 
个人理解：main 是主线程，进行消息循环，几乎都是一样的，waiting在消息队列上。 
Binder Thread #1和2 不清楚， JDWP 是java代码调试用的，Signal Catcher用来接收处理signal的，HeapWorker不太清楚，看字面意思与堆操作相关。 

若要分析这个文件，应着重看这几个之外的线程，再就是HeapWorker线程。 

也可以修改该log生成的位置，通过setprop命令 

setprop -help 
usage: setprop <key> <value> 

adb shell setprop dalvik.vm.stack-trace-file /tmp/stack-traces.txt