首先拨号键属于全局策略管理，所以在PhoneWindowManager中对KEYCODE_CALL事件做了对应的处理，如果按下KEYCODE_CALL时，话机处于RINGING状态，则通过Phone执行answerRingCall接口实现接听电话的调用。而在PhoneWindow中有对KEYCODE_CALL更详细的逻辑处理。当KeyDown时...android更关心此时是否是长按CALL，所以这不是我所想要知道的细节，而在KeyUp时有startCallActivity的调用，哈哈～ 开始跟Call界面关联了。在这个调用中PhonwWindow发出了一个action为ACTION_CALL_BUTTON的Intent请求，不用猜，Contacts中绝对有一个Acivity对这个类型的Intent做了捕获，查看Contacts的AndroidManifest，发现只有DialtactsActivity对该类型的Intent做处理。检查一遍DialtactsActivity发现这是一个TabActivity，而我所关心的拨号界面，通话记录，联系人等界面均为其一个Tab，所以可以确定android就是通过一个简单的Intent将这个界面调用出来的。但是在实际中我遇到一些奇怪的问题(页面定位不准)，所以继续检查。在fixIntent中DialtactsActivity会给来自Call键的Intent设置一个CONTENT_TYPE的type,同时标记一个扩展名为call_key 的boolean值(true)，并立即在setCurrentTab中对这2个值做了检测，首先是如果call_key 为true, type为CONTNT_TYPE 那么就通过ITelephony调用showCallScreen().而这个调用里面如果话机不是idel状态则会调用InCallScreen界面，然后返回，退出。否则根据componentName进行选择显示的Tab。

今天算是解决了这个问题，在Dialtacts中增加了一个Tabpage 显示与否的状态设置。然后通过TwelveKeyDialer 的 onResume()以及onStop()来判断是否显示，当然其他几个页面也是类似的做法。最后很好的解决了Home键返回后再拨号就自动拨出的Bug。虽然方法山寨了点～       其实这个地方android有一个流程我现在还没想通是怎么回事，PhoneWindowManager按理说是全局的策略，也就是说现由PWM捕获到KEYCODE_CALL然后才是TwelveKeyDialer捕获才对，所以PW捕获到之后会立即发出一个action为CALL_BUTTON的请求，而Dialtacts则会以onNewIntent的方式处理这个Intent,从代码分析，此时应该会自动设置为CALL_LOG页面，也就是说现象是，拨号之后按拨号键会切换到通话记录界面上去而不是开始拨打(我遇到的Bug也是这个样子)但是在仿真机上却在按下拨号键之后话机会正确呼叫出去。而代码上分析，呼叫的动作只能在TW中完成，那么Dialtacts在收到onNewIntent后应该是未做处理才对.(通过加调试，发现仿真机运行时也确实是这个样子)那么这就跟上面分析的流程不一致了....这是我现在还没搞明白的事..