Android Ril库总结

          

1总体框架

    Rild是Init进程启动的一个本地服务，这个本地服务并没有使用Binder之类的通讯手段，而是采用了socket通讯这种方式。

Andoid将RIL层分为两个代码空间：RILD管理框架(rild、libril.so)，AT相关的xxxril.so动态链接库(libreference-ril.so)。rild把libril.so和libreference-ril.so联系起来,libril.so对上是java的socket通信，对下是把java层的命名分发到libreference-ril.so，而libreference-ril.so则把命名转换层AT的命令，通过串口发送给Modem。将ＲＩＬ独立成一个动态链接库的好处就是Ａｎｄｒｏｉｄ系统适应不同的Ｍｏｄｅｍ，不同的Mode可以有一个独立的Ril与之对应。

     而ril是具体的AT指令合成者和应答解析者。从最基本的功能来讲，ril建立了一个侦听Socket，等待客户端的连接，然后从该连接上读取RIL-Java成传递来的命令并转化成AT指令发送到Modem。并等待Modem的回应，然后将结果通过套接口传回到Ril-Java层。下图是Ril-D的基本框架：

下面的数据流传递描述图表描述了RIL-JAVA层发出一个电话指令的5 步曲：

①　JAVA层通过socket发送命令到RILD

②　RILD在EventLoop线程监听到socket消息，读取后封装成AT指令，通过串口发送给

     Modem。并等待Modem的回应命令

③　ReaderLoop线程不断读取串口端口数据，得到回应。回应信息分为两种，一种是对

于第二步AT指令的回应，另一种是主动上报信息，即URC消息，例如短信送达的

消息。

④　判断是回应AT命令的回应信息，将消息传送到ril再次处理

⑤　通过socket，将AT回应消息发送到JAVA

⑥　URC消息通过socket，通知到JAVA。

Ril-d的整体数据流及其控制流示意图：

2初始化流程分析

2.1 初始化流程图

   

2.2 代码分析

Ø        init.XXX.rc                    

Ø        hardware/ril/rild/rild.c            

Ø        hardware/ril/libril/ril.cpp          

Ø        hardware/ril/libril/ril_event.cpp

Ø        hardware/ril/reference-ril/reference-ril.c

Ø        hardware/ril/reference-ril/atchannel.c   

2.2.1 入口 

---1. init.XXX.rc  ---

service ril-daemon /system/bin/rild -l libreference-ril.so -- -d /dev/ttyUSB2
    class main
    socket rild stream 660 root radio
    socket rild-debug stream 660 radio system
    user root
    group radio cache inet misc audio sdcard_rw log

在Android配置脚本init.XXX.rc里面，如上所示，定义用于启动RILD的服务ril-daemon，我们可以看到， /system/bin/rild就是该服务的执行文件，即hardware/ril/rild/rild.c文件编译出来的可执行文件。参数如下：

Ø        -l：指定AT相关的动态链接库为libreference-ril.so

Ø        -d：指定modem的端口为/dev/tty/USB2

在ril-daemon服务中，还创建了两个socket端口，分别是rild、rild-debug，我们可以在

小机/dev/socket/目录下看到其节点。rild端口用于Ril库与java代码的socket通信，而rild-debug用于radiooptions(hardware/ril/rild/radiooptions.c)模拟java发送socket命令，起到调试的作用。

2. hardware/ril/rild/rild.c---main

int main(int argc, char **argv)
{
    const char * rilLibPath = NULL;
    void *dlHandle;
    const RIL_RadioFunctions *(*rilInit)(const struct RIL_Env *, int, char **);
    const RIL_RadioFunctions *funcs;
    unsigned char hasLibArgs = 0;
    dlHandle = dlopen(rilLibPath, RTLD_NOW);//获取动态链接库libreferencer-ril.so
    //入口地址
    ......
    RIL_startEventLoop();//初始化EventLoop
    .......
    rilInit = (const RIL_RadioFunctions *(*)(const struct RIL_Env *, int, char **))dlsym(dlHandle, "RIL_Init");//获取libreferencer-ril.so中RIL_Init方法的指针
    .......
    funcs = rilInit(&s_rilEnv, argc, rilArgv);//向libreference-ril.so注册
    RIL_register(funcs);//向libril注册libreference的回调函数，并监听socket端口
    ......
}

