|
首先撥號鍵屬於全局策略管理，所以在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後應該是未做處理纔對.(通過加調試，發現仿真機運行時也確實是這個樣子)那麼這就跟上面分析的流程不一致了....這是我現在還沒搞明白的事.. |
