Android源码分析：RIL代码分析

 

源码分布

ril模块放置在源码包中的hardware/ril目录下，包含以下几个目录:

hardware/ril/rild/rild： 守护进程rild，利用socket与Android Framework中的telephony模块进行通讯。
在该目录下还有一个radiooptions.c，它是个二进制工具程序，用于切换Radio的工作状态。

hardware/ril/reference-ril：GSM的参考实现。客户定制时，需移植的部分，要给出自己的实现。

hardware/ril/reference-cdma-sms：CDMA部分针对SMS的参考实现。定制部分。

hardware/ril/libril：为参考实现提供支撑的功用库。守护进程rild和reference-ril会使用它。

hardware/ril/include：包含的头文件

总述

Android Framework会为上层App提供telephony服务，而这些telephony服务会通过socket机制与守护进程rild交互。telephony向本地socket中写入相应的request，rild守护进程监听来自telephony一侧发来的请求，然后将请求转化为ril_event放到队列里。

守护进程这一侧启动一个线程（dispatch线程）去处理这个队列，将请求转换为不同的AT命令写入到Modem串口设备中，若需要等待Modem回送Response，则睡眠，等待另一个线程reader从Modem设备文件中读取数据，将回送结果填充到发送AT命令时所分配的一个结果缓冲区后，然后唤醒dispatch线程。这时发送命令at_send_command函数簇可以返回，或者是等待超时后返回，这个超时时间可以指定。返回结果将被回送给Telephony Service。这种结果的回送当是内建数据类型时可通过parcel直接传递，若是raw data，则需向socket里写入raw数据。

守护进程还启动一个reader线程不断读取来自Modem侧的Response字符串。每次读取一行，然后对该行进行解析。当读取的行是最后一行时，表示这个response结束，可以得知此次执行的AT命令是否成功。若不是最后一行，则将结果添加到字符串链表中，再去读取下一行，直至一个完整的response结束。当response结束时，就要唤醒正在发送这个AT请求的dispatch线程，让其将返回结果传递给上层的telephony service。

Modem侧上报的有些信息属于它主动上报的，不属于AT执行结果，如来电话的响铃RING或有新SMS等。这些属于unsolicited消息。这也是由reader线程进行处理，它也是解析完结果字符串后将它们送给上层的telephony service。

针对AT命令的处理，以及往Modem串口设备中读写数据，都是在reference-ril库中实现，每一个baseband厂家都可以给出针对自己Modem的AT命令集实现。该实现将被编译成单独的动态连接库。AT命令通过UART口与Modem进行交互。在某些未提供UART口的硬件系统中，模拟出一个UART口与Modem进行通讯。

 

 

在hardware/ril/rild/代码中有两块，一是rild守护进程的代码；二是radiooptions，一个切换Modem的小程序的代码。

rild守护进程

hardware/ril/rild/rild.c是守护进程rild的代码

hardware/ril/rild/radiooptions.c二进制工具程序radiooptions的代码，用于切换radio的状态。

在rild中主要完成下面这些功能：

选定reference-ril参考实现库路径

在rild守护进程的main函数中，首先要指定参考实现库.so文件的路径。可以在启动rild守护进程时，在命令行参数中使用“-l”选项进行指定；另一个参数用于指定库的参数，比如指定所使用的Modem串口设备文件。用法如下：

Usage: rild -l <ril impl library> [-- <args for impl library>]

eg：rild -l /system/lib/your_libreference-ril.so --d /dev/ttyU0

若未在命令行参数中指定，则系统将从下面两个宏定义的属性进行中获取：

#define LIB_PATH_PROPERTY “rild.libpath”

#define LIB_ARGS_PROPERTY “rild.libargs”

而这个 两个属性值是通过文件build/ target/board/generic/system.prop中指定的：

rild.libpath=/system/lib/libreference-ril.so

rild.libargs=-d /dev/ttyU0

如果通过上述两个过程还没找到有效的参考实现库，将使用下面的宏定义的库（见行141）：

#define REFERENCE_RIL_PATH “/system/lib/libreference-ril.so”

用户权限切换

这部分属于Linux的权限管理。切换用户，具体参见文件与进程能力：

参见附录文档：
1. POSIX 文件能力：分配根用户的能力http://www.ibm.com/developerworks/cn/linux/l-posixcap.html

2.setuid函数的用法简介http://hi.baidu.com/%F2%DF%F2%D1%B7%C9%B9%FD%BC%D0%D6%F1%CC%D2/blog/item/d546fdc32c4f123ce5dd3b2b.html

 

启动Request事件循环

在启动Request事件循环之前，会打开该参考实现库libreference-ril.so：

dlHandle = dlopen(rilLibPath, RTLD_NOW);

RIL_startEventLoop();