通过解析参数获取动态链接库的名字保存在rilLibPath中，调用dlopen()获取动态链接库的入口地址，然后再通过调用dlsym()获取libreference-ril中的RIL_Init()方法的指针。

调用RIL_startEventLoop()初始化EventLoop()，创建线程监听端口(管道、socket)事件。

调用libreference-ril的RIL_Init()方法，所带的参数是s_rilEnv结构体指针及-d指定的Modem端口/dev/ttyUSB2，并返回回调函数给Rild。

Ril_register()将回调函数注册到libril中。

Main()函数解析参数后，依次去做一些初始化工作，详细解析如下分析。

2.2.2  eventLoop

    Event Loop的基本工作就是等待在事件端口（管道，Socket），一旦有数据到达就根据登记的Event回调函数进行处理。

1.ril_event对象 hardware/ril/libril/ril_event.h

struct ril_event {
    struct ril_event *next;
    struct ril_event *prev;
int fd; //事件相关设备句柄,例如socket端口、管道
int index;
    bool persist;//如果是保持的，则不从watch_list中删除。
    struct timeval timeout;
    ril_event_cb func; //回调事件处理函数
    void *param; //回调时参数
};

为了统一管理事件，Android使用了三个队列：watch_table,timer_list,pending_list,并使用了一个设备句柄池readFDS,是Linux的fd_set，readFDS保存了Rild中所有的设备文件句柄，以便利用select函数统一的完成事件的侦听。

Ø        watch_table：监测时间队列。需要检测的事件都放入到该队列中。

Ø        timer_list：timer队列

Ø        pending_list:待处理事件队列，事件已经触发，需要所回调处理的事件。

    事件队列队列的操作：ril_event_add,ril_event_del, ril_timer_add

2. hardware/ril/libril/ril.cpp---RIL_startEventLoop

RIL_startEventLoop(void) {
    ......
    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);
    ......
}

这个方法很简单，创建新线程，执行eventLoop()方法。

3. hardware/ril/libril/ril.cpp---eventLoop

static void *
eventLoop(void *param) {
    int ret;
    int filedes[2];
    ril_event_init(); //初始化三个队列
    pthread_mutex_lock(&s_startupMutex);
    s_started = 1;
    pthread_cond_broadcast(&s_startupCond);
    pthread_mutex_unlock(&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);//设置ril_event
    rilEventAddWakeup (&s_wakeupfd_event);//添加到watch_table，并主动唤醒队列
    ril_event_loop();//开始循环扫面readFDS端口
}

   (1)ril_event_init

      初始化三个队列timer_list、pending_list、watch_table及readFDS

   (2)pipe

      创建无名管道，用于队列主动唤醒，一个为读端另一个是写端。

   (3)O_NONBLOCK

      设置了读端s_fdWakeupRead非阻塞模式，即如果没有数据的时候，立即返回。

   (4)ril_event_set

      将s_fdWakeupRead作为句柄，初始化s_wakeupfd_event结构体，即ril_event。

   (5)rilEventAddWakeup   

static void rilEventAddWakeup(struct ril_event *ev) {
    ril_event_add(ev);
    triggerEvLoop();//主动唤醒队列
}

    ril_event_add()将s_wakeupfd_event添加到watch_table队列中，并把s_fdWakeupRead

       句柄添加到readFDS句柄池中，然后理解调用triggerEvLoop()，往s_fdWakeupWrite

       写一个空格字符，主动唤醒队列。

   (6)ril_event_loop

       开始扫面线程池readFDS。

   到此，我们监听的端口只有s_fdWakeupRead。

4.hardware/ril/libril/ril_event.cpp---ril_event_loop()

