我们知道，信号处理的方式一般有三种：

1. 忽略 接收到信号后不做任何反应。

2. 自定义 用自定义的信号处理函数来执行特定的动作

3. 默认 接收到信号后按默认得行为处理该信号。 这是多数应用采取的处理方式。

而 传统 UNIX系统对以上信号的默认处理如下图所示 （来自 APUT ）：

我们知道，信号处理的行为是以进程级的。就是说不同的进程可以分别设置不同的信号处理方式而互不干扰。同一进程中的不同线程虽然可以设置不同的信号屏蔽字，但是却共享相同的信号处理方式 （也就是说 在一个线程里改变信号处理方式，将作用于该进程中的所有线程）。

Android也是Linux系统。所以其信号处理方式不会有本质的改变。但是为了开发和调试的需要，android对一些信号的处理定义了额外的行为。 下面是这些典型的信号在Android系统上的行为：

1. SIGQUIT （ 整型值为 3）

上面的表10-1显示，传统UNIX系统应用，对SIGQUIT信号的默认行为是 "终止 + CORE"。也就是产生core dump文件后，立即终于运行。

Android Dalvik应用收到该信号后，会 打印改应用中所有线程的当前状态，并且并不是强制退出。这些状态通常保存在一个特定的叫做trace的文件中。一般的路径是/data/anr/trace.txt. 下面是一个典型的trace文件的内容：

2. 对于很多其他的异常信号 （SIGILL, SIGABRT, SIGBUS, SIGFPE, SIGSEGV, SIGSTKFLT ), Android进程 在退出前，会生成 tombstone文件。记录该进程退出前的轨迹。一个典型的tombstone文件内容如下：

我们看到，多数signal的产生是由于某种内部错误。我们在在开发过程中，当然也可以通过系统调用故意生成signal给某进程。主要的方法如果：

1. 在kernel里 使用 kill_proc_info(）

2. 在native应用中 使用 kill() 或者raise()

3. java 应用中使用 Procees.sendSignal()等

但是在测试中，最简单的方法某过于通过 adb 工具了。一个典型场景是：

首先是切换到root用户 （普通进程只能发个自己或者同组进程，而root可以发送signal给任何进程）。然后用 ps命令查看当前系统中所有的进程信息。最后用kill命令发送SIGQUIT给进程号为513的进程。

android kill程序的实现很简单，他只能支持发送signal的值（如上例中的 “3”）给进程，而不能用名字（如“SIGQUIT”）。 android 中kill程序的代码在system/core/toolbox/kill.c 中。虽然移植linux中kill的实现就能支持名字，但是那个完全没有必要，android需要的signal就这么几个，他们的值应该记住的。