dumpstate는 안드로이드 시스템의 정보를 로그로 만들어준다.
>adb shell dumpstate
나
>adb shell bugreport
로 확인할 수 있는데, 발생한 문제를 확인하는데 큰 도움이 될 수 있다. 그럼 어떤 정보가 있는지 한번 확인해보자.
요약정보
빌드 번호와 커널 정보 등으로 시작되는 부분을 요약정보라고 부르겠다. 하드웨어 레벨의 메모리와 CPU 정보도 보인다. 여기서 물리적 메모리 사이즈와 CPU 코어의 갯수나 속도 등을 확인할 수 있다.
------ MEMORY INFO (/proc/meminfo) ------ ... ------ CPU CORE INFO ------ ...
PROCESSES
대부분은 하드웨어나 커널 정보이므로 어플리케이션 개발자에게는 큰 도움이 되지 않는다. 하지만, 프로세스 목록은 유용하다.
------ PROCESSES (ps -P --abi) ------ USER PID PPID VSIZE RSS PCY WCHAN PC ABI NAME ... u0_a147 18350 3170 1627032 44260 bg SyS_epoll_ 0000000000 S com.android.calendar ...
여기서 package name을 기준으로 프로세스 아이디(PID)를 찾을 수 있다. 위 예제에서 구글 캘린더(com.android.calendar)의 프로세스 아이디(PID)는 18350이다. PID는 한 번 앱이 실행되어 프로세스가 될 때마다 부여되는 고유번호이다. 로그를 확인할 때 PID를 기준으로 탐색하면 유용하다. 프로세스가 종료 후 재실행 되었다면, PID가 2개 이상일 수도 있다.
로그
시간 순으로 남는 로그는 커널 로그, 시스템 로그, 이벤트 로그, 라디오 로그로 크게 4종류다.
------ KERNEL LOG (dmesg) ------ ... ------ SYSTEM LOG (logcat -v threadtime -d *:v) ------ ... ------ EVENT LOG (logcat -b events -v threadtime -d *:v) ------ ...
이 중 커널로그는 uptime을 기준으로 상대적인 시간 정보와 함께 로그가 남고, 시스템 로그와 이벤트 로그는 사용자 시간 기준으로 로그가 남는다.
일반적인 어플리케이션 개발자라면 시스템 로그를 통해 대부분의 문제를 해결할 것이다.
SYSTEM LOG
어플리케이션에서 android.util.Log 클래스를 통해 남긴 로그는 여기에 남는다. 실행되는 모든 어플리케이션이 여기에 로그를 남길 수 있기 때문에 로그의 양이 상당이 많다.
------ SYSTEM LOG (logcat -v threadtime -d *:v) ------
--------- beginning of main
...
12-28 15:31:16.251 17746 17746 D InjectionManager: InjectionManager
12-28 15:31:16.251 17746 17746 D InjectionManager: fillFeatureStoreMap com.samsung.faceservice
12-28 15:31:16.251 17746 17746 I InjectionManager: Constructor com.samsung.faceservice, Feature store :{}
12-28 15:31:16.251 17746 17746 I InjectionManager: featureStore :{}
...
로그는 각 줄마다 로그 발생 시간과 PID, TID, 로그 레벨, TAG, 사용자 메시지가 표시된다.
로그 레벨은 Log 클래스에 표시되어 있다.
... /** * Priority constant for the println method; use Log.v. */ public static final int VERBOSE = 2; /** * Priority constant for the println method; use Log.d. */ public static final int DEBUG = 3; /** * Priority constant for the println method; use Log.i. */ public static final int INFO = 4; /** * Priority constant for the println method; use Log.w. */ public static final int WARN = 5; /** * Priority constant for the println method; use Log.e. */ public static final int ERROR = 6; /** * Priority constant for the println method. */ public static final int ASSERT = 7; ...
또한 어플리케이션이 죽을 때 발생하는 Exceptiion이나 Error 정보도 볼 수 있다. 시중에 logcat을 보는 프로그램이나 앱이 많이 나와있는데, 모두 이부분을 파싱하여 각 정보별로 나누어 보기좋게 해준다. 또한, PID나 TID, TAG나 내용 별로 필터링하여 보여주는 기능도 대부분 제공한다.
사용자가 앱을 사용하는 히스토리는 여기에만 남기 때문에 debugging을 위해서는 로그를 잘 남기는 것이 중요하다.
EVENT LOG
다음과 같은 메시지로 시작하는 로그다. android.util.EventLog 쓰면 여기에 남는다. 시스템 레벨의 이벤트(가비지 콜렉션, 액티비티 매니저 상태, 시스템 와치독 등)가 남는다.
------ EVENT LOG (logcat -b events -v threadtime -d *:v) ------
이벤트 로그의 태그는 단말 내에 저장된 /system/etc/event-log-tags 파일을 참조하면 된다.
어플리케이션 개발자 보다는 시스템 담당자를 위한 정보라고 하지만, 어플리케이션 개발자도 유용한 정보를 얻을 수 있다. 대표적으로는, ANR이나 F/C(Force Close) 정보다.
ANR은 “am_anr”, F/C는 “am_crash”라는 태그로 검색하면 쉽게 로그에 당시의 기록이 남아있는지, 있다면 문제가 발생한 위치가 어디인지 확인할 수 있다. 참고로, 여기서 “am”이라는 prefix는 Activity Manager를 가리킨다.
VM TRACES JUST NOW
dumpstate 로그가 만들어질 시간의 PID 기준의 VM 정보를 보여준다.
------ VM TRACES JUST NOW (/data/anr/traces.txt.bugreport: 2015-12-31 10:59:13) ------ ...
스레드 정보 뿐 아니라 어플리케이션에 관한 상당히 상세한 정보(가 함께 남는다.
----- pid 12715 at 2015-12-31 10:59:03 ----- Cmd line: system_server ... ABI: 'arm64' Build type: optimized Zygote loaded classes=4083 post zygote classes=5361 Intern table: 84649 strong; 16061 weak ...
VM TRACES AT LAST ANR
ANR 데이터가 표시된다. ANR 문제가 아니라면 다음처럼 비어있을 것이다.
*** NO ANR VM TRACES FILE (/data/anr/traces.txt): No such file or directory
만약 ANR이라면, 다음과 같이 ANR이 발생한 어플리케이션의 정보와 콜스택이 나온다.
------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2015-10-29 16:10:09) ------ ...
많은 정보가 나오지만 ANR은 메인 스레드(일명, UI 스레드)가 오랫동안 잡혀있을 때 발생하는 것이기 때문에, “main” 스레드의 콜스택부터 확인하면 된다.
ANR에 대한 다른 내용은 지난 글을 참조하자.
TOMBSTONES
묘비(tombstone)라는 뜻으로, VM 안에서 문제가 발생한 경우에는 다음처럼 비어있다.
*** NO TOMBSTONES to dump in /data/tombstones
네이티브(native) 쪽에서 에러가 발생한 경우에는 문제가 발생한 어플리케이션의 정보와 메모리 정보, 스택, 함께 문제가 발행한 네이티브 코드 정보가 표시된다. 하지만, 어플리케이션 개발자는 단말의 바이너리를 직접 빌드하지 않기 때문에 소스를 볼 수 없어 문제 원인을 직접 확인할 수는 없는 경우가 많다. Tombstones 분석에 대해서는 이 글을 참조하자.
NETWORK DEV INFO
단말에 설치된 어플리케이션은 네트워크를 대부분 쓴다. 이 네트워크에 문제가 생기는 경우에 대한 문제 분석이 쉽지 않은데, 패킷 교환이 원활했는지 이부분으로 확인할 수 있다.
다음은 WiFi 상태가 원활한 경우다.
------ NETWORK DEV INFO (/proc/net/dev) ------ Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed ... wlan0: 23192305 17498 0 0 0 0 0 465 1113708 12689 0 0 0 0 0 0 ...
원활하지 못한 경우는 error나 drop이 발생할 수 있다. 다음처럼 말이다.
------ NETWORK DEV INFO (/proc/net/dev) ------ Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed ... wlan0: 8253341 6519 0 0 0 0 0 0 355420 4585 0 2 0 0 0 0 ...
drop은 패킷은 단말에 도착하였으나, driver에서 버린 경우로 보통 버퍼가 없을 때 발생한다.
POWER ON INFO
단말이 켜지고 나서 중요한 시스템 서비스나 이벤트가 발생한 시간도 알 수 있다.
------ POWER ON INFO (/proc/boot_stat) ------ boot event time (ms) delta ----------------------------------------------------- !@Boot: start init process : 2654 0 !@Boot: Begin of preload() : 5985 3331 !@Boot: End of preload() : 7165 1180 !@Boot: Entered the Android system server! : 7306 141 !@Boot: Start PackageManagerService : 7876 570 !@Boot: End PackageManagerService : 10827 2951 !@Boot: Loop forever : 14127 3300 !@Boot: performEnableScreen : 16245 2118 !@Boot: Enabling Screen! : 17214 969 !@Boot: bootcomplete : 17307 93 !@Boot: Voice SVC is acquired : 26974 9667 !@Boot: Data SVC is acquired : 53278 26304 !@Boot_SVC : PhoneApp OnCrate : 0 -53278 !@Boot_SVC : RIL_UNSOL_RIL_CONNECTED : 16850 16850 !@Boot_SVC : setRadioPower on : 17516 666 !@Boot_SVC : setUiccSubscription : 17976 460 !@Boot_SVC : SIM onAllRecordsLoaded : 18596 620 !@Boot_SVC : RUIM onAllRecordsLoaded : 0 -18596 !@Boot_SVC : setupDataCall : 53039 53039
단말이 켜진 직 후 어떤 작업을 하고자 할 때, ACTION_BOOT_COMPLETED를 브로드캐스트를 통해 처리하므로 참고할만 하다.
NETWORK DIAGNOSTICS
네트워크 진단 정보도 남는다.
------ NETWORK DIAGNOSTICS (dumpsys connectivity --diag) ------
NetworkDiagnostics:ifaces{wlan0} index{14} network{502} nethandle{2156090018526}
ICMPv4 dst{8.8.8.8} src{192.168.2.51:2}: FAILED: 0/16 (4824ms)
ICMPv4 dst{192.168.2.1} src{192.168.2.51:1}: SUCCEEDED: 1/2 (515ms)
DNS UDP dst{8.8.8.8} src{192.168.2.51:43184} qtype{1} qname{431806-android-ds.metric.gstatic.com}: FAILED: 0/8 (3998ms)
NetworkDiagnostics:ifaces{} index{null} network{501} nethandle{2151795051230}
[dumpsys: 4.929s elapsed]
로그에서는 구글의 공개된 DNS 서버(8.8.8.8)를 찾는데 16번이나 시도했지만 실패했다. 그리고, 192.168.2.1에 연결하는데도 2번 시도 중 두번 째만에 성공했으며 내부 네트워크 IP 주소인데 515ms나 걸렸다.
깔끔하게 연결된다면 아래와 같은 로그가 남을 것이다.
------ NETWORK DIAGNOSTICS (dumpsys connectivity --diag) ------
NetworkDiagnostics:ifaces{wlan0} index{10} network{502} nethandle{2156090018526}
ICMPv4 dst{192.168.42.1} src{192.168.42.140:1}: SUCCEEDED: 1/1 (8ms)
ICMPv4 dst{8.8.8.8} src{192.168.42.140:2}: SUCCEEDED: 1/1 (73ms)
DNS UDP dst{192.168.42.1} src{192.168.42.140:42325} qtype{1} qname{198703-android-ds.metric.gstatic.com}: SUCCEEDED: 1/1 NOERROR (215ms)
DNS UDP dst{8.8.8.8}: FAILED: android.system.ErrnoException: connect failed: EAFNOSUPPORT (Address family not supported by protocol) (0ms)
모든 연결 시도가 1번 시도에 연결되었고, 걸린 시간도 각각 8ms와 73ms로 속도가 빠르다.
SYSTEM PROPERTIES
단말 내에서 전역(global)으로 접근이 가능한 속성값들을 보여준다. 상수 뿐 아니라, 메모리 크기나 ip 주소, usim 정보 등도 가지고 있다.
여기에 대해서는 이전에 작성한 글을 살펴보자.
FILESYSTEMS & FREE SPACE (df)
파일 시스템 정보와 공간을 보여준다. PackageManager를 통해 앱을 설치할 때, 용량이 부족하여 실패하는 경우가 있다. 이 때 PackageManager는 이 때 INSTALL_FAILED_INSUFFICIENT_STORAGE(-4)를 반환한다. 정말 단말에 여유 공간이 없는지 여기도 확인해보자.
------ FILESYSTEMS & FREE SPACE (df) ------ Filesystem Size Used Free Blksize /dev 918.8M 120.0K 918.7M 4.0K /sys/fs/cgroup 918.8M 12.0K 918.8M 4.0K /mnt 918.8M 0.0K 918.8M 4.0K /mnt/secure 918.8M 0.0K 918.8M 4.0K /system 2.9G 2.8G 26.4M 4.0K /efs 15.7M 2.2M 13.4M 4.0K /cache 192.8M 684.0K 192.2M 4.0K /data 11.1G 1.7G 9.3G 4.0K ... *** df: Exit code 1 [df: 0.027s elapsed]
“DUMPSYS : Android Framework Services”
dumpsys는 안드로이드 시스템 서비스들의 상태를 알 수 있는 명령어이다. dumpsys를 통해 CPU, RAM, 배터리, 저장공간 정보 등을 쉽게 확인할 수 있다. adb 커맨드를 이용하는 경우 다음의 명령어로 실행할 수 있다.
>adb shell dumpsys
출력되는 dumpsys 상단에 시스템 서비스의 목록이 나오고, 그 다음에 목록 순서대로 서비스별 정보가 나온다.
Currently running services: accessibility account activity alarm appwidget audio backup battery batteryinfo clipboard connectivity content cpuinfo device_policy devicestoragemonitor diskstats dropbox entropy hardware input_method iphonesubinfo isms location media.audio_flinger media.audio_policy media.player meminfo mount netstat network_management notification package permission phone power reboot screenshot search sensor simphonebook statusbar telephony.registry throttle usagestats vibrator wallpaper wifi window
여기를 잘 확인하면 문제가 발생했을 때 당시의 상태를 알 수 있다. 로그가 26만줄인 로그에서 13만줄 정도가 dumpsys 정보일 정도로 엄청난 양을 자랑하며 그 내용도 많다. 서비스에 따라 최근 몇 건의 기록을 로그성으로 남기는 경우도 있고, dumpstate 로그가 저장될 당시의 정보만 저장하는 경우도 있다.
참고로, 안드로이드 시스템 뿐 아니라, (당연하지만) 제조사에서도 정보를 남길 수 있다.
DUMP OF SERVICE activity
자주보게 되는 부분 중 하나로, 컴포넌트 들의 등록 상태와 현재 화면에 표시되거나 표시되었던 히스토리 등을 확인할 수 있다. 아래와 같은 기준으로 나누어서 보이고 양이 상당히 많다.
ACTIVITY MANAGER ACTIVITIES (dumpsys activity activities) ... ACTIVITY MANAGER SERVICES (dumpsys activity services) ... ACTIVITY MANAGER CONTENT PROVIDERS (dumpsys activity providers) ... ACTIVITY MANAGER BROADCAST STATE (dumpsys activity broadcasts) ... ACTIVITY MANAGER PENDING INTENTS (dumpsys activity intents) ... ACTIVITY MANAGER RECENT TASKS (dumpsys activity recents) ... ACTIVITY MANAGER RUNNING PROCESSES (dumpsys activity processes) ...
예를 들어 브로드캐스트 리시버가 잘 등록되어 있는지, 최근 앱 목록에서 이동하다 이슈가 생겼다고 할 때 최근 테스크 목록의 어디에 우리가 있었는지 등 이슈가 발생했을 당시의 우리 앱의 상태를 확인하는데 유용하다.
다른이야기지만, 전체를 기리키는 이름도 액티비티고 컴포넌트에도 액티비티가 있어 이름이 처음에는 이름이 헷갈린다. 아마도 화면을 담당하는 액티비티의 처음에는 다른 무엇이지 않았을까..
DUMP OF SERVICE meminfo
단말에 설치된 앱들의 메모리 사용 정보를 총망라하여 보여준다. 아래는 안드로이드 시스템 프로세스의 메모리 사용량이다.
...
** MEMINFO in pid 10464 [com.android.system] **
Pss Pss Shared Private Shared Private Swapped Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 6697 0 944 6676 68 0 3732 14848 13013 1834
Dalvik Heap 2178 0 808 2168 68 0 1484 7240 3450 3790
Dalvik Other 362 0 136 360 0 0 0
Stack 412 0 4 412 0 0 4
Ashmem 2 0 4 0 0 0 0
Gfx dev 2264 0 3392 568 0 0 0
Other dev 4 0 100 0 0 4 0
.so mmap 933 136 968 124 27144 136 5440
.apk mmap 157 0 0 0 3156 0 0
.ttf mmap 29 0 0 0 292 0 0
.dex mmap 584 316 0 8 544 316 0
.oat mmap 1426 0 0 0 45992 0 0
.art mmap 1055 0 2192 852 13240 0 248
Other mmap 86 0 12 8 1500 0 0
EGL mtrack 57972 0 0 57972 0 0 0
GL mtrack 8664 0 0 8664 0 0 0
Unknown 1024 0 184 1024 8 0 180
TOTAL 83849 452 8744 78836 92012 456 11088 22088 16463 5624
Dalvik Details
.Heap 1452 0 0 1452 0 0 8
.LOS 576 0 68 576 0 0 1468
.LinearAlloc 146 0 132 144 0 0 0
.GC 172 0 0 172 0 0 0
.Zygote 138 0 740 128 68 0 8
.NonMoving 12 0 0 12 0 0 0
.IndirectRef 44 0 4 44 0 0 0
...
이런 목록이 단말 내에서 동작한 모든 프로세스 별로 정리되어 표시된다.
- Private Clean : 앱의 전용 공간으로 영속적인 파일에 할당된다. 오랜시간 사용되지 않으면 정리될 수 있다.
- Private Dirty : 변하는 데이터로 RAM 메모리 속에 공간을 차지한다. 프로세스가 종료되면 시스템에 반환된다.
- Pss Total : Private Clean + Private Dirty + Shared pages 를 합친 공간이다.
- Native Heap : libc를 이용한 네이티브(native) 할당에 사용되는 힙 메모리다.
- Dalvik Heap : 자바 어플리케이션 할당에 사용된다. 큰 오브젝트, zygote 등이 차지한다. GC에 의해 자동으로 회수된다.
- GL mtrack : 2D/3D 그래픽을 그리는데 사용되는 공간이다. 뷰가 포함된 액티비티가 없는 프로세스더라도, 토스트나 다이얼로그 등을 그릴 때 사용한다. 한 번 할당되면 프로세스가 죽을 때까지 회수되지 않는다.
- EGL mtrack : 프레임버퍼가 할당되는 공간으로, openGL 라이브러리를 이용해 2D/3D 그래픽을 그릴때 사용될 수 있다. 그래픽이 포함된 액티비티가 background로 이동하면, 바로 회수한다.
DUMP OF SERVICE package
이 글을 참고하자.
DUMP OF SERVICE dbinfo
pid와 package 이름을 기준으로 connection 갯수와 상태, database 파일 위치와 가장 최근 수행된 query 정보 등을 볼 수 있다.
DUMP OF SERVICE dbinfo: ... ** Database info for pid 4841 [com.google.process.gapps] **
DUMP OF SERVICE connectivity
지원하는 네트워크 종류와 접속 상태를 알 수 있다.
DUMP OF SERVICE connectivity:
NetworkFactories for: Telephony WIFI_P2P WIFI_UT WIFI WIFI
...
Current Networks:
NetworkAgentInfo{ ni{[type: WIFI[] - WIFI, state: CONNECTED/CONNECTED,
...
DUMP OF SERVICE jobscheduler
등록된 잡 서비스 정보와 상태, 실행 기록 등을 확인할 수 있다.
DUMP OF SERVICE jobscheduler: Settings: ... Started users: [0, 150] Registered 99 jobs: ... Job history at 2018-04-07 10:15:44.096: ... Active jobs: ...
“Registered 99 jobs:” 부분에 등록된 잡의 정보가 보인다. 예를 들면,
JOB #1000/1145656139: 6d6fc51 android/com.android.server.storage.DiskStatsLoggingService
1000 tag=*job*/android/com.android.server.storage.DiskStatsLoggingService
Source: uid=1000 user=0 pkg=android
JobInfo:
Service: android/com.android.server.storage.DiskStatsLoggingService
PERIODIC: interval=+1d0h0m0s0ms flex=+1d0h0m0s0ms
Requires: charging=true batteryNotLow=false deviceIdle=true
Backoff: policy=1 initial=+30s0ms
Has early constraint
Has late constraint
Required constraints: CHARGING TIMING_DELAY DEADLINE IDLE
Satisfied constraints: BATTERY_NOT_LOW APP_NOT_IDLE DEVICE_NOT_DOZING
Unsatisfied constraints: CHARGING TIMING_DELAY DEADLINE IDLE
Tracking: BATTERY IDLE TIME
Enqueue time: -9h37m37s809ms
Run time: earliest=+3h7m30s599ms, latest=+1d3h7m30s599ms
Ready: false (job=false user=true !pending=true !active=true !backingup=true comp=true)
안드로이드 시스템이 등록한 잡을 볼 수 있다. 여기에는 실행할 예정이거나 현재 실행 중인 잡이 등록된다.
“Job history at …” 부분에서는 실행된 잡의 정보를 볼 수 있다. 잡이 실행/종료된 timestamp와 종료 시 사유를 간단히 볼 수 있다.
Job history at 2018-04-07 10:15:44.096: ... -2m33s279ms START: u0a151 com.google.android.apps.photos/com.google.android.libraries.social.mediamonitor.MediaMonitorJobSchedulerService -2m33s182ms STOP: u0a151 com.google.android.apps.photos/com.google.android.libraries.social.mediamonitor.MediaMonitorJobSchedulerService : app called jobFinished
위의 로그를 보면, 구글 포토 앱의 잡 서비스가 작업을 완료 한 후 수행할 작업이 없다고 메시지(“app called jobFinished”)를 보냈다. 그 밖에, 앱이 강제종료되거나 초기화 된 경우 “unexpectedly disconnected”를, 수행할 작업 자체가 없는 경우 onStartJob()에서 false를 반환(“onStartJob returned false”)하여 바로 종료한 기록이 남기도 한다.
1회성 잡의 경우, 실행 후 “Registered Jobs” 목록에서는 제거되므로 “Job history” 부분을 통해서만 디버깅할 수 있다. O OS 기준, 재부팅하면 히스토리가 모두 사라지니 참고하자.
마지막으로, “Active jobs:” 부분에서는 현재 실행 중인 잡을 확인할 수 있다.
CPU
일정 시간 동안의 각 프로세스 별 cpu 점유율을 알 수 있다. 간혹, 본인의 앱은 문제가 없는데 브로드캐스트가 올바르게 동작하지 않거나 ANR이 발생했다면 혹시 CPU 점유율을 과도하게 사용한 다른 앱이 있지는 않았는지 확인해볼 필요가 있다.
DUMP OF SERVICE cpuinfo: Load: 6.33 / 5.37 / 3.46 CPU usage from 199030ms to 138956ms ago with 99% awake: 59% 3589/system_server: 34% user + 24% kernel / faults: 189642 minor 210 major 29% 3119/surfaceflinger: 17% user + 12% kernel / faults: 3208 minor 73 major ... 28% TOTAL: 16% user + 10% kernel + 1% iowait + 0.4% softirq
그 밖에
안드로이드 개발자 사이트에서 dumpsys에 대해 소개하고 있으니, 이 부분도 참조하자.
ANR이 Activity Manager나 Window Manager 같은 곳에서 발생한 경우는 “어플리케이션이 응답이 없습니다. 기다리시겠습니까?”와 같은 메시지가 표시되지 않을 수 있다.
최 하단에는 dumpstate가 만들어지기 까지 걸린 시간이 남아있다.
dump done: 29.0s elapsed
디버깅을 위한 로그 남기기에 대해서는 안드로이드 사이트에 정리가 잘 되어 있다.
참고
- http://developer.android.com/intl/ko/tools/help/adb.html
- http://stackoverflow.com/questions/11201659/whats-the-android-adb-shell-dumpsys-tool-and-what-are-its-benefits
- http://android.stackexchange.com/questions/14430/how-can-i-view-and-examine-the-android-log
- http://developer.android.com/intl/ko/tools/debugging/debugging-log.html
- http://bytesthink.com/blog/?p=133
- http://www.slideshare.net/AshishAgrawal22/android-crash-debugging-15694310
- https://source.android.com/devices/tech/debug/dumpsys.html
- http://www.onlamp.com/pub/a/linux/2000/11/16/LinuxAdmin.html
- http://developer.android.com/reference/android/content/pm/PackageManager.html#COMPONENT_ENABLED_STATE_DEFAULT
핑백: 안드로이드의 메모리 릭(Memory leak) – Dog발자
핑백: 안드로이드 잡서비스 분석 – Dog발자
핑백: 안드로이드 package dump 분석 – Dog발자
핑백: startActivity가 안돼요 – Dog발자