void ril_event_loop(){
    int n;
    fd_set rfds;
    struct timeval tv;
    struct timeval * ptv;
    for (;;) {
        // make local copy of read fd_set
        memcpy(&rfds, &readFds, sizeof(fd_set));
        if (-1 == calcNextTimeout(&tv)) {
            // no pending timers; block indefinitely
            dlog("~~~~ no timers; blocking indefinitely ~~~~");
            ptv = NULL;
        } else {
            dlog("~~~~ blocking for %ds + %dus ~~~~", (int)tv.tv_sec, (int)tv.tv_usec);
            ptv = &tv;
        }
        printReadies(&rfds);
        n = select(nfds, &rfds, NULL, NULL, ptv);
        printReadies(&rfds);
        ......
        processTimeouts();
        processReadReadies(&rfds, n);
        firePending();
    }
}

    我们知道对于Linux设备来讲，我们可以使用select函数等待在FDS上,只要FDS中记录的设备有数据到来，select就会设置相应的标志位并返回。readFDS记录了所有的事件相关设备句柄。readFDS中句柄是在在AddEvent加入的。所有的事件侦听都是建立在linux的select readFDS基础上。

ril_event_loop 利用select等待在readFDS（fd_set）上，当select设备有数据时，ril_event_loop会从select返回，processTimeouts()检查timer_list是否有Timeout事件(request回调)，有则添加到pengding_list列表中。processReadReadies()检查watch_list中是否有Event可读，有则相应的Event放置到pend_list，如果Event是持久性的则不从watch_list中删除。然后firePending遍历pengding_list处理Event事件，发起事件回调函数。

2.2.3  readerLoop

RIL_Init开始，开启对modem端口硬件的事件监听，在创建线程中readerLoop循环读取modem端口（/dev/ttyUSBX）AT应答执行。

1.hardware/ril/reference-ril/reference-ril.c---RIL_Init

const RIL_RadioFunctions *RIL_Init(const struct RIL_Env *env, int argc, char **argv)
{
......
s_rilenv = env;
    while ( -1 != (opt = getopt(argc, argv, "p:d:s:"))) {
        switch (opt) {
            case 'd':
                s_device_path = optarg; //解析参数，保存modem端口
                ALOGI("Opening tty device %s\n", s_device_path);
            break;
        }
    }
    pthread_attr_init (&attr);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
    ret = pthread_create(&s_tid_mainloop, &attr, mainLoop, NULL);//创建线程
    return &s_callbacks;
}

  (1) 将env赋值给 s_rilenv，env是在rild.c定义的，通过RIL_Init传进来的，定义如下：

static struct RIL_Env s_rilEnv = {
    RIL_onRequestComplete,   //request完成的时候调用
    RIL_onUnsolicitedResponse, //URC消息回调
    RIL_requestTimedCallback  //request超时回调，后面会添加timer_list事件
};

 这三个方法，是在ril.cpp中定义的。

（2）-d参数指定了modem端口，用变量s_device_path保存，然后调用pthread_create创建

      新线程，在新线程中调用mainLoop()方法。

（3）直接将s_callbacks返回给Rild。

   hardware/ril/reference-ril/reference-ril.c

static const RIL_RadioFunctions s_callbacks = {
    RIL_VERSION,
    onRequest, //java层发送AT命令时回调，处理requst请求
    currentState,
    onSupports,
    onCancel,
    getVersion
};

2.hardware/ril/reference-ril/reference-ril.c---mainLoop

