Android核心分析---Android电话系统
Android核心分析---Android电话系统(2012-02-21 13:05:37)转载▼标签：it分类：AndroidAndroid电话系统之概述篇 首先抛开Android的一切概念来研究一下电话系统的最基本的描述。我们的手机首先用来打电话的，随后是需要一个电话本，随后是PIM，随后是网络应用，随后是云计算，随后是想
Android电话系统之概述篇
0)拨叫电话,接听电话，挂断电话,发送短信，网络连接,PIM管理
1)由于电话运营商为我们提供了呼叫等待，电话会议等补充业务，所以我们的手机需要管理多路通话，如何管理?
2)来电时，我们要播出来电铃声，接通时我们需要切换语音通道，这个又跟多媒体系统打上了交道，例如有耳机插上了，有蓝牙耳机连上了，系统该做如何的管理和切换？
3）上网的网络通路建立（例如GSMGPRS），如何PPP连接并连接到LinuxSocket通道上的？系统如何管理数据连接？
4）AP跟Modem通讯时通过AT指令的，如何将AT指令变成一个个具体的操作函数，如何管理Modem发给我们的回应，AT命令通道，数据通道如何管理？
5）sim卡的电话本如何管理？
上面的关于手机的基本问题，Android电话系统设计者必须要解答的问题。该设计如何的管理框架，提出什么概念来表达？所以要分析Android的电话部分，还是需要理解电话实现的背景知识，通讯协议，大体框架。
Android设计者将电话系统设计成了三部分。
Android电话系统之-rild
Rild是Init进程启动的一个本地服务，这个本地服务并没有使用Binder之类的通讯手段，而是采用了socket通讯这种方式。RIL(RadioInterface Layer)
Android给出了一个ril实现框架。由于Android开发者使用的Modem是不一样的，各种指令格式，初始化序列都可能不一样，GSM和CDMA就差别更大了，所以为了消除这些差别，Android设计者将ril做了一个抽象，使用一个虚拟电话的概念。这个虚拟电话对象就是GSMPhone（CDMAPhone),Phon对象所提供的功能协议，以及要求下层的支撑环境都有一个统一的描述，这个底层描述的实现就是靠RIL来完成适配。
Andoid将RIL层分为两个代码空间：RILD管理框架，AT相关的xxxril.so动态链接库。将ＲＩＬ独立成一个动态链接库的好处就是Ａｎｄｒｏｉｄ系统适应不同的Ｍｏｄｅｍ，不同的Mode可以有一个独立的Ril与之对应。从这个层面上看，Rild更多是一个管理框架。
下面的数据流传递描述图表描述了RIL-JAVA层发出一个电话指令的5步曲。
在AT通讯的过程中有两类响应：一种是请求后给出应答，一种是通知类，即为不请自来的，例如短信通知达到，我们称该类通知为URC。在Rild中URC和一般的Response是分开处理的，概念上URC由handleUnsolicited@Atchannel.c处理，而Response由handleFinalResponse来处理。
1 Event Loop
Rild管理的真正精髓在ril.cpp,ril_event.cpp中，在研究的过程中，可以看到设计者在抽象上所下的功夫，设计得很优美。EventLoop的基本工作就是等待在事件端口（串口，Socket），一旦有数据到达就根据登记的Event回调函数进行处理。现在来看Ril设计者是如何建立一套管理框架来完成这些工作的？
1.1 Event对象
Event对象构成：（fd,index,persist,func,param）
| fd | 事件相关设备句柄。例如对于串口数据事件，fd就是相关串口的设备句柄 |
| index | |
| persist | 如果是保持的，则不从watch_list中删除。 |
| func | 回调事件处理函数 |
| param | 回调时参数 |
readFDS：是Linux的fd_set，readFDS保存了Rild中所有的设备文件句柄，以便利用select函数统一的完成事件的侦听。
watch_list：监测时间队列。需要检测的事件都放入到该队列中。
timer_list：timer队列
pending_list:待处理事件队列，事件已经触发，需要所回调处理的事件。
事件队列队列的操作：ril_event_add,ril_event_del,ril_timer_add
在添加操作中，有两个动作：
(1) 加入到watch_list
(2) 将句柄加入到readFDS事件句柄池。
1.2 ril_event_loop()
ril_event_loop利用select等待在readFDS（fd_set）上，当select设备有数据时，ril_event_loop会从select返回，在watch_list中相应的Event放置到pend_list，如果Event是持久性的则不从watch_list中删除。然后ril_event_loop遍历pengding_list处理Event事件，发起事件回调函数。
1.3 几个重要的Event
上面分析了ril-d的框架，在该框架上跑的事件有什么
（1）s_listen_event-（s_fdListen,listenCallback）
listenCallback处理函数，
接收客户端连接：s_fdCommand=accepte(..)
添加s_commands_event()
重新建立s_listen_event，等待下一次连接
（2）s_command_event(s_fdCommand,ProcessCommandsCallback)
从fdCommand
使用ProcessCommandBufer处理数据
s_listen_event在大的功能上处理客户端连接（Ril-JAVA层发起的connect）,并建立s_commands_event去处理Socket连接发来的Ril命令。ProcessCommandBufer实际上包含了Ril指令的下行过程。
1.4 下行命令翻译及其组织@ProcessCommandBuffer
RIL_JAVA传递的命令格式：Parcel ，由命令号，令牌，内容组成。RIL_JAVA到达RIL_C时转为构建本地RequestInfo，并将被翻译成具体的AT指令。由于每条AT命令的参数是不同的，所以对不同的AT指令，有不同的转换函数，在此Android设计在这里做了一个抽象，做了一个分发框架，通过命令号，利用sCommand数组，获得该命令的处理函数。
sComand[]={
<...>
}
sComand 存在于Ril_command.h中。
&sComand[]=
<
{….}
>
dispatchXxx函数一般都放在在Reference-ril.c中，Reference-ril.c这个就是我们需要根据不同的Modem来修改的文件。
1.5 send_at_command框架
send_at_command是同步的，命令发送后，send_at_command将等待在s_commandcond，直到有sp_response->finalResponse。
2 read loop@Atchannel.c
Readloop是解决的问题是：解析从Modem发过来的回应。如果遇到URC则通过handleUnsolicited上报的RIL_JAVA。如果是命令的应答，则通过handleFinalResponse通知send_at_command有应答结果。
对于URC，Rild同样使用一个抽象数组@Ril.CPP.
static UnsolResponseInfos_unsolResponses[] = {
#include"ril_unsol_commands.h"
};
并利用RIL_onUnsolicitedResponse将URC向上层发送。
3 Ril-d的整体数据流及其控制流示意图
Android RIL-Java
RIL-Java的大框架包含了四个方面：
Receiver，Sender，CommandInterface，异步通知机制
（1） Command Interface
…
getlccCardStatus
getCurrrentCalls
dial
acceptCall
rejectCall
sendDTMF
sendSMS
setupDataCall
setRadioPower
…
为什么要定义这些接口呢？这函数接口不是凭空捏造出来的，这些都是电话的基本功能的描述，是对ModemAT指令的提炼抽象。大多数Modem都是根据通讯协议提供接口，我们如果不熟悉通讯协议，请参阅3GPP的相关文档，以及自己使用的Modem的SPEC说明。
V.25ter AT Commands
3GPP 07.07 ATComamnds-General commands 3GPP 07.07 AT Comamnds-Call Controlcommans
3GPP 07.07 AT Comamnds-Network Servicerelated commands
3GPP 07.07 AT Comamnds-MT control andstatus command
3GPP 07.07 AT Comamnds-GPRSCommands
3GPP 07.07 Mobile TerminationErrors
3GPP 07.05 SMS AT Commands
（2）Receiver
Receiver连接到RILD的服务套接口，接收读取RILD传递过来的ResponseParcel。Response分为两种类型，一种是URC，一种是命令应答。对于URC将会直接分发到通知注册表中的Handler。而命令应答则通过Receiver的异步通知机制传递到命令的发送者进行相应处理。
（3）Sender
Sender应该分为两部分架构，
上层函数调用CommandInterface将请求消息发送到Sender的架构。
Sender接收到EVENT_SEND消息后，将请求发送到RILD的架构。
（4）异步应答框架
Android设计者利用了Result Message和RILRequest对象来完成Request和Result的对应对于关系。在上层做调用的时候生成Result Message对象传递到ril_java，并在Modem有应答后，通过ResultMessage对象带回结果。如何保证该应答是该RILRequest的呢？Android设计者还提供了一个Token（令牌）的概念。在源代码中RILRequest的mSerail就用作了Token。Token用来唯一标识每次发送的请求，并且Token将被传递到RILD，RILD在组装应答是将Token写入，并传回到ril-java，ril-java根据该Token找到相应的Request对象。
（4.1）RIL命令的发送模式
协议的真正实现是在rild中，RIL-JAVA更多的是一个抽象和代理，我们在研究源代码的过程中就会体会到到RIL-JAVA中的命令函数都有一个共同的框架。
SendXxxCmd(传入参数Data，传出参数result){
组合RILRequest(请求号，result，mSerail)
Data->RR
send(RILRequest)： Message
}
1)RILRequest
请求号：
request将传递到RILD用以标识命令，request代表某个功能。例如拨叫的request号为：RIL_REQUEST_DIAL。在libs/telephony/ril_commands.h有定义。RILRequest.obtain@RILRequest根据命令请求号,传入参数ResultMessage，mSerail构造了一个RILRequest。ResultMessage将带回应答信息回到命令的发起者。
mSerail：
Android使用了一个RILRequest对象池来管理AndoirdRILRequest。mSerail是一个递增的变量，用来唯一标识一个RILRequest。在发送时正是用了该变量为Token,在rild层看到的token就是该mSerail。
EVENT_END:
EVENT_END@handleMessage@RILSender@RIL.java
2)发送步骤：
第一步：
生成RILRequest，此时将生成m_Serial（请求的Token)并将请求号，数据，及其Result Message对象填入到RILRequest中
第二步：
使用send将RILRequest打包到EVENT_SEND消息中发送到到RIL SenderHandler，
第三步：
RilSender接收到EVENT_SEND消息，将RILRequest通过套接口发送到RILD，同时将RILRequest保存在mRequest中以便应答消息的返回。
（4.2） 接收模式
第一步：分析接收到的Parcel，根据类型不同进行处理。
第二步：根据数据中的Token（mSerail),反查mRequest,找到对应的请求信息。
第三步：将是数据转换成结果数据。
第四步：将结果放在RequestMessage中发回到请求的发起者。
4.3)详细的GSMCallTracker,RIL-Java函数对照
Android电话系统之GSMCallTracker
通话连接管理
GSMCallTracker在本质上是一个Handler。
GSMCallTracker是Android的通话管理层。GSMCallTracker建立了ConnectionList来管理现行的通话连接，并向上层提供电话调用接口。
在GSMCallTracker中维护着通话列表：connections。顺序记录了正连接上的通话，这些通话包括：ACTIVE，DIALING，ALERTING，HOLDING，INCOMING，WAITING等状态的连接。GSMCallTracker将这些连接分为了三类别进行管理：
RingingCall: INCOMING,WAITING
ForegourndCall: ACTIVE, DIALING,ALERTING
BackgroundCall: HOLDING
上层函数通过getRingCall()，getForegrouandCall()等来获得电话系统中特定通话连接。
为了管理电话状态，GSMCallTracker在构造时就将自己登记到了电话状态变化通知表中。RIL-Java一收到电话状态变化的通知，就会使用EVENT_CALL_STATE_CHANGE通知到GSMCallTacker
1 RIL-JAVA中发起电话连接列表操作
在RIL-JAVA中涉及到CurrentCallList查询的有以下几个操作：
（1）hangup
（2）dial
（3）acceptCall
（4）rejectCall
在GSMcallTracker在发起这些调用的时候都有一个共同的ResultMessage构造函数：obtainCompleteMessage()。obtainCompleteMessage()实际上是调用：
obtainCompleteMessage(EVENT_OPERATION_COMPLETE)
这就意味着在这些电话操作后，GSMCallTracker会收到EVENT_OPERATION_COMPLETE消息，于是我们将目光转移到handleMessage()@GSMCallTracker的EVENT_OPERATION_COMPLETE事件处理：operationComplete@GSMCallTracker。
operationComplete（）操作会使用cm.getCurrentCalls(lastRelevantPoll)调用，向RILD发起RIL_REQUEST_GET_CURRENT_CALLS调用，这个最终就是向Modem发起AT+CLCC，获取到真正的电话列表。
2 在RILD中，引起getCurrentCalls调用
（1）在RILD中，收到URC消息：
+CRING
RING
NO CARRIER
+CCWA
将会使用RIL_onUnsolicitedResponse(RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED)，主动向ril-java上报RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED消息。
（2）在处理requestCurrentCalls时，使用CLCC查询通话连接（CALL TABLE）后，如何发现有callTable不为空则开启一个定时器，主动上报RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED消息，直到没有电话连接为止。
在RIL-Java层收到RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED这个URC，并利用mCallStateRegistrants.notifyRegistrants(new AsyncResult(null, null,null))来通知电话状态的变化，此时GSMTracker会接收到EVENT_CALL_STATE_CHANGE消息，并使用
来发起查询，并更新JAVA层的电话列表。
3 handlePollCalls电话列表刷新
lastRelevantPoll =obtainMessage(EVENT_POLL_CALLS_RESULT)
我们这里就从可以看到获取到的电话列表Result使用handlePollCalls进行了处理。Result实际上是一个DriverCall列表，handlePollCalls的工作就是将当前电话列表与RIL-Java的电话列表对比，使用DriverCall列表更新CallTracker的电话列表connections,并向上传递电话状态改变的通知。
以后慢慢消化......
摘自Linux公社---http://www.linuxidc.com/
华为开发者空间，是为全球开发者打造的专属开发空间，汇聚了华为优质开发资源及工具，致力于让每一位开发者拥有一台云主机，基于华为根生态开发、创新。
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)