或许你某一次编译了整个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(); ~~~ 上面总共给出了五种可能，也有一些其他的情况，例如可能某些库的不匹配导致软件的问题，等不一而足。