static void *
mainLoop(void *param)
{
    int fd;
    int ret;
    AT_DUMP("== ", "entering mainLoop()", -1 );
    at_set_on_reader_closed(onATReaderClosed);
    at_set_on_timeout(onATTimeout);
    for (;;) {
        fd = -1;
        while  (fd < 0) {
            if (s_port > 0) {
                fd = socket_loopback_client(s_port, SOCK_STREAM);
            } else if (s_device_socket) {
             ......  
            } else if (s_device_path != NULL) {
                fd = open (s_device_path, O_RDWR);//打开modem端口
                if ( fd >= 0 && !memcmp( s_device_path, "/dev/ttyS", 9 ) ) {
             ......
            }
        }
        s_closed = 0;
        ret = at_open(fd, onUnsolicited);//建立起modem端口上的reader等待循环
        RIL_requestTimedCallback(initializeCallback, NULL, &TIMEVAL_0);
    }
}

  (1) 打开modem端口

  (2)通过at_open建立起modem设备文件上的reader等待循环

  (3)Ril的相应机制，回调initializeCallback方法，执行了一些模块的初始化命令。

3.hardware/ril/reference-ril/atchannel.c---at_open

int at_open(int fd, ATUnsolHandler h)
{
    .......
    pthread_attr_init (&attr);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
    ret = pthread_create(&s_tid_reader, &attr, readerLoop, &attr);
    ......
    return 0;
}

该方法也通过新建一个线程完成，即pthread_create创建，线程的入口是readerLoop方法。实现如下。

4. hardware/ril/reference-ril/atchannel.c---readerLoop

static void *readerLoop(void *arg)
{
    for (;;) {
        const char * line;
        line = readline(); //读取modem端口数据
        if(isSMSUnsolicited(line)) {//判断相应类型
            char *line1;
            const char *line2;
            line1 = strdup(line);
            line2 = readline();
            if (s_unsolHandler != NULL) {
                s_unsolHandler (line1, line2);//URC消息处理
            }
            free(line1);
        } else {
            processLine(line);//回应java层的AT请求
        }
    onReaderClosed();
    return NULL;
}

      在AT通讯的过程中有两类响应：一种是请求后给出应答，一种是通知类，即为不请自来的，例如短信通知达到，我们称该类通知为URC。在Rild中URC和一般的Response是分开处理的，概念上URC由handleUnsolicited处理，而Response由handleFinalResponse来处理。

 (1) readline不断读取串口数据

（2）isSMSUnsolicited判断相应类型

（3）U_unsolHandler处理URC消息

（4）processLine处理java层的的response信息

 对于readerLoop，到这里就告一段落，后续我们会分析request和response的。

2.2.4  监听socket端口

      有上面介绍中，RIL_Init函数获取一组函数指针RIL_RadioFunctions，通过RIL_register将回调函数注册到libril.so中，并打开接受来自java层命令的socket端口。

extern "C" void
RIL_register (const RIL_RadioFunctions *callbacks) {
    int ret;
    int flags;
......
memcpy(&s_callbacks, callbacks, sizeof (RIL_RadioFunctions));
//打开与java层通信的socket端口/dev/socket/rild
    s_fdListen = android_get_control_socket(SOCKET_NAME_RIL);
    if (s_fdListen < 0) {
        ALOGE("Failed to get socket '" SOCKET_NAME_RIL "'");
        exit(-1);
    }
    ret = listen(s_fdListen, 4);
    /* note: non-persistent so we can accept only one connection at a time */
    ril_event_set (&s_listen_event, s_fdListen, false,
                listenCallback, NULL);
    rilEventAddWakeup (&s_listen_event);
.......
//注册debug端口
 ril_event_set (&s_debug_event, s_fdDebug, true,
                debugCallback, NULL);
    rilEventAddWakeup (&s_debug_event);
}

函数指针callbacks中的函数，是在reference-ril.c中定义的，这样，socket端口数AT请求的时候，就可以将at命令传送到reference-ril.c中处理了。将callbacks赋值给s_callbacks。

调用接口android_get_control_socket()获取/dev/socket/rild的文件描述符，并设置为s_listen_event事件，再调用rilEventAddWakeup添加到watch_table列表中，并主动唤醒队列。

到这里就完成了RILD守护进程的初始化操作，最后main函数主线程就将进入死循环中。回顾下初始化过程中，挂载到watch_table队列中的event事件有如下3个：

Ø        s_listen_event ,名为rild的socket，它主要是request和response的通道

Ø        s_debug_event,名为rild-debug的socket，主要作用是调试用的request与response通道。与s_listen_event类似。

Ø        s_wakeupfd_evnet,无名管道，用于队列的主动唤醒。

3 request流程分析

    Request即请求流程，java层通过socket将命令发送到RIL层的RILD守护进程，这时RILD负责监听的ril_event_loop消息循环的select发现了java层的socket请求连接信号，s_listen_event就会被挂到pending_list队列中，并执行了event->func回调函数，即listenCallback。下面开始分析。

3.1 request调用关系图

3.2 代码分析

1. hardware/ril/libril/ril.c---listenCallback

static void listenCallback (int fd, short flags, void *param) {
......
//接受连接请求
    s_fdCommand = accept(s_fdListen, (sockaddr *) &peeraddr, &socklen);
    ......
    ret = fcntl(s_fdCommand, F_SETFL, O_NONBLOCK);
    ......
    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();
}

  (1) java层要与RILD通信，首先调用socket.connect()发起连接请求。而这里，通过accept   

    函数接受连接请求，返回传入的socket描述符给s_fdCommand

 (2) 通过record_stream_new建立起一个record_stream，连接于上层的数据通道，并开始接

     受数据请求，将record_stream与s_fdCommand绑定。

 (3)将s_fdCommand设置到s_commands_event事件中，并添加到watch_table队列中。

 这样，一旦s_fdCommand有数据，那么就回调processCommandsCallback方法。

2.hardware/ril/libril/ril.c---processCommandsCallback

static void processCommandsCallback(int fd, short flags, void *param) {
    RecordStream *p_rs;
    void *p_record;
    size_t recordlen;
    int ret;
    assert(fd == s_fdCommand);
    p_rs = (RecordStream *)param;
    for (;;) {
        ret = record_stream_get_next(p_rs, &p_record, &recordlen);
        if (ret == 0 && p_record == NULL) {
            break;
        } else if (ret < 0) {
            break;
        } else if (ret == 0) { /* && p_record != NULL */
            processCommandBuffer(p_record, recordlen);
        }
    }
    //省略.....
    }
}

通过record_stream_get_next()阻塞读取s_fdCommand上发来的数据，直到一个完整的request请求，在通过processCommandBuffer处理。

3. hardware/ril/libril/ril.c---processCommandBuffer

static int
processCommandBuffer(void *buffer, size_t buflen) {
//省略......
p.setData((uint8_t *) buffer, buflen);
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);
    pRI->p_next = s_pendingRequests;
    s_pendingRequests = pRI;
    ret = pthread_mutex_unlock(&s_pendingRequestsMutex);
    pRI->pCI->dispatchFunction(p, pRI);
    return 0;
}