打开它是为了完成后面的RIL_Init函数符号的解析。在该事件循环中，会启动一个事件分发dispatch线程，该线程调用processCommandBuffer解析来自Android Framework Telephony侧的request请求（根据request号查询数组s_commands，调用对应的分发函数。数组成员则是在头文件ril_commands.h中定义）

然后，启动事件循环，见RIL_startEventLoop函数（详见后续章节），再解析参考实现库libreference-ril.so里的函数符号“RIL_Init”，并从属性“rild.libargs”里获取调用它的参数列表，最后执行该参考实现库里的RIL_Init，返回新的回调函数并注册之。主要代码如下：

rilInit = (const RIL_RadioFunctions *(*)(const struct RIL_Env *, int, char **))dlsym(dlHandle, “RIL_Init”);
//…此处省略部分代码
property_get(LIB_ARGS_PROPERTY, args, “”);//属性键是“rild.libargs”
argc = make_argv(args, rilArgv);

//…此处省略部分代码

funcs = rilInit(&s_rilEnv, argc, rilArgv);

RIL_register(funcs);

rild守护进程先是找到reference-ril库，ril event事件循环，并也创建一个dispatch线程，分发处理各种ril event。接着解析RIL_Init函数，在其中创建一个mainloop线程。在 mainLoop线程中又会创建一个reader线程，用于读取来自Modem串口设备的response。

 

RIL_startEventLoop函数的代码在libril库中

radiooptions工具程序

可以在Linux命令行下，使用radiooptions来切换Radio状态，具体用法如下：

# /system/bin/radiooptions

Usage: radiooptions [option ] [extra_socket_args]

0 – RADIO_RESET,

1 – RADIO_OFF,

2 – UNSOL_NETWOR

3 – QXDM_ENABLE,

4 – QXDM_DISABLE

5 – RADIO_ON,

6 apn- SETUP_PDP

7 – DEACTIVE_PDP

8 number – DIAL_

9 – ANSWER_CALL,

10 – END_CALL

它把传递过来的参数写入“/dev/socket/rild-debug”标识的本地socket，不做其他操作。在rild守护进程会监听该socket，当有数据到达时，会调用相应的回调函数，解析发送过来的命令，并转换为相应的AT命令写入Modem。

具体过程是：在radiooptions这一侧，先判断参数个数，然后逐个将它们写入socket。在rild守护进程侧，守护进程注册回调函数RIL_RadioFunctions时，会监听该套接字，当套接字上有数据到达时，就调用ril.cpp文件中的回调函数debugCallback，进行实际的向硬件BP侧Modem发送AT命令。

库libril

 

在libril库中共有5个源代码文件，它们是：

1. 定义ril_event数据结构及其上面的操作的ril_event.h和ril_event.cpp
2. 定义主动请求的AT命令集的文件ril_commands.h和非主动请求的AT命令集文件ril_unsol_commands.h。它们构成了两个数组s_commands和s_unsolResponses中的元素。主动请求的AT命令是AP侧主动向BP Modem发出查询设置的命令，而非主动则是BP侧主动发送来的状态报告。
3. 定义分发和处理Request Event的ril.cpp文件

先来看一下ril_event数据类型，及定义在该类型上的函数操作。

ril_event数据结构

头文件中定义了数据类型ril_event，声明了添加删除函数，部分代码如下：

 

struct ril_event {
struct ril_event *next;
struct ril_event *prev;

int fd;//用于通讯的文件描述符
int index;//该event在队列中的索引
bool persist;//是否保存下来的标志
struct timeval timeout;//等待多长时间后超时
ril_event_cb func;//处理event的回调函数
void *param;//传递给回调函数的参数指针
};

// Initialize internal data structs
void ril_event_init();

// Initialize an event
//初始化一个ril_event，指定它的用于通讯的文件符、是否存储、回调函数以及回调函数的参数
void ril_event_set(struct ril_event * ev, int fd, bool persist, ril_event_cb func, void * param);

// Add event to watch list
//添加到一个ril_event到watch_table中
void ril_event_add(struct ril_event * ev);

// Add timer event
//添加一个ril_event至timer_list中
void ril_timer_add(struct ril_event * ev, struct timeval * tv);

// Remove event from watch list
//从watch_table中删除指定的ril_event
void ril_event_del(struct ril_event * ev);

// Event loop
void ril_event_loop();//进入循环并阻塞，除非有数据到达或超时

上面定义了ril_event以及对几个ril_event列表的添加删除操作。因为多线程的缘故，这些对列表的操作，都采用了互斥锁同步机制。当进入添加删除操作之前，上锁，操作结束后，释放锁。

 

在ril_event.cpp中声明的主要的全局变量有：

 

//rild守护进程调用RIL_register(funcs)将从libreference库中的 解析的RIL_Init函数符号赋值给它：
RIL_RadioFunctions s_callbacks = {0, NULL, NULL, NULL, NULL, NULL};

//……

static struct ril_event s_commands_event;
static struct ril_event s_wakeupfd_event;
static struct ril_event s_listen_event;
static struct ril_event s_wake_timeout_event;
static struct ril_event s_debug_event;

