本文以通话设置中的呼叫等待的设置为例，讲解RIL的流程。其实其余的也类似如此
路径: package/apps/Phone/src/com/android/phone
呼叫等待的onClick事件在CallFeaturesSettings.java里面
当点击呼叫等待的CheckboxPreference时，调用以下函数：
CallFeaturesSettings::onPreferenceTreeClick（）
其中：
else if (preference == mButtonCW) {
handleCWClickRequest(mButtonCW.isChecked());
nextState = AppState.BUSY_NETWORK_CONNECT;
}
这里的mButtonCW便是呼叫等待的这个CheckboxPreference
继续追下去，调用
CallFeaturesSettings::handleCWClickRequest()
这里便有：
mPhone.setCallWaiting(b, Message.obtain(mSetOptionComplete, EVENT_CW_EXECUTED));
===================================================================================
以下转到: framework/base/telephony/java/com/android/internal/telephony/gsm
其中mPhone是Phone的对象，追到Phone里面，发现Phone是个接口.
得找出是哪个类去实现这个接口的，是GSMPhone.
里面就有setCallWaiting（）这个函数。
public void setCallWaiting(boolean enable, Message onComplete) {
mCM.setCallWaiting(enable, CommandsInterface.SERVICE_CLASS_VOICE, onComplete);
}
发现这个函数又是调用别人的函数，其中mCM是CommandsInterface对象，而CommandsInterface又是个接口。
像刚才一样，得找出是谁实现了CommandsInterface。找到RIL.java。
寻找setCallWaiting（）：
public void
setCallWaiting(boolean enable, int serviceClass, Message response)
{
RILRequest rr
= RILRequest.obtain(RIL_REQUEST_SET_CALL_WAITING, response);
//以下对rr中的mp写入数据。mp是Parcel的对象
rr.mp.writeInt(2);
rr.mp.writeInt(enable ? 1 : 0);
rr.mp.writeInt(serviceClass);
if (RILJ_LOGD) riljLog(rr.serialString() + "> " + requestToString(rr.mRequest)
+ " " + enable + ", " + serviceClass);
send(rr);
}
这里的RILRequest是获取呼叫等待的RIL请求消息。这里得留意RIL_REQUEST_SET_CALL_WAITING， 这个可以认为是该请求的ID。
在RILConstants.java以及ril.cpp中有对此ID号的解析，映射成了一个string，以在后面对其进行处理。
send()便是把这个请求发送出去。
private void
send(RILRequest rr)
{
Message msg;
msg = mSender.obtainMessage(EVENT_SEND, rr);
acquireWakeLock();
msg.sendToTarget();
}
看下send()，会发现，在send的时候，mSender获取了这个消息。之后该请求进入了消息队列。一开始追到这里就懵了，感觉没有对消息进行处理，就卡住了。
这里得说下Handler对消息队列的处理机制。
是这样的，Handler所获取的消息，都会进入消息队列。而等消息出来的时候，将会在Handler的handlerMessage()中对其进行处理。
因此，在msg.sendToTarget()之后，就是mSender对象的handleMessage()对此消息进行处理。
追查到mSender的handlerMessage（）， 把代码好好看一遍。
其实这里就是对rr里面所打包的数据进行解包，以字节流的方式，写入socket.
===========================================================================================================
回到RIL.java，会发现在RIL的构造函数里面，有如下部分：
mSenderThread = new HandlerThread("RILSender");
mSenderThread.start();
Looper looper = mSenderThread.getLooper();
mSender = new RILSender(looper);
mReceiver = new RILReceiver();
mReceiverThread = new Thread(mReceiver, "RILReceiver");
mReceiverThread.start();
这里注意mSender是RILSender的实例
而mReceiver是RILReceiver的实例
在mReceiver，注意到在它开启了一个线程，这个线程里面有如下代码：
s = new LocalSocket();
l = new LocalSocketAddress(SOCKET_NAME_RIL,LocalSocketAddress.Namespace.RESERVED);
s.connect(l);
因此，在进入RIL.java的时候便连上了socket。
其次有个mSocket=s。其实就是将RILSender与RILReceiver共用一个socket。
查找这个socket的name， 是SOCKET_NAME_RIL， 其中有：
static final String SOCKET_NAME_RIL = "rild";
在sourceInSight中查找这个socket_name，即rild
其次，
路径：hardware/ril/
搜到ril.cpp这个文件，毫无疑问，这个就是上层的RIL.java开启的socket所连接上的文件，开始要跟硬件打交道了。
至于连接上socket后具体做了什么事情，参阅文档：GSM驱动模块详细分析(一)～（三）
以下只是初略的写下大概的流程。
ril.cpp中建立了消息循环，而对消息的处理以及解析，都在reference_ril.c中
要想知道处理的函数在哪，就得找到上面所说的请求ID号所映射的字符串， 搜索字符串便能找到相应的请求函数。
请求均在onRequest()里面，再通过response进行解析。
同时reference_ril.c将解析好的消息传回给socket，将字节流返回到上层。
============================================================================================
而返回到上层的时候，便是RILReceiver的工作，它会将返回上来的字节流进行处理。
处理函数为RIL::processResponse（）
其中：
AT的response有两种，一是主动上报的，比如网络状态，短信，来电等都不需要经过请求，有一unsolicited词语专门描述。
另一种才是真正意义上的response，也就是命令的响应，用solicited描述。
最后将处理后的消息，返回给最初的mSetOptionComplete
流程：
CallFeaturesSetting::onPreferenceTreeClick()
->CallFeaturesSetting::handleCWClickRequest()
->Phone::setCallWaiting()
->GSMPhone::setCallWaiting()
->CommandInterface::setCallWaiting()
->RIL::setCallWaiting()
->RIL::send()
与此同时，RILSender mSender把RILRequest rr里面所打包好的数据解包，以字节流写入socket。
此时底层的GSM驱动对此字节流进行请求和解析，将结果返回给上层。这结果恰好就是以引用方式所传下来的Message。
->Message::sendToTarget()
->CallFeaturesSetting::mSetOptionComplete::handleMessage()