前置文章：
《 Android 4.4 Kitkat Phone工作流程淺析(一)__概要和學習計劃》
《Android 4.4 Kitkat Phone工作流程淺析(二)__UI結構分析》
《Android 4.4 Kitkat Phone工作流程淺析(三)__MO(去電)流程分析》
《Android 4.4 Kitkat Phone工作流程淺析(四)__RILJ工作流程簡析》
《Android 4.4 Kitkat Phone工作流程淺析(五)__MT(來電)流程分析》
《Android 4.4 Kitkat Phone工作流程淺析(六)__InCallActivity顯示更新流程》
《Android 4.4 Kitkat Phone工作流程淺析(七)__來電(MT)響鈴流程》
《Android 4.4 Kitkat Phone工作流程淺析(八)__Phone狀态分析》
《Android 4.4 Kitkat Phone工作流程淺析(九)__狀态通知流程分析》
《Android 4.4 Kitkat Phone工作流程淺析(十)__"通話顯示"查詢流程》
《Android 4.4 Kitkat Phone工作流程淺析(十一)__PSensor工作流程淺析》
概述
在Android 4.4 中，Google 對Telephony_Phone進行了重構，前面也通過一些列文章分析了Android 4.4 中Telephony Phone的工作流程。但在2014年10月15日，Google釋出了Android 5.0 預覽版，正式版也在一個月之後釋出。Android 5.0 變化非常大，無論從UI風格還是功能實作上，Google都進行了大刀闊斧的修改。同時，Telephony_Phone子產品的架構也再次進行了調整，調整之後的Telephony_Phone各個子產品之間耦合性更低，分工也更為明确，但整個流程卻變複雜了許多。
本文來自http://blog.csdn.net/yihongyuelan 轉載請務必注明出處
下圖是Android 4.2 到5.0，Telephony Phone子產品結構變化示意圖：
圖 1 Android Telephony Phone Architecture Evolution
在Android 4.2 以及之前的版本中，Telephony Phone子產品主要涉及Phone和Contacts以及Telephony Framework這幾個部分。在Android 4.4 中，Phone子產品被InCallUI和TeleService取而代之，其中InCallUI被打包到Dialer.apk中。InCallUI主要負責UI顯示部分，TeleService則負責邏輯處理。
Android 5.0 中，Telephony Service也就是原來的TeleService，部分功能被提取到了Telecom Service和Telecom Framework中。整個Telephony Phone子產品包括了5個部分：InCallUI、Telecom Service、Telecom Framework、Telephony Service、Telephony Framework。其中新增的Telecom Framework被打包到framework.jar中，Telecom Service則打包到Telecom.apk裡。
從Android 4.2到5.0，Telephony Phone子產品愈加細化，各個子子產品的功能越愈發精簡。當然，這符合面向對象的要求，但也導緻各個子產品間互動也相應增加。整個Telephony Phone演進過程可以簡單的概括為：
圖 2 Simplified Phone Architecture Evolution
Android 5.0 InCallUI簡介
Android 5.0 對InCallUI界面進行了調整以适應Google的Material Design。
圖 3 InCallUI InCall process (pictrue from @Eric Li)
圖 4 Incoming call (pictrue from @Eric Li)
在Android 5.0中，InCallUI加入了新的呈現方式即Immersive Mode，隻要在非LockScreen界面來電，來電資訊将顯示為一個浮動通知。該通知是一個Heads-up類型的Notification，當觸發時會在狀态欄彈出以提示使用者。任何一個Notification都可以采用Heads-up的方式顯示，隻需給Notification.builder設定FullScreenIntent屬性：
builder.setFullScreenIntent(PendingIntent intent, boolean highPriority)
如果彈出Heads-up Notification時系統處于鎖屏狀态，NotificationMangerService會執行PendingIntent所指定的Action。如：鎖屏時來電則會啟動InCallActivity，又因為InCallActivity具有以下屬性：
getWindow().addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD);
是以，鎖屏會被解除并顯示InCallActivity。
圖 5 Multiple calls UI (pictrue from @Eric Li)
圖 6 Conference calls UI (pictrue from @Eric Li)
Android 4.4與5.0 MO/MT對比
之前已經分析過Android 4.4 的MO/MT過程，具體可以參看：
《Android 4.4 Kitkat Phone工作流程淺析(三)__MO(去電)流程分析》
《Android 4.4 Kitkat Phone工作流程淺析(五)__MT(來電)流程分析》
MO即Mobile Origination Call主叫，也就是去電。主要包括：撥号，啟動UI界面，更新通話狀态；MT即Mobile Termination Call被叫，也就是來電。主要包括：響鈴，啟動UI界面，更新通話狀态。在Android 4.4 中，整個MO/MT執行流程如圖7：
圖 7 Android 4.4 MO/MT flowchart
MO關鍵步驟如下
①. Dial
圖中粉色箭頭标示。Dial是從Dialer的Dialpad中發起的，發送廣播到Telephony Service中繼續進行處理。
②. Start InCallUI
圖中綠色箭頭标示。在Android 4.4中，當Dial發起并到達RIL之後，RIL會将Dial請求下發給Modem端，Modem端則傳回DIALING狀态。RIL接收到DIALING狀态之後将資訊回報給Telephony Service，最終到達InCallUI并根據目前通話狀态(DIALING)啟動界面并顯示相應内容。
③. Update Call State
圖中綠色箭頭标示。在Android 4.4中，Call狀态從IDLE變為DIALING也屬于Call State變化範疇，是以Update Call State流程與Start InCallUI流程一緻，但Start InCallUI隻會執行一次，而Update Call State在通話過程中會多次執行，如Call 狀态從ACTIVE轉為HOLD等。
MT關鍵步驟如下
①. Ringing
圖中橙色箭頭所示。Ringing實際上也是Call 狀态的一種類型，是以也是從Modem端發起并傳遞給RIL，之後逐級上報并最終顯示到InCallUI中。與Update Call State唯一不同的是，MT會在CallNotifier中調用Ringer執行播放鈴聲操作。
在Android 4.4 中，MO流程可以分為兩步，即Dial和Update Call State (Start InCallUI包含在Update Call State流程中)。MT流程亦分為兩步，即Update Call State和Ringing。
Android 4.4 Telephony Phone架構非常清晰，各個子子產品也較為獨立。如Telephony Service和InCallUI通過CallHandlerService、CallHandlerServiceProxy以及CallCommandClient、CallCommandService進行互動，主要涉及com.android.incallui(InCallUI)、com.android.dialer(Dialer)、com.android.phone(Telephony Service)三個程序。雖然架構上比較清晰，但InCallUI和Telephony Service綁定得太緊，同時Telephony Service也非常臃腫。
在Android 5.0 中Telephony Service分離了部分功能到Telcom Service和Telecom Framework中。Android 4.4 與 5.0 Telephony Phone架構對比，如下圖所示：
圖 8 Architecture difference(Simplified)
從圖中可以看到Telephony Phone架構從Android 4.4時的三層變成了Android 5.0時的四層，其中Android 5.0 中新增部分由原來的Telephony Service分離而來。從程序模型上分析，在Android 5.0 中，Telephony Phone的工作流程主要包含：com.android.incallui(InCallUI)、com.android.dialer(Dialer)、com.android.server.telecom(Telecom Service)、com.android.phone(Telephony Service)四個程序。
Android 5.0 Telephony Phone MO流程改動較大，關鍵步驟如下圖所示：
圖 9 Android 5.0 MO flowchart
MO流程分為三個步驟，即Dial，Start InCallUI，Update Call State。在Android 4.4的流程中，Update Call State包含了Start InCallUI，而在Android 5.0 中很各個步驟非常明确。從上圖中可以看到，無論是InCallUI、Telecom Service還是Telephony Service均沒有直接互動，所有的互動都是與Framework進行。最重要的一點是：InCallUI不再與Telephony Service或者Telecom Service綁定，各個子產品非常獨立。
Android 5.0 Telephony Phone MO詳細流程如下圖所示：
圖 10 MO Dial / Start InCallUI /Update Call State Flowchart
Android 5.0 MO詳細流程分為四個步驟，即Start InCallUI，執行Dial Action，更新Dialing狀态，Call 狀态改變更新。從上圖可以看到，InCallUI在Call 狀态改變之前就已經啟動了，在Call 狀态改變為Dialing後再次更新界面。
Android 5.0 Telephony Phone MT流程關鍵步驟以及詳細流程，如下圖所示：
圖 11 Android 5.0 MT Flowchart
圖 12 MT Ringing and Update Call State Flowchart
在Android 5.0 Telephony Phone MT流程中，Start InCallUI依然包含在Update Call State流程中，同時在CallsManager中會調用Ringer執行相關響鈴的操作。
Telecom簡介
在Android 5.0中新增了Telecom Service ( packages/services/Telecomm )和Telecom Framework ( framework/base/telecomm )，這兩部分由Telephony Service分離而來，雖然在Android 5.0 中Telephony Service依然存在，但所負責事務卻有所改變。
Telecom是對Telecom Service和Telecom Framework的統稱，其主要負責所有資料業務。上層APP(InCallUI)接觸到的Phone、Call以及Connection對象，實際上是Telecom Framework的Phone、Call和Connection對象，并不是Telephony Framework中的GSMPhone、GsmCall和GsmConnection。
其中，Telecom Framework中的Phone和Call取代了Android 4.4 Telephony Service中的CallCommandService和CallHandlerServiceProxy，負責通話資料的傳遞以及控制指令的下發。而Telecom Service中的CallsManager則負責所有通話資料以及指令的處理，并将結果傳遞給Telecom Framework。
Android 4.4與5.0 Call State對比
在之前的博文中有分析Android 4.4中Call 狀态( 詳見《Android 4.4 Kitkat Phone工作流程淺析(八)__Phone狀态分析》 《Android 4.4 Kitkat Phone工作流程淺析(九)__狀态通知流程分析》 )，随着Android 5.0中Telephony Phone架構的變更，Call 狀态也随之改變。如下圖所示為Android 4.4中各個Call狀态及其對應關系：
圖 13 Android 4.4 Call State Overview (MTK)
其中msg_type是MTK的+ECPI指令中所攜帶的參數。
Android 5.0 中Call 狀态分布以及轉換如下圖所示：
圖 14 Android 5.0 Call State distribution diagram
Android 5.0 中Call State的種類包括：
1. DriverCall.State. 用于描述modem的狀态；
2. Call.State (Telephony Framework). 用于描述Call狀态，這裡的Call包含GsmCall、CdmaCall；
3. Connection (Telecom Framework). 用于描述每一個Connection的狀态，每一個Connection狀态來源于所屬Call的狀态；
4. CallState (Telecom Framewok). 由于上層改動引入了PRE_DIAL_WAIT等狀态，但這種狀态并不存在于Telephony Framework Call.State中，是以使用CallState來轉換；
5. Call (Telecom Framework). Telephony Framework Call.State的進一步抽象，來源于CallState的轉換，也是InCallUI中Call.State的來源；
6. Call.State (InCallUI). 定義InCallUI中Call的狀态；
7. InCallState (InCallPresenter). InCallActivity的狀态，用于控制UI的更新；
Telephony Phone中的Call狀态由協定規定，對于新增的PRE_DIAL_WAIT是無法在Modem端改動的，是以隻能在Framework中進行修改并做相應的處理。Android 5.0 中Call 各個狀态及其對應關系如圖所示：
圖 15 Android 5.0 Call State Overview (AOSP)
通過上面的分析可以知道：
①. InCallState新增兩個狀态，即PENDING_OUTGOING和WAITING_FOR_ACCOUNT
當使用者有多個賬戶且沒有設定預設賬戶時，撥号後會彈出提示框讓使用者選擇賬戶(網際網路賬戶/SIM1/SIM2)，此時狀态就為WAITING_FOR_ACCOUNT即等待使用者輸入。Android 5.0 中，InCallUI并非等待Call狀态改變後再啟動，預先啟動的InCallUI狀态為PENDING_OUTGOING，之後會轉為OUTGOING狀态。
②. Telephony Framework Call.State和DriverCall.State沒有改動
Android 5.0 中，Telephony Framework Call.State 之間的轉換關系如下圖所示，與Android 4.4 一緻：
圖 16 Telephony Call.State conversion relationship
小結
Android 5.0 Telephony Phone無論從UI還是架構上都與之前相差很大。架構上的差異主要展現在新增了Telecom Service和Telecom Framework，所有的通話資料業務的處理從Telephony Service轉移Telecom中。UI上的差異主要是适應Android 5.0 新引入的Material Design，并引入了Heads-up Notification來電界面。
架構的變化也導緻了MO/MT流程的變更，新流程相較于原來更加複雜，但各個子子產品更加獨立。如InCallUI僅僅依賴于Framework，如果Framewrok公開相應的接口(Call/Phone/InCallServiced等)，三方APP可以輕松實作InCallUI的功能。
雖然Android 5.0 Telephony Phone架構變得更加複雜，不過代碼中仍然有部分接口并未使用，或許Google在後續的版本更新中還會進一步改進。
文中涉及資源免積分下載下傳：戳這裡