//……

/*
上层发送来的AT请求经转换为RequestInfo后挂在它上面，因此将串行执行AT请求，见processCommandBuffer
*/
static RequestInfo *s_pendingRequests = NULL;

static RequestInfo *s_toDispatchHead = NULL;
static RequestInfo *s_toDispatchTail = NULL;

//……

static UserCallbackInfo *s_last_wake_timeout_info = NULL;

//……

static CommandInfo s_commands[] = {
#include “ril_commands.h”
};

static UnsolResponseInfo s_unsolResponses[] = {
#include “ril_unsol_commands.h”
};

 

数组s_commands 和s_unsolResponses用来查询对应的分发 函数。

再来看一下ril_event_init()函数：

void ril_event_init()
{
MUTEX_INIT();
FD_ZERO(&readFds);
init_list(&timer_list);
init_list(&pending_list);
memset(watch_table, 0, sizeof(watch_table));
}

它初始化一个读文件集和三个列表：

static fd_set readFds;
static struct ril_event * watch_table[MAX_FD_EVENTS];//目前定义的最多为8个
static struct ril_event timer_list;
static struct ril_event pending_list;

watch_table列表中的各个ril_event对应的文件符将被设置在文件描述符集readFds

中。在往watch_table添加event时设置了文件描述符至描述符集readFds，以供监视，在processReadReadies中处理watch_table时则用FD_ISSET(rev->fd, rfds)来判断是否被设置可以有数据以供读取了。

 

 

 

文件ril.cpp

 

RIL_startEventLoop与eventLoop函数

RIL_startEvent函数功能是创建一个新分发event的dispatch线程，线程id赋给ril.cpp中的本地全局 变量s_tid_dispatch，线程执行入口点函数是eventLoop。

RIL_startEventLoop在主进程中执行，在其创建的dispatch线程执行eventLoop函数后，就在s_startupCond上等待dispatch线程初始化各个ril_event列表。当eventLoop完成各个列表的初始化后，RIL_startEventLoop才会继续往下执行直至返回到rild.c中，执行后面的代码，否则它在同步条件s_startupCond上一直等待下去。

下面的代码是RIL_startEventLoop创建dispatch线程并一直等待它完成初始化各个ril_event列表：

