版權聲明：本文爲博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/chi_wy/article/details/42472279
重啓原因分類
1.上層造成重啓
system_server被殺
watchdog重啓
重要線程阻塞
2.kernel造成重啓
空指針
非法地址
3.kernel watchdog造成重啓，原因不確定
內存原因
nand驅動
log查看步驟及關鍵字
1. 重啓後的kernel.log或misc/cmdline.log
在log最前面，會有很長的一段，如：
initrd=0x85500000,0x204229 apv="td860-user 4.1.2 MocorDroid4.1.2 eng..20131107.215135 test-keys" mem=512M loglevel=1 console=ttyS1,115200n8 init=/init mtdparts=sprd-nand:256k(spl),512k(2ndbl),256k(params),512k(vmjaluna),10m(modem),3840k(fixnv),3840k(backupfixnv),5120k(dsp),3840k(runtimenv),10m(boot),10m(recovery),250m(system),180m(userdata),20m(cache),256k(misc),1m(boot_logo),1m(fastboot_logo),3840k(productinfo),512k(kpanic) androidboot.mode=panic lcd_id=ID9816 lcd_base=8ff27000 CHR_STATE=0 ram=512M no_console_suspend boot_ram_log=0x8fe00000,0x80000 tdfixnv=0x89060000,0x40000 tdruntimenv=0x890a0000,0x60000 wfixnv=0x90440000,0x40000 wruntimenv=0x90480000,0x60000 productinfo=0x80490000,0x4000 androidboot.serialno=12345678912345 adc_cal=216338536,185339408 fgu_cal=186388584,159845904,7534 fgu_init=2805,7742
搜索androidboot.mode，看開機的模式，如果沒有則默認爲normal mode，正常開機；上例中爲panic，爲kernel中出錯導致的重啓。這個值是從ANA_REG_GLB_POR_RST_MONITOR位中獲取到的值，每次獲取完之後會置爲0：
rst_mode = ANA_REG_GET(ANA_REG_GLB_POR_RST_MONITOR);
rst_mode &= 0x7FFF;
ANA_REG_SET(ANA_REG_GLB_POR_RST_MONITOR, 0); //clear flag
這個值是重啓前填入的，如HWRST_STATUS_PANIC、HWRST_STATUS_ALARM等。
2. 重啓後的last_kmsg log
此文件記錄了重啓前的kernel log，搜索panic確定問題發生在上層還是底層，如果有panic相關信息一般都是kernel造成的問題，如果有Restarting system則是上層造成的。
案例一：上層空指針引起的重啓
0[ 83.522143] Restarting system with command 'special-systemserver-died'.
0[ 83.900657] SPRD_WDT watchdog_feeder, margin=20, feed_period=3, sys_cnt = 86225
0[ 84.026350] sprd_set_reboot_mode:cmd=special-systemserver-died
此時是由於上層systemserver出了問題導致重啓，查看重啓方式是androidboot.mode=special，是system server掛掉引起的重啓，看上去special方式啓動都是上層引起的。
案例二：
【其他】手機處於待機狀態長按Power鍵彈出POP選框不做任何操作還繼續長按Power，手機會自動重啓。
【預置條件】無
【操作步驟】手機處於待機狀態長按Power鍵--彈出POP選框不做任何操作--還繼續長按Power
【實際結果】手機會自動重啓
【預期結果】應正常
【復現概率】Must
【備註說明】對比其他手機無此現象。
分析：last_kmsg中搜索到sprd_set_reboot_mode:cmd=panic，說明是kernel導致的重啓，附件的log中還有!!!! trigger_watch_powerkey !!!! do emergency_restart，說明很可能是主動調用重啓，在代碼中搜索發現
static void trigger_watch_powerkey(void *private)
{
unsigned long flags;
local_irq_save(flags);
#ifdef CONFIG_MAGIC_SYSRQ
handle_sysrq('m');
handle_sysrq('w');
#endif
pr_warn("!!!! trigger_watch_powerkey !!!! do emergency_restart\n");
emergency_restart();
pr_err("%s should never reach here!\n", __func__);
}
長按power鍵超過6秒時會調用此函數，使得手機重啓，諮詢展訊是爲了調試定屏問題所增加的功能，量產時可以去除。
解決方法：代碼中註釋掉input_report_key_hook函數的調用，Makefile中不編譯input-hook.o庫。
案例三：
【無線熱點】下拉狀態欄，點擊無線熱點，手機自動重啓
【預置條件】無
【操作步驟】下拉狀態欄--多次點擊無線熱點
【實際結果】手機自動重啓
【預期結果】無線熱點正常打開和關閉
【復現概率】經常
分析：last_kmsg中搜索到Kernel panic - not syncing: Fatal exception，說明是kernel導致的重啓，而且打印出堆棧信息判斷應爲WIFI問題，查看last_log中的kernel log，可能是soft_ap打開時失敗。
01-01 08:06:06.522 <4>[ 296.682000] thr_wait_for_2nd_eth_dev: sap_eth_sema timeout
解決方法：增加打開嘗試次數爲3次，減小打開失敗概率。
3. 查看重啓前的android log
在android log中，搜索關鍵字 died, 確認是否system server被殺，如果是查看具體原因。
案例四：開機動畫過後手機自動重啓
分析：
log最後顯示
I/Zygote ( 86): Exit zygote because system server (222) has terminated
原因是
E/AndroidRuntime( 222): *** FATAL EXCEPTION IN SYSTEM PROCESS: android.server.ServerThread
ActivityManagerService.java:4182中的空指針導致的，而前面還有一些空指針異常，第1個是
E/SystemServer( 222): java.lang.NullPointerException
E/SystemServer( 222): at android.sim.SimManagerService.<init>(SimManagerService.java:94)
E/SystemServer( 222): at com.android.server.ServerThread.run(SystemServer.java:219)
SimManagerService 94行爲mContext.registerReceiver(mReceiver, filter);可能是mContext空指針，而
Context temp = null;
try {
temp = context.createPackageContext("com.android.settings", Context.CONTEXT_IGNORE_SECURITY);
} catch (NameNotFoundException e) {
e.printStackTrace();
};
mContext = temp;
所以createPackageContext可能創建失敗導致，temp爲null。再回到log
W/System.err( 222): android.content.pm.PackageManager$NameNotFoundException: Application package com.android.settings not found
證實了這一點，
搜索“com.android.settings”
E/PackageManager( 222): Package com.android.settings has no signatures that match those in shared user android.uid.system; ignoring!
發現初始化失敗，可能是簽名或share user id或是版本不匹配導致，導出Settings.apk，反編譯並查看AndroidManifest.xml
<manifest android:sharedUserId="android.uid.system" android:versionCode="15" android:versionName="4.0.3-eng..20130516.160103" package="com.android.settings" coreApp="true" xmlns:android="http://schemas.android.com/apk/res/android">
android:versionName="4.0.3-eng..20130516.160103"，此信息顯示Settings爲20130516號編譯的版本，與測試提供的信息20130627版本不匹配，最終原因是驅動下載了差異較大的boot.img導致。
解決方法：下載20130516版本的boot.img即可恢復並正常開機。
4. 上層watchdog產生的重啓，查看重啓前的traces.txt
軟件framework層的WatchDog主要作用：接收系統內部reboot請求,重啓系統；監護SystemServer進程,防止系統死鎖；每30秒檢查一次。在android log, 關鍵字：WATCHDOG KILLING SYSTEM PROCESS 確認是否是watchdog造成的重啓。如果是，則要查看重啓前的traces.txt，檢查下面3項：
確認是否有kernel stack
關鍵字'held', 找到阻塞源頭
不能被阻塞的線程:WindowManager、ActivityManager、PowerManager、ServerThread
案例五：上層AMS、WMS死鎖導致watchdog重啓
"Thread-304" prio=5 tid=4 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41c16ef8 self=0x69b8a8
| sysTid=3040 nice=0 sched=0/0 cgrp=[no-cpu-subsys] handle=7056472
| schedstat=( 0 0 0 ) utm=0 stm=0 core=1
at com.android.server.wm.WindowManagerService.resumeKeyDispatching(WindowManagerService.java:~6346)
- waiting to lock <0x41738e80> (a java.util.HashMap) held by tid=12 (android.server.ServerThread)
at com.android.server.am.ActivityRecord.resumeKeyDispatchingLocked(ActivityRecord.java:554)
at com.android.server.am.ActivityStack$myThread.run(ActivityStack.java:4314)
"android.server.ServerThread" prio=5 tid=12 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x4154a9a8 self=0x32e200
| sysTid=275 nice=-2 sched=0/0 cgrp=[no-cpu-subsys] handle=3607224
| schedstat=( 0 0 0 ) utm=830 stm=262 core=1
at com.android.server.am.ActivityManagerService.getTasks(ActivityManagerService.java:~5389)
- waiting to lock <0x41555738> (a com.android.server.am.ActivityManagerService) held by tid=4 (Thread-304)
由上面log可知AMS和WMS發生了死鎖，導致了watchdog重啓。
5. 重啓後kernel.log、misc/last_kmsg、dump文件
內核或hal層出現的錯誤有很多，這裏主要將oops或有堆棧信息的問題分析方法，主要分爲3類：
1.一個.so或多個.so文件引起的問題，可能產生的問題並不是重啓
案例六：libwebcore.so導致瀏覽器強關(內存地址+so)
15:50:05.633 I DEBUG : pid: 7662, tid: 7677 >>> com.android.browser <<<
15:50:05.633 I DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000008
15:50:05.673 I DEBUG : #00 pc 000b852a /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #01 pc 000b887c /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #02 pc 000b6428 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #03 pc 00218852 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #04 pc 000be9c4 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #05 pc 000beaae /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #06 pc 000bf1e8 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #07 pc 000a9242 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #08 pc 000a7f6a /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #09 pc 000a71a8 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #10 pc 000aac4a /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #11 pc 000aaf06 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #12 pc 000b3304 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #13 pc 000b33fa /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #14 pc 00093230 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #15 pc 001e95aa /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #16 pc 001da83e /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #17 pc 001d6544 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #18 pc 001d658c /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #19 pc 001644ac /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #20 pc 00253ba8 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #21 pc 002dee9c /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #22 pc 002e4f24 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #23 pc 002e51f2 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #24 pc 0033ac62 /system/lib/libwebcore.so
15:50:05.673 I DEBUG : #25 pc 0033acc8 /system/lib/libwebcore.so
這是從android log中截取的信息，原理是一樣。這種log可以通過addr2line工具進行反編譯，addr2line位於目錄/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin。
命令是addr2line -e -f libwebcore.so 000b852a，libwebcore.so是帶符號表的so，位於/out/target/product/sp8830ec/symbols/system/lib，000b852a是對應的出錯地址。
一個或多個so引起的問題，還可以從網上找個腳本，把堆棧信息單獨保存到文件中，然後使用腳本反編譯，會把每個地址對應的源函數反編譯出來，網上有很多這裏就不貼出腳本了。
2.hal層即非內核層出現地址錯誤產生的重啓問題
案例七：驅動去除光感後開機不斷重啓(so+函數名+偏移地址)
Fatal signal 11 (SIGSEGV) at 0x00000001 (code=1), thread 456 (system_server)
I/DEBUG ( 138): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 138): Build fingerprint: 'Lenovo/A388t/A388t:4.1.2/MocorDroid4.1.2/A388t_S161_131112.20131121:user/release-keys'
I/DEBUG ( 138): pid: 456, tid: 456, name: system_server >>> system_server <<<
I/DEBUG ( 138): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000001
I/DEBUG ( 138): r0 00000001 r1 00000001 r2 00000001 r3 5a07d004
I/DEBUG ( 138): r4 5aedd2c0 r5 403ff19c r6 5aedd2c4 r7 00000001
I/DEBUG ( 138): r8 5a07d004 r9 00000088 sl 00000003 fp 5aedd2b8
I/DEBUG ( 138): ip 40317e94 sp bea80548 lr 4030e6a1 pc 40211048 cpsr 20000010
……
I/DEBUG ( 138): backtrace:
I/DEBUG ( 138): #00 pc 00017048 /system/lib/libc.so (strlen+16)
I/DEBUG ( 138): #01 pc 0000f69d /system/lib/libutils.so (android::String8::setTo(char const*)+8)
I/DEBUG ( 138): #02 pc 0001e7d3 /system/lib/libgui.so (android::Sensor::Sensor(sensor_t const*)+38)
I/DEBUG ( 138): #03 pc 0000e5af /system/lib/libsensorservice.so (android::HardwareSensor::HardwareSensor(sensor_t const&)+70)
I/DEBUG ( 138): #04 pc 0000f78f /system/lib/libsensorservice.so (android::SensorService::onFirstRef()+110)
I/DEBUG ( 138): #05 pc 0000edd5 /system/lib/libutils.so (android::RefBase::incStrong(void const*) const+38)
I/DEBUG ( 138): #06 pc 000010d1 /system/lib/libsystem_server.so
I/DEBUG ( 138): #07 pc 000011eb /system/lib/libsystem_server.so (system_init+242)
……
D/Zygote ( 140): Process 456 terminated by signal (11)
I/Zygote ( 140): Exit zygote because system server (456) has terminated
很明顯是Zygote初始化時system server訪問錯誤地址00000001導致初始化失敗產生的重啓，堆棧信息如下：
#00 pc 00017048 /system/lib/libc.so (strlen+16)
#01 pc 0000f69d /system/lib/libutils.so (android::String8::setTo(char const*)+8)
#02 pc 0001e7d3 /system/lib/libgui.so (android::Sensor::Sensor(sensor_t const*)+38)
#03 pc 0000e5af /system/lib/libsensorservice.so (android::HardwareSensor::HardwareSensor(sensor_t const&)+70)
#04 pc 0000f78f /system/lib/libsensorservice.so (android::SensorService::onFirstRef()+110)
1).看上去雖然棧頂是/system/lib/libc.so (strlen+16)時出現的錯誤，但實際是傳過去的參數有問題，問題應是從android::SensorService::onFirstRef()+110這裏開始；
2).找到SensorService.cpp中onFirstRef函數，出錯是在registerSensor( new HardwareSensor(list[i]) );，即初始化HardwareSensor(list[i])出現的問題，可以發現仍然是函數參數地址不正確引起的；
3).而list是ssize_t count = dev.getSensorList(&list);得到的，具體調用的是sensors_module_t mSensorModule的getSensorList；
4).mSensorModule是通過status_t err = hw_get_module(SENSORS_HARDWARE_MODULE_ID, (hw_module_t const**)&mSensorModule);進行初始化的，hw_get_module則是hardware中通過SENSORS_HARDWARE_MODULE_ID加載對應so文件的函數，即sensor.xxxx.so；
5).而sensor.xxxx.so是/device/sprd/common/libs/libsensors_sprd/模塊生成的文件，因此這個getSensorList實際是通過/device/sprd/common/libs/libsensors_sprd/sensors.cpp中sensors__get_sensors_list得到的，查看錯誤log前面的信息：
D/Sensors ( 456): BmaSensors=1; 1
D/Sensors ( 456): SensorHQALSPS: open_device /dev/alsps
D/Sensors ( 456): alsps Sensor: get name:: (ft6306_ps)
D/Sensors ( 456): SensorHQALSPS: getName = ft6306_ps
D/Sensors ( 456): PnumSensors=3; 2
D/Sensors ( 456): activate handle=0; drv=0
D/Sensors ( 456): BmaSensor: mEnabled = 0, enabled = 0.
D/Sensors ( 456): activate handle=4; drv=1
D/Sensors ( 456): SensorHQALSPS::setEnable=0= en=0; newState=0; what=1; mEnabled=0
D/Sensors ( 456): HQALSPS ---Proximity::HQALSPS_IOCTL_PROX_OFF=== err=0
D/Sensors ( 456): SensorHQALSPS::setEnable=1= en=0; newState=0; what=1; mEnabled=0
6).再結合問題去除光感後，手機不斷重啓，所以可能是D/Sensors ( 456): PnumSensors=3; 2中，光感、接近傳感器的numSensors有問題，而：
mSensors[pls] = new SensorHQALSPS();
numSensors +=
mSensors[pls]->populateSensorList(sSensorList + numSensors);
……
ALOGD("PnumSensors=%d; %d", numSensors, PlsSensor::numSensors);
populateSensorList返回的就是AlspsSensor.h定義的numSensors，值爲2：
enum
{
Light = 0,
Proximity = 1,
numSensors
};
所以最後修改爲：
enum
{
Proximity = 0,
numSensors
};
3．Linux內核引起的Oops問題
對Linux內核來說，Oops就意外着內核出了異常，此時會將產生異常時CPU的狀態，出錯的指令地址、數據地址及其他寄存器，函數調用的順序甚至是棧裏面的內容都打印出來，然後根據異常的嚴重程度來決定下一步的操作：殺死導致異常的進程或者掛起系統。
最典型的異常是在內核態引用了一個非法地址，通常是未初始化的野指針Null，這將導致頁表異常，最終引發Oops。分析錯誤原因的原理同第1種問題，vmlinux相當於so的合集，也是通過工具反編譯找到對應的彙編行，同時查看對應的函數分析原因，這種問題往往比較複雜後面會單獨寫文檔總結分析方法。
6. kernel watchdog造成重啓
原因不確定，可能是內存原因、nand驅動。
————————————————
版權聲明：本文爲CSDN博主「AK_Coffee」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/chi_wy/article/details/42472279
用自動化做穩定性測試，主要是爲了發現系統或者應用出現FC/ ANR/ Reboot/ Freeze等問題。
先詳細說下各種問題對應Log的關鍵字：
一. FC: 所有FC在EventLog中對應的關鍵字是“am_crash”。
1. 常規FC，在Main/Sys.log 關鍵字 "FATAL EXCEPTION"
2. Native Crash，在Main/Sys.log 關鍵字 "backtrace"
二.ANR:在EventLog中對應的關鍵字是“am_anr”。
在Main/Sys.log 中關鍵字“ANR IN”，並且會生成相應的trace文件。
ANR 主要原因有以下三種：
1. KeyDispatchTimeout(5 seconds) --主要類型按鍵或觸摸事件在特定時間內無響應；
2. BroadcastTimeout(10 seconds)BroadcastReceiver在特定時間內無法處理完成；
3. ServiceTimeout(20 seconds) --小概率類型Service在特定的時間內無法處理完成。
三.Reboot：主要分Framwork層重啓和底層重啓。所有重啓在Main/Sys.log 中關鍵字"Entered the Android system server!"。
1.Framework 層重啓（快速重啓，系統開機時間不變）：在Main/Sys.log 對應關鍵字“Watchdog killing system proces”/"system_server_crash"；
2.底層重啓（系統開機時間重置）；在Main/Sys.log 對應關鍵字“Kernel panic”
四. Freeze： 待分析
拿到一份Log，我一般的分析流程是> Event.log> Main/Sys.log> Tarce.log。
注：常見抓Log 方法
1. 停止MTKlog
am broadcast -a com.mediatek.mtklogger.ADB_CMD -e cmd_name stop --ei cmd_target 1
2.打開MTKlog
am broadcast -a com.mediatek.mtklogger.ADB_CMD -e cmd_name start --ei cmd_target 1
3. adb logcat -v time > logcat.txt
4. adb shell cat /proc/kmsg > kernel.txt
5. adb pull data/aee_exp