場景分析：
1. 電話接入時共可分為兩個場景：
1). 電話於響鈴模式時在電話接入的時候會先行停止音樂播放，然后播放電話鈴音接着顯示來電界面等待用戶的
接入操作
2). 電話為無聲模式及用戶沒有設置響鈴的模式，當用戶在來電界面實施接聽操作的時候系統會停止音樂播放進
而進入通話界面
2. 電話掛斷的時候恢復音樂的播放：當電話斷接后系統底層會向上層發送消息，上層接到消息后會對連接做一些后
續操作，其中包括恢復原界面、恢復原播放的音樂等
流程分析：
1. 電話於響鈴模式下在電話接入的時候停止音樂的播放：
場景分析：
1. 電話接入時共可分為兩個場景：
1). 電話於響鈴模式時在電話接入的時候會先行停止音樂播放，然后播放電話鈴音接着顯示來電界面等待用戶的
接入操作
2). 電話為無聲模式及用戶沒有設置響鈴的模式，當用戶在來電界面實施接聽操作的時候系統會停止音樂播放進
而進入通話界面
2. 電話掛斷的時候恢復音樂的播放：當電話斷接后系統底層會向上層發送消息，上層接到消息后會對連接做一些后
續操作，其中包括恢復原界面、恢復原播放的音樂等
流程分析：
1. 電話於響鈴模式下在電話接入的時候停止音樂的播放：
1). RIL在接收到請求的時候會向GsmCallTracker廣播消息，而GsmCallTracker在接收到該消息的時候會繼續
向上層的CallManager廣播
2). CallManager在這個只充當了一個轉播者的角色，它會繼續將消息傳播給CallNotifier
3). 而CallNotifier接收到消息后會判斷來電是否需要查詢，不查詢則會直接設置聲音模式(包含停止音樂播放並
開始響鈴)並顯示來電界面等待用戶的下一步操作； 若需要查詢則會在查詢接收后執行此部分過程
2. 電話於無聲模式下當用戶執行接聽操作的時候停止音樂的播放：
1). 此場景的流程較為簡單因為其整個流程是由上層發向下層的，當用戶實施了接聽的操作時系統 就會捕獲該信
息並直接開始調用函數進入接入電話的准備操作， 其中就包括現行停止音樂播放然后調整后聲音模式等過程
3. 電話掛斷后系統恢復原播放音樂的任務：
1). 本場景下的流程前部分較場景一較為相似，且其走向也大體相同。GsmCallTracker在接收到RIL發送來的
消息后會執行handlePollCalls函數，先更新了本連接為斷開狀態然后將該消息向外廣播
2). 通過CallManager的中轉，CallNotifier得到連接斷開的消息然后會處理一些善后操作，包含恢復音樂播放等
時序分析：
1. 電話於響鈴模式下在電話接入的時候停止音樂的播放的時序圖示：
2. 電話於無聲模式下當用戶執行接聽操作的時候停止音樂的播放的時序圖示：
3. 電話掛斷后系統恢復原播放音樂的任務的時序圖示：
其他：
1. 分析接入電話的時候停止音樂播放、電話掛斷后恢復音樂播放的這兩個流程，其實涉及了整個通話流程的
大部分內容，我首先是找到了關閉音樂和恢復音樂的關鍵點然后再從RIL層向上開始研究電話接入的過 程。
剛開始的時候我在RIL.java中一直走不出去，后來分析得原因主要是對於Message的構造和發送的不了解
導致走了不少彎路
2. 剛剛開始學習Android的Framework開發，雖然只有點Java的底子，但還是希望能越來越好！
1). RIL在接收到請求的時候會向GsmCallTracker廣播消息，而GsmCallTracker在接收到該消息的時候會繼續
向上層的CallManager廣播
2). CallManager在這個只充當了一個轉播者的角色，它會繼續將消息傳播給CallNotifier
3). 而CallNotifier接收到消息后會判斷來電是否需要查詢，不查詢則會直接設置聲音模式(包含停止音樂播放並
開始響鈴)並顯示來電界面等待用戶的下一步操作； 若需要查詢則會在查詢接收后執行此部分過程
2. 電話於無聲模式下當用戶執行接聽操作的時候停止音樂的播放：
1). 此場景的流程較為簡單因為其整個流程是由上層發向下層的，當用戶實施了接聽的操作時系統 就會捕獲該信
息並直接開始調用函數進入接入電話的准備操作， 其中就包括現行停止音樂播放然后調整后聲音模式等過程
3. 電話掛斷后系統恢復原播放音樂的任務：
1. 分析接入電話的時候停止音樂播放、電話掛斷后恢復音樂播放的這兩個流程，其實涉及了整個通話流程的大部分內容，我首先是找到了關閉音樂和恢復音樂的關鍵點然后再從RIL層向上開始研究電話接入的過 程。剛開始的時候我在RIL.java中一直走不出去，后來分析得原因主要是對於Message的構造和發送的不了解導致走了不少彎路 .