Android 4.4 Kitkat Phone工作流程浅析(七)__来电(MT)响铃流程

最新推荐文章于 2021-05-28 11:02:21 发布

yihongyuelan

最新推荐文章于 2021-05-28 11:02:21 发布

阅读量1.3w

点赞数 5

分类专栏： Android 文章标签： Ring Android4.4 Phone Telephony

本文链接：https://blog.csdn.net/yihongyuelan/article/details/24640819

版权

本文详细分析了Android 4.4 KitKat系统中电话来电响铃的工作流程，从Telephony Framework的RILJ、PhoneBase、CallManager的注册流程，到TeleService如何处理响铃事件，包括CallStateMonitor、CallNotifier和Ringer的角色。文章指出，Android 4.4将响铃触发放到了TeleService中，实现了UI和Logic的分离。

摘要由CSDN通过智能技术生成

本文来自http://blog.csdn.net/yihongyuelan 转载请务必注明出处

本文代码以MTK平台Android 4.4为分析对象，与Google原生AOSP有些许差异，请读者知悉。

前置文章：

《 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显示更新流程》

概述

本系列文章以MT/MO为主线流程，并对其中的细枝末节进行补充说明，比如来电响铃流程。在MT流程的分析中已经涵盖了流程的发起与终止，本文所描述的响铃流程始于MT流程的发起，如对MT流程不熟悉的童鞋请查看文章《Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析》以及《Android 4.4 Kitkat Phone工作流程浅析(六)__InCallActivity显示更新流程》。

Android 4.4对于响铃流程有所改动，把响铃触发放到了TeleService中，这也符合4.4 Phone的设计风格即UI和Logic分离。当来电流程发起时，抓取radio_log进行分析后，可以看到整个来电过程状态改变如下：

handleMessage (EVENT_VOICE_CALL_INCOMING_INDICATION) //设置voice call的标志
handleMessage (EVENT_NEW_RINGING_CONNECTION)         //新来电标志
handleMessage (EVENT_PRECISE_CALL_STATE_CHANGED)     //状态改变
handleMessage (EVENT_INCOMING_RING)                  //响铃
handleMessage (EVENT_CRSS_SUPP_SERVICE_NOTIFICATION) //收到AT指令CLIP后，更新通话信息(CLIP即来电显示作用)
handleMessage (EVENT_INCOMING_RING)
handleMessage (EVENT_CRSS_SUPP_SERVICE_NOTIFICATION)
handleMessage (EVENT_INCOMING_RING)
handleMessage (EVENT_CRSS_SUPP_SERVICE_NOTIFICATION)
handleMessage (EVENT_INCOMING_RING)
handleMessage (EVENT_CRSS_SUPP_SERVICE_NOTIFICATION)
handleMessage (EVENT_INCOMING_RING)
handleMessage (EVENT_CRSS_SUPP_SERVICE_NOTIFICATION)
handleMessage (EVENT_DISCONNECT)                     //断开连接
handleMessage (EVENT_PRECISE_CALL_STATE_CHANGED)     //状态改变
handleMessage (EVENT_PRECISE_CALL_STATE_CHANGED)

这些log是CallManager中打印出来的，当然我们也可以在RIL.java中去查看对应的log。

当Modem侧收到来电消息后所做的操作如下：

1. 根据来电类型设置INCOMING_INDICATION；

2. 发起NEW_RINGING_CONNECTION，新来电标志；

3. 触发CALL_STATE_CHANGED状态，状态改变促使界面更新；

4. 发起响铃通知INCOMING_RING，响铃流程由此发起；

5. 根据CLIP返回信息触发CRSS_SUPP_SERVICE_NOTIFICATION，这是由MTK加入的，其作用是根据CLIP的返回更新Call的信息；

6. 循环上面4和5步，持续响铃；

7. 断开连接DISCONNECT，本次MT流程结束(未接听)；

8. 触发CALL_STATE_CHANGED状态，状态改变促使界面更新；

Telephony Framework处理响铃事件

当来电消息到来时，经过Modem以及RILD的处理后便传递到Telephony framework中，并由RILJ继续发起。流程图如下：

RILJ

在MT流程发起后，会有相关的unsolicited信息反馈到RILJ中，这里主要关注响铃流程(ringing_flow)，因此可以找到以下AT指令返回的log信息：

01-01 02:46:01.154  4753  4768 D use-Rlog/RLOG-AT: +CRING: VOICE
01-01 02:46:01.154  4753  4768 D use-Rlog/RLOG-AT: 
01-01 02:46:01.154  4753  4768 D use-Rlog/RLOG-AT: +CLIP: "13800138000",0,"",0,"",0
01-01 02:46:01.154  4753  4768 D use-Rlog/RLOG-AT: 
01-01 02:46:01.154  4753  4768 D use-Rlog/RLOG-AT: +ECPI: 1,4,0,1,1,0,"13800138000",129,""