Android RIL代码详细分析

 

RIL代码分析

代码位于：android/hardware/ril

1rild.c中的main()函数提供了rild的入口

首先，通过main函数的传参，cmdline，内核选项等方式获取rild.libpath和rild.libargs。

我们这里主要是：/system/lib/libreference-ril.so。

2RIL_startEventLoop():建立消息队列的机制，开始事件的监听

函数RIL_startEventLoop()开启了一标识符为s_tid_dispatch的线程，线程的入口函数为eventLoop()。

ril_event_init()进行消息队列的初始化，主要是初始化读文件描述符集readfds,time_list,pending_list和watch_table；后面三个都是ril_event的结构体变量

struct ril_event { struct ril_event *next; struct ril_event *prev; int fd; int index; bool persist; struct timeval timeout; ril_event_cb func; void *param;};

由定义可以看出它是一个双向链表。（重要的数据结构，后面会反复使用）

通过pipe()创建一个无名管道，对这个管道的读写描述符分别为：

ret = pipe(filedes); ... s_fdWakeupRead = filedes[0]; s_fdWakeupWrite = filedes[1]; 

创建一个s_wakeupfd_event的ril_event，消息的fd为s_fdWakeupRead，消息的处理函数为processWakeupCallback()；这个处理函数主要是读取管道内的消息。

将s_wakeupfd_event加入消息队列并触发消息队列：

ril_event_add(ev)：将ev加入watch_table[i]；将ev->fd加入读文件描述符集readFds。

triggerEvLoop()：如果s_tid_dispatch 线程结束，通过s_fdWakeupWrite写一个变量触发消息队列。

ril_event_loop()：将读文件描述符集加入select()中，阻塞等待其变化。

processTimeouts()：遍历time_list链表，查看是否有消息超时，如果超时移除链表。

processReadReadies()：将watch_table[i]中非空消息加入等待链表pending_list；并且从select()阻塞列表中移除watch_table[i]。

firePending()：从pending_list中取出一条消息并执行消息请求函数。

上面几个函数反复涉及到双向链表的结点加入和删除操作。

总之，RIL_startEventLoop()并没有真正的接收消息并处理，只是通过一个无名管道唤醒消息队列。

3RIL_Init：建立起和硬件基带模块的交互

通过dlopen打开rilLibPath下动态库，并找到函数RIL_Init()函数的入口地址。

可以看出RIL_Init函数返回一个RIL_RadioFunctions的结构体指针：

typedef struct { int version; /* set to RIL_VERSION */ RIL_RequestFunc onRequest; RIL_RadioStateRequest onStateRequest; RIL_Supports supports; RIL_Cancel onCancel; RIL_GetVersion getVersion;} RIL_RadioFunctions;

RIL_RequestFunc等是ril.h@hardware/ril/include/Telephony/中定义的函数指针，通过RIL_Init函数指针回调的形式给结构体中的函数赋值。

首先通过switch case获取libargs中的s_device_path；然后创建一个标识符为s_tid_mainloop，入口地址为mainLoop的线程。

mainLoop()：对获取各种s_device_path作处理，如果是模拟器，创建qemud Socket的客户端，建立Socket连接；如果是usb虚拟串口终端设备，则打开这个终端设备并关闭其回显功能。（后面的内容我就基于usb虚拟串口终端设备分析）

at_open(fd,onUnsolicited)：对打开的标准usb转串口设备进行各种ioctl操作，并新开启一个标识符s_tid_reader，入口为readerLoop的线程。

readerLoop()----->readline()：读取usb转串口设备上的各种AT命令并返回一个命令常量指针

processLine()：解析上面传回的AT命令。这个包括对命令类型的判断和相应命令的Handler处理。（这里的AT命令限于被动请求命令，例如网络状态，新信息通知等）

到这里我们就来分析下具体的Handler处理：

首先，从at_open()中将onUnsolicited赋值给函数指针类型的全局变量s_unsolHandler，在processLine()中直接调用handleUnsolicited()函数，继而handleUnsolicited()函数再调用s_unsolHandler(line)进行AT命令解析。所以最终的被动请求命令解析发生的onUnsolicited()函数中：

通过一系列if else语句对各种被动请求命令做判断。最终都会调到在ril.h中定义的一个函数指针