/* spin up eventLoop thread and wait for it to get started */
s_started = 0;
pthread_mutex_lock(&s_startupMutex);
pthread_attr_init (&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
ret = pthread_create(&s_tid_dispatch, &attr, eventLoop, NULL);
while (s_started == 0) {
pthread_cond_wait(&s_startupCond, &s_startupMutex);
}
pthread_mutex_unlock(&s_startupMutex);

eventLoop函数

它调用ril_event_init完成各个ril_event列表的初始化，包括指定ril_event的回调处理函数。eventLoop函数主要代码如下：

ril_event_init();
pthread_mutex_lock(&s_startupMutex);
s_started = 1;
pthread_cond_broadcast(&s_startupCond);
pthread_mutex_unlock(&s_startupMutex);//唤醒在s_startupMutex上等待的线程
ret = pipe(filedes);//创建管道，第一个用来读，第二个用来写
//…此处删除了错误检查代码
s_fdWakeupRead = filedes[0];
s_fdWakeupWrite = filedes[1];
fcntl(s_fdWakeupRead, F_SETFL, O_NONBLOCK);//设置为非阻塞模式
ril_event_set (&s_wakeupfd_event, s_fdWakeupRead, true, processWakeupCallback, NULL);//给本地全局变量赋值，接着会将其添加到列表中
rilEventAddWakeup (&s_wakeupfd_event);//添加一个event中至watch列表中，然后写一个空格字符到管道的写端，唤醒该线程

ril_event_loop();

它在完成三个ril event列表的初始化之后，就唤醒主进程，让其执行RIL_startEventLoop的剩下部分。接着它创建一个管道，管道的读描述符被绑定到本地全局的s_wakeupfd_event上，然后将该本地全局的event添加到watch列表中，并写入一个空字符唤醒它。唤醒后执行的回调函数为processWakeupCallback。

最后，它进入ril_event.cpp中的ril_event_loop()函数，处理各个列表上的ril_event：调用它们的回调函数（processWakeupCallback），处理它们。详见下面：

 

ril_event_loop()

它启动一个无限循环，不断进行如下内容：

首先不断检查timer list上是否有超时的ril_event，若有就计算超时时间，并传递给下面的select调用，让它检查文件读选择符集readFds是否有文件（或Socket）中有数据变得可读。若有可读或超时，则select返回，否则一直阻塞在该调用上。

 

for (;;) {
// make local copy of read fd_set
memcpy(&rfds, &readFds, sizeof(fd_set));
if (-1 == calcNextTimeout(&tv)) {//根据下一个timerlist中最近一个要到//来的event，计算最快的即将到来的超时时间
// no pending timers; block indefinitely
dlog(“~~~~ no timers; blocking indefinitely ~~~~”);
ptv = NULL;//无需等待，则下面的select超时参数为空，将会无限等待下
//去，除非有可读的数据就绪
} else {
dlog(“~~~~ blocking for %ds + %dus ~~~~”, (int)tv.tv_sec, (int)tv.tv_usec);
ptv = &tv;//超时等待时间，select可以立即返回，对其进行处理
}
printReadies(&rfds);
n = select(nfds, &rfds, NULL, NULL, ptv);//检查读文件符集，有数据可读//时则文件描述符标志被修改，select返回，否则一直阻塞等待下去，除非超时；若超时参数为//0，则一直等待下去，除非所监控的文件集中有数据到达变得可读。

// Check for timeouts
processTimeouts();

// Check for read-ready
processReadReadies(&rfds, n);

// Fire away
firePending();

}

接着系统开始处理超时： processTimeouts将超时的ril_event从timer_list中移除，添加到pending_list中，等待处理。

processReadReadies 则是监控watch_table上的所有event，将它们从watch_table移除，填加到pending_list中。

最后一个firePending则是调用pending_list中的各个回调函数并将它们从列表中移除。

timeout超时的回调函数是ril.cpp文件userTimerCallback

 

RIL_register (const RIL_RadioFunctions *callbacks)函数

主要功能是将reference-ril库中的本地s_callbacks赋给libril中的全局的s_callbacks，这样，在Android Framework中通过IPC Parcel协议传递的Request及其数据通过dispatch线程分发给reference-ril中的onRequest进行处理。最后它开始，监听两个套接字上是否有数据到来。

首先，它对传进来的实参callbacks进行正确性检查后，通过内存拷贝的方式赋给libril中全局变量s_callbacks。该实参保存了reference-ril库中的几个回调函数指针及其它信息：

/*** Static Variables ***/
static const RIL_RadioFunctions s_callbacks = {
RIL_VERSION,
onRequest,
currentState,
onSupports,
onCancel,
getVersion
};

内存拷贝的方式赋值：

memcpy(&s_callbacks, callbacks, sizeof (RIL_RadioFunctions));

接着，它监听在“/dev/socket/rild”上的socket： s_fdListen，它监听来自Android Telephony Service的Request。

ril_event_set (&s_listen_event, s_fdListen, false, listenCallback, NULL);

rilEventAddWakeup (&s_listen_event);

它设置本地全局的s_listen_event，该event与s_fdListen绑定，然后将该event添加到watch列表中。当有数据到达时，会在dispatch线程中的eventLoop中调用listenCallback。

Request数据通过Parcel协议写入socket，在dispatch线程中的eventLoop循环中（watcher列表）监控这些socket是否有数据写入（Telephony去写入请求），当有数据到达时，文件描述符被设置，于是event的回调函数被调用，

 

另外一个“/dev/socket/rild-debug”上的socket：s_fdDebug，监听来自radiooptions工具程序的请求操作，处理请求的回调函数是debugCallback：

ril_event_set (&s_debug_event, s_fdDebug, true, debugCallback, NULL);

rilEventAddWakeup (&s_debug_event);

该回调函数的也是在dispatch线程中的eventLoop中被调用的。

listenCallback

它接受远端的一个套接字连接，然后返回队列上一个新的套接字描述符。接着在下面还要进行权限检查，如果不是phone process中发起的连接，将关闭s_fdCommand，并返回不再往下执行。

s_fdCommand = accept(s_fdListen, (sockaddr *) &peeraddr, &socklen);

接着，为它分配一个记录流的缓冲区，设置一个ril_event，将其添加到watch列表中，监视新数据的到来。当有数据到来时，调用processCommandsCallback进行处理。

p_rs = record_stream_new(s_fdCommand, MAX_COMMAND_BYTES);

ril_event_set (&s_commands_event, s_fdCommand, 1, processCommandsCallback, p_rs);

rilEventAddWakeup (&s_commands_event);

onNewCommandConnect();

 

processCommandsCallback

当读socket出错时则关闭socket，将其从watch列表中删除，释放前面分配的缓冲区，重新将s_fdListen加入到watch列表中（因为在调用回调函数后，event将被从列表中清除）。正常情况下则调用processCommandBuffer进行处理来自Parcel里的数据。

 

processCommandBuffer

它首先从Parcel里读取request请求号和token，然后分配一个RequestInfo缓冲区，查询数组得到对应s_commands[request]。

status = p.readInt32(&request);//读取数据
status = p.readInt32 (&token);

//…

pRI = (RequestInfo *)calloc(1, sizeof(RequestInfo));
pRI->token = token;
pRI->pCI = &(s_commands[request]);//将全局数组项的地址赋给它

ret = pthread_mutex_lock(&s_pendingRequestsMutex);
assert (ret == 0);
pRI->p_next = s_pendingRequests;//这两行，将request添加到队列头部
s_pendingRequests = pRI;
ret = pthread_mutex_unlock(&s_pendingRequestsMutex);
assert (ret == 0);
/* sLastDispatchedToken = token; */
pRI->pCI->dispatchFunction(p, pRI);//调用request对应的dispatch函数

 

在解析完成后查询数组s_commands构建的数据结构类型（见ril.cpp），它们用于调用底层的AT发送函数。

typedef struct {
int requestNumber;//请求号
void (*dispatchFunction) (Parcel &p, struct RequestInfo *pRI);
int(*responseFunction) (Parcel &p, void *response, size_t
responselen);
} CommandInfo;

typedef struct RequestInfo {
int32_t token; //this is not RIL_Token
CommandInfo *pCI;
struct RequestInfo *p_next;
char cancelled;
char local;//responses to local commands do not go back to command process
} RequestInfo;

 

 

用于主动上报Modem发送来的信息结构体如下：

typedef struct {
int requestNumber;
int (*responseFunction) (Parcel &p, void *response, size_t responselen);
WakeType wakeType;
} UnsolResponseInfo;

typedef struct UserCallbackInfo {
RIL_TimedCallback p_callback;
void *userParam;
struct ril_event event;
struct UserCallbackInfo *p_next;
} UserCallbackInfo;

 

 

dispatchXXX函数簇

dispatchXXX函数簇，被上面的缓冲区处理函数调用。这些函数进一步从socket里读取数据，解析之后作为待处理的数据，转给reference-ril库中的onRequest函数进行处理。具体是从parcel里读取数据，解析后调用s_callbacks.onRequest函数进行处理。

 

Ril.cpp里提供了多个dispatch函数，用来处理不同类型的AT请求。

static void dispatchVoid (Parcel& p, RequestInfo *pRI);

static void dispatchString (Parcel& p, RequestInfo *pRI);

static void dispatchStrings (Parcel& p, RequestInfo *pRI);

static void dispatchInts (Parcel& p, RequestInfo *pRI);

static void dispatchDial (Parcel& p, RequestInfo *pRI);

static void dispatchSIM_IO (Parcel& p, RequestInfo *pRI);

static void dispatchCallForward(Parcel& p, RequestInfo *pRI);

static void dispatchRaw(Parcel& p, RequestInfo *pRI);

static void dispatchSmsWrite (Parcel &p, RequestInfo *pRI);

static void dispatchCdmaSms(Parcel &p, RequestInfo *pRI);

static void dispatchCdmaSmsAck(Parcel &p, RequestInfo *pRI);

static void dispatchGsmBrSmsCnf(Parcel &p, RequestInfo *pRI);

static void dispatchCdmaBrSmsCnf(Parcel &p, RequestInfo *pRI);

static void dispatchRilCdmaSmsWriteArgs(Parcel &p, RequestInfo *pRI);

当AT请求执行完成后，用于发送Modem侧的回复的函数簇为：

static int responseInts(Parcel &p, void *response, size_t responselen);

static int responseStrings(Parcel &p, void *response, size_t responselen);

static int responseString(Parcel &p, void *response, size_t responselen);

static int responseVoid(Parcel &p, void *response, size_t responselen);

static int responseCallList(Parcel &p, void *response, size_t responselen);

static int responseSMS(Parcel &p, void *response, size_t responselen);

static int responseSIM_IO(Parcel &p, void *response, size_t responselen);

static int responseCallForwards(Parcel &p, void *response, size_t responselen);

static int responseDataCallList(Parcel &p, void *response, size_t responselen);

static int responseRaw(Parcel &p, void *response, size_t responselen);

static int responseSsn(Parcel &p, void *response, size_t responselen);

static int responseSimStatus(Parcel &p, void *response, size_t responselen);

static int responseGsmBrSmsCnf(Parcel &p, void *response, size_t responselen);

static int responseCdmaBrSmsCnf(Parcel &p, void *response, size_t responselen);

static int responseCdmaSms(Parcel &p, void *response, size_t responselen);

static int responseCellList(Parcel &p, void *response, size_t responselen);

static int responseCdmaInformationRecords(Parcel &p,void *response, size_t responselen);

static int responseRilSignalStrength(Parcel &p,void *response, size_t responselen);

static int responseCallRing(Parcel &p, void *response, size_t responselen);

static int responseCdmaSignalInfoRecord(Parcel &p,void *response, size_t responselen);

static int responseCdmaCallWaiting(Parcel &p,void *response, size_t responselen);

 

 

其它函数功能释义：

 

strdupReadString(Parcel &p)

从Parcel中读取UTF16编码的字符串，并把它转换为UTF8格式，然后返回之。

 

writeStringToParcel(Parcel &p, const char *s)

将UTF8格式字符串转换为UTF16后，写入Parcel

 

 

processWakeupCallback，它用于清理管道中的数据。Watch列表的作用仅是将event的处理从select中唤醒过来？（TODO）

todo

 

 

issueLocalRequest(int request, void *data, int len)

根据request号（即数组s_commands中的索引，即s_commands[request]）构建一个RequestInfo对象pRI，token设置为0xffffffff，local设置为1；然后将其添加到s_pendingRequests列表的头部（将其next指针指向原s_pendingRequests，将新的s_pendingRequests指向它）；最后，调用s_callbacks.onRequest(request, data, len, pRI);

因为AT请求一般都来自于上层的Framework中的Telephony部分，然后rild解析后得到，此函数提供了一个直接声称AT请求的一个入口。接收到radiooptions工具程序发送来的请求后在debugcallback中会得到调用。

 

RIL_onRequestComplete(RIL_Token t, RIL_Errno e, void *response, size_t responselen)

它在响应request完成后，将response写入到parcel中。它将调用reponseXXX函数簇

todo

responseXXX函数簇

 

todo

RIL_requestTimedCallback

它将一个回调函数与一个timer ril_event绑定，然后添加到timer list中，timeout后，在dispatch的线程中得到执行。

todo

RIL_onUnsolicitedResponse

todo

reference-ril库

 

mainLoop线程

在reference-ril库中的RIL_Init函数主要完成两个功能，一是根据传递过来的参数，打开不同的设备，二是创建一个线程，将线程号指定给s_tid_mainloop。打开设备的用法如下：

reference-ril requires: -p <tcp port> or -d /dev/tty_device

实际上，还可以指定一个参数s，指定使用socket方式，该socket值为1。

选项用来指定读写AT所要用的接口：用选项p指定端口号，优先级最高；用s指定socket优先级其次，用d指定AT设备，一般为/dev/tty_device，优先级最低，见mainLoop函数。

 

第二个任务是创建mailLoop线程，线程号s_tid_mainloop，函数入口点是mainLoop：

 

ret = pthread_create(&s_tid_mainloop, &attr, mainLoop, NULL);

 

mainLoop函数

 

先指定reader关闭和timeout时的回调函数；之后就进入for无限循环，打开AT交互设备，获取文件描述符，然后调用at_open打开at channel。当打开at channel时，创建一个reader线程，它读取Modem串口设备上的AT response。

打开文件获取描述符时，依照s_port、s_device_socket和s_device_path优先级顺序，当前者 空时，就检查后者，不为空就打开它，获取相应的文件描述符。

 

然后，调用libril库中ril.cpp的RIL_requestTimedCallback（它调用的是本地的一个全局结构体变量s_rilenv中的一个指针，而s_rilenv来自于rild中的s_rilenv，后者这个结构体中的函数指针都在libril库中ril.cpp中）。

附注：rild中的s_rilenv

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

 

RIL_requestTimedCallback函数将initializeCallback与一个Timer ril_event绑定，让其在一定时间间隔后（此处为0，意味着立即执行）执行回调函数initializeCallback。详见RIL_requestTimedCallback注释。

 

mainLoop线程在完成上述操作后，进入睡眠，等待at channel被关闭，当被关闭时，它被唤醒再次进入循环，然后再次执行上述指定回调函数和打开at channel的操作。

 

at_set_on_reader_closed(onATReaderClosed);
at_set_on_timeout(onATTimeout);
//进入无限循环
for(;;) {

/*此处省略代码：打开AT交互设备，获取文件描述符fd*/

ret = at_open(fd, onUnsolicited);

//…省略部分检查代码

RIL_requestTimedCallback(initializeCallback, NULL, &TIMEVAL_0);

//…

waitForClose();

//…

}

onRequest

当dispatch线程处理ril_event表上的event时，调用它们的回调函数，进而最终调用到onRequest函数。它首先检查Radio是不是不可用（unavailable），不可用时，只能查询SIM状态；当Radio关闭时，也只能查询SIM卡状态和Radio是否关闭。因此，遇到上述情况，只是调用ril.cpp中的RIL_onRequestComplete后直接返回：返回结果是一个空指针。

然后，onRequest根据请求号，要么调用request函数簇，或直接将来自Telephony的请求转为AT-command，调用atchannel.cpp中的发送函数将AT写到Modem串口设备中。完成后，调用

onUnsolicited

它会根据AT Response字符串行首的几个字符，判断是对哪个AT命令的响应，然后调用RIL_onUnsolicitedResponse函数告诉Telephony Service请求结果。

文件atchannel.c

部分数据结构释义：

 

typedef struct ATLine {
struct ATLine *p_next;
char *line;
} ATLine;//该数据结构定义了一个字符串列表，它表示了AT Response里的一组连续的字符串

typedef struct {
int success; /* true if final response indicates success (eg “OK”) */
char *finalResponse; /* eg OK, ERROR */
ATLine *p_intermediates; /* any intermediate responses */
} ATResponse;//一个完整的AT Response

函数void at_response_free(ATResponse *p_response)释放上述一个ATResponse对象的内存。对应的at_response_new()函数为内部的，只能在atchannel.c文件中使用。

 

 

 

at_open与reader线程

主要功能是将处理unsolicited 信息的handler赋给s_unsolHandler(在上面的mainLoop函数中，传递过来的onUnsolicited将被赋值给s_unsolHandler)，以备调用。第二个功能是创建一个新的读取Modem串口设备的线程reader，线程号为s_tid_reader，线程入口点为readerLoop，用于读取Modem设备送来的Response

todo

在reader线程中，readerLoop不断读取Modem串口设备文件，先读取一行，据此判断是否是SMS，若是还要再读一行，获取PDP文本，然后调用s_unsolHandler（见上面，在调用at_open函数时，它被指定为reference-ril.cpp中的onUnsolicited）进行处理。否则不为SMS类型消息时，调用processLine处理。

 

processLine

该函数处理来自AT Response。AT回送的结果，会有单行会多个行组成，最后一行往往标识了AT命令执行的结果是error还是ok。同样，有些Response是Modem主动上报的消息，不是对AT命令执行的响应。因此，此函数是处理来自Modem设备的一行数据，在readerLoop里反复不断读取调用该行。

它先检查当前的处理是否是一个新的AT Response，即还没有正在处理的response，此时调用handleUnsolicited函数。

再就是判断是否是最后的AT执行结果标识行，根据该行，分别标识出一个AT执行结果是否成功。

再判断是否是执行发送SMS后的Response

最后，判断不同的命令类型，执行不同的处理。

 

if (sp_response == NULL) {//若是新开始处理一个response
/* no command pending */
handleUnsolicited(line);
} else if (isFinalResponseSuccess(line)) {//如果行是最后的成功标识行
sp_response->success = 1;//设置response结果标志
handleFinalResponse(line);//
} else if (isFinalResponseError(line)) {//如果最后的结果行是错误标识行
sp_response->success = 0;// 设置response结果标志
handleFinalResponse(line);
} else if (s_smsPDU != NULL && 0 == strcmp(line, “> “)) {//若是发送SMS
// See eg. TS 27.005 4.3
// Commands like AT+CMGS have a “> ” prompt
writeCtrlZ(s_smsPDU);
s_smsPDU = NULL;
} else switch (s_type) {//根据类型不同的AT类型进行不同的结果处理
case NO_RESULT:
handleUnsolicited(line);
break;
case NUMERIC:
if (sp_response->p_intermediates == NULL
&& isdigit(line[0])
) {
addIntermediate(line);
} else {
/* either we already have an intermediate response or
the line doesn’t begin with a digit */
handleUnsolicited(line);
}
break;
case SINGLELINE:
if (sp_response->p_intermediates == NULL
&& strStartsWith (line, s_responsePrefix)
) {
addIntermediate(line);
} else {
/* we already have an intermediate response */
handleUnsolicited(line);
}
break;
case MULTILINE:
if (strStartsWith (line, s_responsePrefix)) {
addIntermediate(line);
} else {
handleUnsolicited(line);
}
break;
default: /* this should never be reached */
LOGE(“Unsupported AT command type %dn”, s_type);
handleUnsolicited(line);
break;
}

当readerLoop不断循环调用processLine时，当为对AT命令响应结果时，最终会走到最后的结果标识行，调用到handleFinalResponse函数，标识一个完整的AT Response结束，唤醒正在该结果上的等待的sent_at_command_full_nolock函数。

 

addIntermediate(line)

将reponse结果行保存到ATResponse中去：将字符串转为ATLine添加到ATResponse的ATLine链表中。

 

附注：

检查是不是SMS消息的标准是：AT的Response是不是以返回下面的字符做为前缀：

static const char * s_smsUnsoliciteds[] = {
“+CMT:”, //Received SMS indication
“+CDS:”, // +CDS Received SR indication
“+CBM:” //+CBM Received CBM indication
};

 

isFinalResponseSuccess (const char *line)

若AT命令的response行是标识AT执行成功的行，则返回1，否则返回0

原代码注释：returns 1 if line is a final response indicating success

它是根据下列字符进行判断：

static const char * s_finalResponsesSuccess[] = {
“OK”,
“CONNECT” /* some stacks start up data on another channel */
};

 

 

isFinalResponseError (const char *line)

AT命令的response行是标识AT执行失败的行，则返回1，否则返回0

原代码注释：returns 1 if line is a final response indicating error

它是根据下列字符进行判断：

static const char * s_finalResponsesError[] = {
“ERROR”,
“+CMS ERROR:”,
“+CME ERROR:”,
“NO CARRIER”, /* sometimes! */
“NO ANSWER”,
“NO DIALTONE”,
};

handleUnsolicited

 

at_close

关闭AT设备，即Modem。并将全局的s_readerClosed标志设为1。

 

int at_handshake()

每隔250ms，即睡眠250（#define HANDSHAKE_TIMEOUT_MSEC 250）ms后醒来，向Modem写入字符“ATE0Q0V1″，用于启动和保持At channel，见代码注释：Used to ensure channel has start up and is active。

 

void at_set_on_timeout(void (*onTimeout)(void))

void at_set_on_reader_closed(void (*onClose)(void))

这两个函数是设定回调函数的。设定的回调函数指针分别被赋给全局的s_onTimeout和s_onReaderClosed，以备超时后和reader进程关闭时被调用。

在mainLoop函数中，将onATTimeout和onATReaderClosed两个函数指针被赋值给s_onTimeout和s_onReaderClosed，执行关闭操作，将radio设置为unavailable状态。

 

int at_send_command_singleline (const char *command, const char *responsePrefix, ATResponse **pp_outResponse)

 

int at_send_command_numeric (const char *command, ATResponse **pp_outResponse);

 

int at_send_command_multiline (const char *command, const char *responsePrefix, ATResponse **pp_outResponse)

 

int at_send_command_sms (const char *command, const char *pdu, const char *responsePrefix, ATResponse **pp_outResponse);

 

上述四个函数，均是发送各种类型的AT至Modem侧的函数，它们都是都调用下面的at_send_command_full函数：

 

int at_send_command_full (const char *command, ATCommandType type,

const char *responsePrefix, const char *smspdu,

long long timeoutMsec, ATResponse **pp_outResponse)

该函数首先检查调用者是不是在reader线程中，若是则返回一个错误号。（最终调用它的应该是在dispatch线程中）然后上锁同步，避免出现写AT出现竞争的情况，在上锁期间，调用at_send_command_full_nolock完成发送一个完整的AT命令。若出现发送超时，且超时回调函数被指定，则调用超时回调函数进行处理。

 

 

int at_send_command_full_nolock (const char *command, ATCommandType type,

const char *responsePrefix, const char *smspdu,

long long timeoutMsec, ATResponse **pp_outResponse)

该函数完成一个AT命令的发送。它首先检查当前是否有一个还未完成发送的AT命令正在发送：判断全局的sp_response是否为空，当为空时，说明没有正在发送的AT命令。这是因为：当有正在发送的AT命令时，首先在内存里创建一个ATResponse的对象，然后将指针赋给sp_response。当成功发送后再将sp_response指定为NULL。

当它向Modem发送完AT命令后，将等待在互斥锁s_commandmutex上，等待Modem侧的response（由reader线程去读取response）被完整读取，否则reader线程不断去读取，若没有数据，将会等待阻塞调用线程，即dispatch线程。读取完被唤醒后（见handleFinalResponse函数和processLine注释），设置相关的response全局变量后，即可将sp_response指定为NULL后返回。

 

 

 

void reverseIntermediates(ATResponse *p_response)

反转字符串顺序列表

 

函数writeCtrlZ (const char *s)

辅助函数，非接口函数。将字符串发送到Modem中（写入到s_fd设备，即在at_open中打开的与AT交互设备）后，然后再写入个控制字符“^Z”。在代码中有如下注释：See eg. TS 27.005 4.3 Commands like AT+CMGS have a “> ” prompt

 

 

AT_CME_Error at_get_cme_error(const ATResponse *p_response)

返回错误码，见代码注释：Returns error code from response. Assumes AT+CMEE=1 (numeric) mode

typedef enum {
CME_ERROR_NON_CME = -1,
CME_SUCCESS = 0,
CME_SIM_NOT_INSERTED = 10
} AT_CME_Error;

 

参考：

pthread_mutex_lock

pthread_mutex_unlock

pthread_cond_signal

pthread_cond_timeout_np

pthread_cond_timedwait

pthread_cond_wait

 

 

 

 

at_tok.c at_tok.h

int at_tok_start(char **p_cur)

寻找token的位置，将其更新到*p_cur，成功返回0，失败返回-1。具体为：p_cur指向的字符串地址值被更新，新的值是是字符串中冒号（“：”）后面的一个字符串的首字符的地址。

 

 

int at_tok_start(char **p_cur);

 

int at_tok_nextint(char **p_cur, int *p_out);

int at_tok_nexthexint(char **p_cur, int *p_out);

int at_tok_nextbool(char **p_cur, char *p_out);

int at_tok_nextstr(char **p_cur, char **out);

 

上面的函数军事遍历AT Response字符串，并把得到的结果置于p_out中。同时更新*P_cur，让其为下面对字符地址。成功，返回0，失败返回-1

 

int at_tok_hasmore(char **p_cur);

检查是否还有新的token。

 

这些主要是被at_get_cme_error函数使用获取错误号。

 

misc.h misc.c

这两个文件中只有一个函数int strStartsWith(const char *line, const char *prefix)，用于返回字符串line中是否有前缀字符串prefix开头，是则返回1，否则返回0。