这个方法很关键，它完成了消息的派发。Java层传递的命令格式为：Parcel+Request号+令牌+内容组成，通过socket传送到RIL层，由于parcel是一套简单是序列化协议，因此需要通过反序列化的方法将其提取出来，以RequestInfo结构体形式存在，定义如下：

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;

在这里，我们看到了request号，它是在java命令中指定的，由它我们就可以找到ril_commands.h中定义的方法了。RIL层命令的分发也是基于request号的。我们看看静态变量s_commands的定义：

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

 CommandInfo 表示一个结构体，关联了request号和实际的请求函数，以及响应函数之间的关系，该结构体的定义如下：

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

    我们再看看ril_commands.h文件的定义，其对数组变量s_commands进行了初始化：

   {0, NULL, NULL},                   //none
    {RIL_REQUEST_GET_SIM_STATUS, dispatchVoid, responseSimStatus},
    {RIL_REQUEST_ENTER_SIM_PIN, dispatchStrings, responseInts},
{RIL_REQUEST_ENTER_SIM_PUK, dispatchStrings, responseInts},
//省略......

    第一个参数，就是request号，第二个参数是对应的dispatchXXX，第三个参数，对应的是该请求的回应函数responseXXX，dispatch方法和response方法都是在ril.cpp中定义的。

回到processCommandBuffer中，根据request号，指定s_commands数组中的CommandInfo实例，并赋值给pRI->pCI。接着就调用pRI->pCI->dispatchFunction()，调用到了具体的dispatchXXX方法。

在所有的dispatchXXX方法中，最终都会调用到s_callbacks.onRequest()。s_callbacks应该不会陌生吧，是获取reference-ril.c中的RIL_RadioFunctions结构体指针。

到这里，消息就传到了reference-ril.c中的onRequest中了。

4.hardware/ril/reference-ril/reference-ril.c----onRequest

static void
onRequest (int request, void *data, size_t datalen, RIL_Token t)
{
   //省略......
    switch (request) {
         //省略......
        case RIL_REQUEST_HANGUP_WAITING_OR_BACKGROUND:
//阻塞，等待超时或接收到Modem的相应
at_send_command("AT+CHLD=0", NULL);
            /* success or failure is ignored by the upper layer here.
               it will call GET_CURRENT_CALLS and determine success that way */
            RIL_onRequestComplete(t, RIL_E_SUCCESS, NULL, 0);
            break;
        //省略......
        default:
            RIL_onRequestComplete(t, RIL_E_REQUEST_NOT_SUPPORTED, NULL, 0);
            break;
    }
}

     onRequest也很简单，会根据不同的request号做不同的处理，并命令和参数转换成对应的AT命令。然后调用at_send_command()方法进行传送，最终会调用到at_send_command_full_nolock，并最终的写操作是通过writeline()方法中完成的，实际上是通过linux系统调用write接口向modem设备节点文件描述符完成写操作。