struct RIL_Env { void (*OnRequestComplete)(RIL_Token t, RIL_Errno e, void *response, size_t responselen); void (*OnUnsolicitedResponse)(int unsolResponse, const void *data, size_t datalen); void (*RequestTimedCallback) (RIL_TimedCallback callback, void *param, const struct timeval *relativeTime);};

那么这个函数指针是如何被赋值的呢？

1）在RIL_Init()函数开始的时候有一个赋值操作：

这个s_rilenv 是一个RIL_Env类型的全局结构体指针变量

2）.作为参数传递过来的env，定义在rild.c中

s_rilenv = env;static struct RIL_Env s_rilEnv = { RIL_onRequestComplete, RIL_onUnsolicitedResponse, RIL_requestTimedCallback}; 

这样我们就获取了RIl_Env结构体的函数指针具体地址。

从声明我们发现这个RIL_onUnsolicitedResponse定义在ril.cpp@/hardware/libril中

3）从RIL_onUnsolicitedResponce中我们还是不能获取具体被动请求命令（例如：RIL_UNSOL_RESPONSE_NEW_SMS_STATUS_REPORT）的句柄。

4）后来发现，在RIL_onUnsolicitedResponce函数的开始有一个关于s_registerCalled的判断，如果没有调用过RIL_register()则返回。从此，我们可以断定在RIL_register()中对具体的函数指针进行了赋值。

4RIL_register()

代码位于/hardware/libril/ril.cpp中。

将RIL_Init()函数返回的RIL_RadioFunctions结构体memcpy到s_callbacks中（后面使用）

并对两个大的结构体数组进行自检：

typedef struct { int requestNumber; void (*dispatchFunction) (Parcel &p, struct RequestInfo *pRI); int(*responseFunction) (Parcel &p, void *response, size_t responselen);} CommandInfo;typedef struct { int requestNumber; int (*responseFunction) (Parcel &p, void *response, size_t responselen); WakeType wakeType;} UnsolResponseInfo;static CommandInfo s_commands[] = {#include "ril_commands.h"};static UnsolResponseInfo s_unsolResponses[] = {#include "ril_unsol_commands.h"};

定义的过程相当于给每个request的确定了操作句柄。（确定了上面的推断）

创建一个s_fdListen的socket与rild连接并监听；将s_fdListen加入消息队列；

创建一个s_fdDebug的socket与rild-debug连接并监听；将s_fdDebug加入消息队列

在这里我们可以总结一下RIL中的消息队列：

1.s_fdListen：与上层的rild socket通信；

2.s_fdDebug：与上层的rild-debug通信；

3.s_fdWakeup_event：无名管道，用于队列的唤醒；

这三个描述符最终都被加入readFds，通过selects()函数阻塞等待。

接着上面分析：

通过s_fdCommand = accept(s_fdListen, (sockaddr *) &peeraddr, &socklen)获得第一个连接请求之后创建了一个新的socket：s_fdCommand。

通过调用ril_event_set()和rilEventAddWakeup()将新创建的socket加入消息队列。新消息的处理函数为processCommandsCallback()

然后再调用processCommandBuffer()对命令进行解析（解析的过程类似于刚刚分析的RIL_Init中对虚拟串口设备发送的状态的解析。）

定义一个Parcel用来装载上层传来的主动请求命令，对传来的命令自检（这里的主动请求命令定义在全局结构体数组变量s_commands中）。然后通过调用

对于90多个主动请求命令的处理句柄，这里不一一分析了。

但每个dipatchFunction()函数最终都会调用

这个s_callbacks是一个全局变量的RIL_RadioFunctions变量。

（RIL_Register开始的时候被初始化）

onRequest()@/hardware/ril/reference-ril/reference-ril.c：主动请求命令的最主要函数。

通过switch和大量的case对各种主动请求命令处理。例如：

pRI->pCI->dispatchFunction(p, pRI);

然后requestSendSMS()---->at_send_command_sms()--->at_send_command_full()----->at_send_command_full_nolock------>writeline (command)--->written = write (s_fd, s + cur, len - cur)

说明一下：全局变量s_fd在RIL_Init的at_open()函数中被赋值（即USB虚拟串口设备描述符）

另外，执行完命令发送后必须要执行

RIL_onRequestComplete(t, RIL_E_SUCCESS, &response, sizeof(response))进行状态返回。

我们这里对RIL_Regisger进行下总结，这部分主要是创建一个socke与上层进行通信，接受来自上层的主动请求命令，然后Vendor-ril.将这些主动命令转化成AT命令发送到USB虚拟串口终端。