或許你某一次編譯了整個Android，然后燒進去，結果屏幕中一直顯示Android Bootanimation，Home界面一直不出來。對此，可能有以下五類原因，往這幾個方向考慮與調查可能可以提供一些線索。前面兩類是屬于軟件的，后面兩類屬于硬件。最后一類屬于軟件硬件都相關。 ## 第一類：binder相關 ~~~ <span style="font-family:Microsoft YaHei;font-size:18px;">binder: release 3000:3000 transaction 12769 out, still active binder: 2720:2720 transaction failed 29189, size 4-0 binder: send failed reply for transaction 12769, target dead</span> ~~~ 這一類的問題，一般都是因為某個進程退出了，因此binder消息無法發送過去了，因此和下面第二類比較類似。 ## 第二類：pid XXX exit 這類log會不斷輸出，表現為某個或者某幾個線程不斷的重啟。為何會不斷的重啟，因為這個是系統關鍵的線程，可能是守護進程。 那么就需要調查程序為什么會退出，這一般有三種可能的原因： 1. 進程需要的資源無法獲得 1. 進程程序有問題 1. 有其他進程在不斷的kill（發信號）這個進程 這幾類都遇到過，下面舉例說明。 ### 進程需要的資源無法獲得 有可能是某個分區壞了，而這個線程一定需要在這個分區創建某個文件并寫入數據才能執行。 有一些Service可能需要某個屬性的值變成特定的值才能運行。 ### 進程程序有問題 在前面的博客：[Freescale IMX6 Android (6): 向ServerManager中添加Service](http://blog.csdn.net/sy373466062/article/details/50333581)，實踐中就遇到過這個問題，且最終發現是自己寫的問題。 那么如何解決呢？ 看log，有時候會出現誤解，例如log可能看到的A進程不對重啟，但是實際上可能是因為A進程依賴B進程，而B進程有問題自己退出了，所以A進程就一直等不到或者發現B進程死了，也退出了，但是B進程退出的時候居然沒有提示。于是我們誤認為是A進程有問題，但是實際是B進程的問題。對此，我們可以看Android的tombstone。不同系統的tombstone存放的位置可能不大一樣，但是一般默認是放在/data/tombstone下面的。 例如某一次啟動后不出現Home畫面，且提示mediaServer與btd不同重啟，但是查看tombstone卻發現是我在SystemServer中添加了代碼導致的： ~~~ *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Freescale/sabresd_6dq/sabresd_6dq:4.3/1.1.0-rc4/20131206:eng/dev-keys' Revision: '405522' pid: 15565, tid: 15565, name: system_server >>> system_server <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d r0 00000000 r1 00000000 r2 00000000 r3 409961a0 r4 deadd00d r5 0000020c r6 00000001 r7 663e7290 r8 663e13b1 r9 00000001 sl 00000000 fp 40991c88 ip 3ccd4001 sp be835258 lr 00000001 pc 4092dad8 cpsr 600b0030 d0 0000000000000000 d1 0000000000000000 d2 0000000000000000 d3 0000000000000000 中間省略 --------- log /dev/log/main 01-02 08:52:24.370 15565 15565 E BatteryService: No charger supplies found 01-02 08:52:24.370 15565 15565 E dalvikvm: ERROR: couldn't find native method 01-02 08:52:24.370 15565 15565 E dalvikvm: Requested: Lcom/android/server/LedService;.native_ledOpen:()I 01-02 08:52:24.370 15565 15565 E dalvikvm: Candidate: Lcom/android/server/LedService;.native_ledOpen:()V 01-02 08:52:24.370 15565 15565 E dalvikvm: JNI posting fatal error: RegisterNatives failed for 'com/android/server/LedService', aborting ~~~ 可以看到其實我native函數的聲明與實際的定義類型不匹配導致的。 ### 有其他進程在不斷的kill（發信號）這個進程 這個一般出現在資源互斥的情況下，例如只有一個攝像頭，但是兩個進程都需要，且某一個進程的做法是如果其他進程在使用這個設備，那么kill掉它。盡管這種做法很流氓，但是實際中，有的時候為了快速響應，也是可以理解的。 ## 第三類：某個硬件相關的驅動不停的打印log 例如，我的PC的USB接口有些松動了，如果adb先接到這個端口，就會不斷的出現下面的log： ~~~ android_work: did not send uevent (0 0 (null)) android_work: did not send uevent (0 0 (null)) android_work: did not send uevent (0 0 (null)) android_work: did not send uevent (0 0 (null)) android_work: did not send uevent (0 0 (null)) ~~~ 這個是因為硬件接觸的問題導致一下子接好馬上就松開了，于是USB驅動不斷產生中斷，內核不斷發送event到上層。 對于這種持續不斷大量的中斷產生，內核大部分的CPU時間都用去處理中斷了，因為中斷的優先級比非NMI中斷外的任務都高，且中斷的上半部分會關閉中斷與調度，因此系統啟動會變得特別的慢，看起來就向一直啟動不來似的。 ## 第四類：沒有特殊的log輸出，但是系統一直卡住 這個也在實際中遇到過，而且幾乎可以肯定是內核（硬件）問題，例如產生某個NMI中斷硬件一直產生中斷，這個最終將會導致CPU無法調度其他任何任務而freeze。 ## 第五類：硬件出現問題，軟件等不到這個硬件不斷重啟 例如某次啟動后不斷打印如下log： ~~~ ov3640_write_reg:write reg error:reg=3012,val=80 ERROR: v4l2 capture: slave not found! ~~~ 然后一個service依賴這個v4l2_capture（攝像頭）設備，于是不斷的去檢測，不存在就退出，然后又被啟動起來又檢測發現不存在又退出。對此，我們可以插上這個硬件，也可以直接去掉對這個設備的檢測，甚至可以在內核中不要添加這個設備，例如在TQIMX6Q的內核中可以注釋掉下面的語句來解決這個問題： ~~~ $ git diff arch/arm/mach-mx6/board-mx6q_sabresd.c diff --git a/arch/arm/mach-mx6/board-mx6q_sabresd.c b/arch/arm/mach-mx6/board-mx6q_sabresd.c index fd1f3fd..5ca39e0 100644 --- a/arch/arm/mach-mx6/board-mx6q_sabresd.c +++ b/arch/arm/mach-mx6/board-mx6q_sabresd.c @@ -1328,9 +1328,9 @@ static void __init mx6_sabresd_board_init(void) imx6q_add_mipi_dsi(&mipi_dsi_pdata); imx6q_add_lcdif(&lcdif_data); imx6q_add_ldb(&ldb_data); - imx6q_add_v4l2_output(0); - imx6q_add_v4l2_capture(0, &capture_data[0]); - imx6q_add_v4l2_capture(1, &capture_data[1]); + //imx6q_add_v4l2_output(0); + //imx6q_add_v4l2_capture(0, &capture_data[0]); + //imx6q_add_v4l2_capture(1, &capture_data[1]); imx6q_add_mipi_csi2(&mipi_csi2_pdata); imx6q_add_imx_snvs_rtc(); ~~~ 上面總共給出了五種可能，也有一些其他的情況，例如可能某些庫的不匹配導致軟件的問題，等不一而足。