Android来电时停止音乐播放的流程（转）
场景分析：
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的构造和发送的不了解导致走了不少弯路 .