在at_send_command_full_nolock中，在writeline之后，发送命令的线程进入响应等待的状态，直到超时或者接收到响应才返回。返回之后，则调用RIL_onRequestComplete，即respose请求，这里就线不讲了，后续在respone流程中再分析。

5.hardware/ril/reference-ril/atchannel.c---at_send_command_full_nolock

static int at_send_command_full_nolock (const char *command, ATCommandType type,
                    const char *responsePrefix, const char *smspdu,
                    long long timeoutMsec, ATResponse **pp_outResponse)
{
//省略…..
//向设备发送命令
    err = writeline (command);
    s_type = type;
    s_responsePrefix = responsePrefix;
    s_smsPDU = smspdu;
    sp_response = at_response_new();
#ifndef USE_NP
    if (timeoutMsec != 0) {
        setTimespecRelative(&ts, timeoutMsec);
    }
#endif /*USE_NP*/
    //处理等待情况
    while (sp_response->finalResponse == NULL && s_readerClosed == 0) {
        if (timeoutMsec != 0) {
#ifdef USE_NP
            err = pthread_cond_timeout_np(&s_commandcond, &s_commandmutex, timeoutMsec);
#else
            err = pthread_cond_timedwait(&s_commandcond, &s_commandmutex, &ts);
#endif /*USE_NP*/
        } else {
            err = pthread_cond_wait(&s_commandcond, &s_commandmutex);
        }
  //省略…….
}

在writeline之后则进入线程等待处理中，关键在于信号量s_commandcond，当readerLoop读取到回应信息的时候，会做一个判断该信息的类型，如果有request在等待回应，再调用pthread_cond_signal(&s_commandcond)发送信号给request等待线程，即pthread_cond_wait返回，结束等待。

Ok，到这里，request流程就分析结束了，下面就开始分析response请求了。

4response流程分析

    Response即modem通过串口回应信息到java层，在AT通讯的过程中有两类Response：一种是请求后给出应答，另一种是通知类，即为不请自来的，例如短信通知达到，我们称该类通知为URC。在Rild中URC和一般的Response是分开处理的，概念上URC由handleUnsolicited处理，而Response由handleFinalResponse来处理。

4.1response调用关系图

4.2代码分析

在前面，我们讲解初始化流程的时候，有介绍到readerLoop，循环读取modem端口的数据，readerLopp的处理流程如下：

1.hardware/ril/reference-ril/atchannel.c---readerLoop

static void *readerLoop(void *arg)
{
    for (;;) {
        const char * line;
        line = readline(); //读取modem端口数据
        if(isSMSUnsolicited(line)) {//判断相应类型
            char *line1;
            const char *line2;
            line1 = strdup(line);
            line2 = readline();
            if (s_unsolHandler != NULL) {
                s_unsolHandler (line1, line2);//URC消息处理
            }
            free(line1);
        } else {
            processLine(line);//回应java层的AT请求
        }
    onReaderClosed();
    return NULL;
}

首先通过readline读取端口数据接收响应，然后isSMSUnsolicited()判断响应信息的类型，如果是URC信息，那么调用s_unsolHandler处理，如果是响应java层的request请求，那么调用processLine处理。这里我们先分析URC消息，processLine会稍后分析。

4.2.1 URC消息

s_unsolHandler是一个函数指针，是在初始化的时候，reference-ril.c通过调用at_open传给atchannel.c的，其实现的代码如下：

1. hardware/ril/reference-ril/ reference-ril.c---onUnsolicited

static void onUnsolicited (const char *s, const char *sms_pdu)
{
    char *line = NULL;
    int err;
      //省略….
    if (strStartsWith(s, "%CTZV:")) {
        //省略….
    } else if (strStartsWith(s,"+CREG:")|| strStartsWith(s,"+CGREG:"){
      //省略….
    } else if (strStartsWith(s,"+CREG:") || strStartsWith(s,"+CGREG:")) {
        RIL_onUnsolicitedResponse (
            RIL_UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED,
            NULL, 0);
#ifdef WORKAROUND_FAKE_CGEV
        RIL_requestTimedCallback (onDataCallListChanged, NULL, NULL);
#endif /* WORKAROUND_FAKE_CGEV */
}
 //省略….
}

跟request类似，response也有一个response号，onUnsolicited做一个简单的处理，通常通过misc.c的strStartsWith方法，只解析头部，然后根据类型的不一样得到不一样的response号，进行下一步处理，都调用RIL_onUnsolicitedResponse进行处理，其第一个参数就是response号。

2. hardware/ril/libril/ril.c ---RIL_onUnsolicitedResponse

extern "C"
void RIL_onUnsolicitedResponse(int unsolResponse, void *data,
                                size_t datalen)
{
    //省略......
    unsolResponseIndex = unsolResponse - RIL_UNSOL_RESPONSE_BASE;
    //省略......
    Parcel p;
    p.writeInt32 (RESPONSE_UNSOLICITED);
    p.writeInt32 (unsolResponse);
    //省略......
    ret = s_unsolResponses[unsolResponseIndex]
                .responseFunction(p, data, datalen);
    ret = sendResponse(p);
    //省略......
}
 

   s_unsolResponses变量是结构体UnsolResponseInfo的数组，根据传入的response号，减去基数RIL_UNSOL_RESPONSE_BASE，得到s_unsolResponses数组的索引，然后调用其responseFunction方法。这个和request的派发类似，这里就不详细的介绍了。

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

    经过responseFunction的处理，将response信息封装到parcel中，然后调用sendResponse()继续回应，然后直接调用sendResponseRaw(),代码如下。

3 hardware/ril/libril/ril.c ---sendResponseRaw

static int sendResponseRaw (const void *data, size_t dataSize) {
    int fd = s_fdCommand;
    //省略...
    ret = blockingWrite(fd, data, dataSize);
    //省略...
}

     对于s_fdCommand应该是不陌生了，在request流程分析中的listenCallback中讲到的，是RIL与JAVA层Socket的数据通道对应的设备节点。在blockingWrite方法中，通过write系统调用，将Parcel数据、大小作为参数，往s_fdCommand写数据，完成向JAVA层回应消息。

    到此，对于URC消息的分析就到此结束。

4.2.2 AT 回应消息

回到readerLoop()方法中，分析回应AT命令的消息处理processLine，在processLine会做一些判断处理，但最终都调用到handleFinalResponse中，这是关键。

1. hardware/ril/libril/ril.c---handleFinalResponse

static void handleFinalResponse(const char *line)
{
    sp_response->finalResponse = strdup(line);
    pthread_cond_signal(&s_commandcond);//发送结束等待信号量
}

  前面在request的时候讲解到，把AT命令写到Modem后，写线程进入了阻塞的等待状态，即等待Modem的回应信息，而这里就发送了s_commandcond的结束等待的信号量。则at_send_command_full_nolock方法立即结束等待返回到onRequest中，然后调用RIL_onRequestComplete方法。

2. hardware/ril/libril/ril.c  ---RIL_onRequestComplete

extern "C" void
RIL_onRequestComplete(RIL_Token t, RIL_Errno e, void *response, size_t responselen) {
    //省略....
    pRI = (RequestInfo *)t;
    if (pRI->cancelled == 0) {
        Parcel p;
        p.writeInt32 (RESPONSE_SOLICITED);
        p.writeInt32 (pRI->token);
        errorOffset = p.dataPosition();
           //省略....
        p.writeInt32 (e);
          //省略....
        if (response != NULL) {
            // there is a response payload, no matter success or not.
            ret = pRI->pCI->responseFunction(p, response, responselen);
        }
        sendResponse(p);
    }
}
 

   对于第一个参数t，其实是在request的时候创建的RequestInfo结构体，有其对应的responseFunction接口，调用后将回应信息封装在Parcel中，后续调用sendResponse将数据发送到JAVA层，前面介绍过，这里就不重复了。