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