Android GSM 驱动模块详细分析

核心提示：libreference-ril处理,handler是reference-ril.c中的onRequest.onRequest进行一个简单的switch分发,我们依然来看RIL_REQUEST_DIAL流程是 onRequest-->requestDial-->at_send_command-->at

libreference-ril处理,handler是reference-ril.c中的onRequest.

onRequest进行一个简单的switch分发,我们依然来看RIL_REQUEST_DIAL

流程是 onRequest-->requestDial-->at_send_command-->at_send_command_full-->at_send_command_full_nolock-->writeline

requestDial中将命令和参数转换成对应的AT命令,调用公共send command接口at_send_command.

除了这个接口之外,还有 at_send_command_singleline,at_send_command_sms,at_send_command_multiline 等,这是根据at返回值,以及发命令流程的类型来区别的.比如at+csq这类,需要at_send_command_singleline,而发送短信,因为有prompt提示符">",传裸数据,结束符等一系列操作,需要专门用at_send_command_sms来实现.

然后执行at_send_command_full,前面几个接口都会最终到这里,再通过一个互斥的at_send_command_full_nolock调用,然后完成最终的写出操作,在writeline中,写出到初始化时打开的设备中.

writeline返回之后,还有一些操作,如保存type等信息,供response回来时候使用,以及一些超时处理. 不再详述.

到这里,request的详细流程,就分析完毕了.

response流程

前文对request的分析， 终止在了at_send_command_full_nolock里的writeline操作，因为这里完成命令写出到硬件设备的操作，接下来就是等待硬件响应，也就是response的过程了。我们的分析也是从这里开始。

response信息的获取，是在第一篇初始化分析中，提到的readerLoop中。由readline函数以‘行’为单位接收上来。

AT的response有两种，一是主动上报的，比如网络状态，短信，来电等都不需要经过请求，有一unsolicited词语专门描述。另一种才是真正意义上的response，也就是命令的响应。

这里我们可以看到，所有的行，首先经过sms的自动上报筛选，因为短信的AT处理通常比较麻烦，无论收发都单独列出。这里是因为要即时处理这条短信消息(两行，标志+pdu)，而不能拆开处理。处理函数为onUnsolicited(由s_unsolHandler指向)，我们等下介绍。

除开sms的特例，所有的line都要经过processLine，我们来看看这个流程：

processLine

|----no cmd--->handleUnsolicited //主动上报

|----isFinalResponseSuccess--->handleFinalResponse //成功,标准响应