2023年3月2日发(作者：科三考试内容)本文假设读者已经了解RIL的基本知识
从上层出发，在frameworks/ba/telephony/java/com/android/internal/telephony/中添加所要发AT命令的上层函数。
Phone是个接口，因此，添加完后，得在实现Phone接口的java类里面实现这个方法，实现Phone的类即位于frameworks/ba/telephony/java/com/android/internal/telephony/gsm/
在这里，调用CommandInterface里面的方法， 因此， 我们还得在CommandInterface里面把我们要增加的方法添加进去
同样的，CommandInterface也是个接口，而实现这个接口的类有2个：
1. frameworks/ba/telephony/java/com/android/internal/telephony/gsm/
2. frameworks/ba/telephony/java/com/android/internal/telephony/test/
其中第2个是在模拟器里面测试用的， 我们只需要在里面把方法添加进去，然后调用个resultSuccess或者umimplement都可以。
而第1个才是真正到达GSM驱动的类。
所以，我们得在中，实现上层与下层的通信。
在的方法里面，只需要定义好你所需要发送AT命令的一个标识MARK（下面还会提到）， 再把RilRequest类里面的Parcel成员mp赋值， 然后发送出去即可。
赋给mp的值，即为我们需要发送到下层去处理的值， 例如传个数组下去， 一般都先把长度写进去， 其次再把成员依次写入。
===============================================================================================
接下来，便是下层的添加过程。
1。 hardware/ril/include/telephony/ril.h
在此文件中，添加一个标识你所要处理的AT命令的宏， 即上面所说到的MARK， 注意不要和别的宏发生冲突。
注意： 这里的MARK必须定义在最后面， 不然会带来不必要的麻烦， 理由如下：
在ril.h中定义了每个关键字对应的值，同时在ril_command.h有张映射表
而且是按ril.h中的顺序映射的，大家可以看作是数组的下标。
这里要一一对应，如果从中间插入，将会导致后面的字段映射不对。
除非把ril.h中关键字对应的值修改，但这样会浪费比较多的时间。
2。 hardware/ril/libril/
在该文件的const char *requestToString(int request)函数里面添加消息映射字符串。
3。 hardware/ril/libril/ril_commands.h
在该文件的最后添加函数映射表， 形如{MARK, dispatch
, respon}
解释如下：
首先第1个参数即为我们之前所定义的标识，即MARK。
第2个参数是下层的从数据流中解出数据的函数，这里要和上层所传下来的类型对应，例如上层传下来的是int数组，这里也得是dispathInts， 否则数据会出错
第3个参数是该函数所要返回的值， 这里的和第2个参数的一样。
4。 hardware/ril/reference-ril/reference-ril.c
这里就是发AT命令的核心文件，
在static void onRequest (int request, void *data, size_t datalen, RIL_Token t)里面添加我们所要处理的AT命令函数。
照着别人写的， 自己加以修改就可以了。这里对2个发送AT命令的函数进行说明下：
一般来说， 都是这样的，对只返回成功与否的AT命令，我们用at_nd_command()。 而对于有返回值的命令，我们用at_nd_command_singleline()。
======================================================================================================
最后回到上层的中，在processUnsolicited()或者processSolicited()里面添加返回值即可。
这里我们只选择其中一个来处理，在processUnsolicited()是处理主动上报类型的命令的，即不需要你发送命令去查询的类型。 而processSolicited()则是需要通过发送命令才会返回结果的类型。
大家只要看看那函数里面的值是如何返回的即可， 注意我们选用的返回函数，得和我们在ril_command.h里面所添加的函数映射表里的返回函数对应。
到了这里，AT命令的过程就添加结束， 命令的返回值就在调用Phone里面的函数所传入的Message中。 返回的是一个AsyncResult， 就是Message的obj成员 。
这里我们可以处理异常，一般可通过如下代码处理(假设传入的Message为msg)：
AsyncResult ar = (AsyncResult)
if (ion != null) 处理异常
处理结果，就对进行处理。
本文以通话设置中的呼叫等待的设置为例，讲解RIL的流程。其实其余的也类似如此
路径: package/apps/Phone/src/com/android/phone
呼叫等待的onClick事件在里面
当点击呼叫等待的CheckboxPreference时，调用以下函数：
CallFeaturesSettings::onPreferenceTreeClick（）
其中：
el if (preference == mButtonCW) {
handleCWClickRequest(ked());
nextState = _NETWORK_CONNECT;
}
这里的mButtonCW便是呼叫等待的这个CheckboxPreference
继续追下去，调用
CallFeaturesSettings::handleCWClickRequest()
这里便有：
lWaiting(b, (mSetOptionComplete, EVENT_CW_EXECUTED));
===================================================================================
以下转到: framework/ba/telephony/java/com/android/internal/telephony/gsm
其中mPhone是Phone的对象，追到Phone里面，发现Phone是个接口.
得找出是哪个类去实现这个接口的，是GSMPhone.
里面就有tCallWaiting（）这个函数。
public void tCallWaiting(boolean enable, Message onComplete) {
lWaiting(enable, E_CLASS_VOICE, onComplete);
}
发现这个函数又是调用别人的函数，其中mCM是CommandsInterface对象，而CommandsInterface又是个接口。
像刚才一样，得找出是谁实现了CommandsInterface。找到。
寻找tCallWaiting（）：
pu
blic void
tCallWaiting(boolean enable, int rviceClass, Message respon)
{
RILRequest rr
= (RIL_REQUEST_SET_CALL_WAITING, respon);
//以下对rr中的mp写入数据。mp是Parcel的对象
nt(2);
nt(enable ? 1 : 0);
nt(rviceClass);
if (RILJ_LOGD) riljLog(String() + "> " + requestToString(st)
+ " " + enable + ", " + rviceClass);
nd(rr);
}
这里的RILRequest是获取呼叫等待的RIL请求消息。这里得留意RIL_REQUEST_SET_CALL_WAITING， 这个可以认为是该请求的ID。
在以及中有对此ID号的解析，映射成了一个string，以在后面对其进行处理。
nd()便是把这个请求发送出去。
private void
nd(RILRequest rr)
{
Message msg;
msg = Message(EVENT_SEND, rr);
acquireWakeLock();
Target();
}
看下nd()，会发现，在nd的时候，mSender获取了这个消息。之后该请求进入了消息队列。一开始追到这里就懵了，感觉没有对消息进行处理，就卡住了。
这里得说下Handler对消息队列的处理机制。
是这样的，Handler所获取的消息，都会进入消息队列。而等消息出来的时候，将会在Handler的handlerMessage()中对其进行处理。
因此，在Target()之后，就是mSender对象的handleMessage()对此消息进行处理。
追查到mSender的handlerMessage（）， 把代码好好看一遍。
其实这里就是对rr里面所打包的数据进行解包，以字节流的方式，写入socket.
===========================================================================================================
回到，会发现在RIL的构造函数里面，有如下部分：
mSenderThread = new HandlerThread("RILSender");
();
Looper looper = per();
mSender = new RILSender(looper);
mReceiver = new RILReceiver();
mReceiverThread = new Thread(mReceiver, "RILReceiver");
();
这里注意mSender是RILSender的实例
而mReceiver是RILReceiver的实例
在mReceiver，注意到在它开启了一个线程，这个线程里面有如下代码：
s = new LocalSocket();
l = new LocalSocketAddress(SOCKET_NAME_RIL,ED);
t(l);
因此，在进入的时候便连上了socket。
其次有个mSocket=s。其实就是将RILSender与RILReceiver共用一个socket。
查找这个socket的name， 是SOCKET_NAME_RIL， 其中有：
static final String SOCKET_NAME_RIL = "rild";
在sourceInSight中查找这个socket_name，即rild
其次，
路径：hardware/ril/
搜到这个文件，毫无疑问，这个就是上层的开启的socket所连接上的文件，开始要跟硬件打交道了。
至于连接上socket后具体做了什么事情，参阅文档：GSM驱动模块详细分析(一)～（三）
以下只是初略的
写下大概的流程。
中建立了消息循环，而对消息的处理以及解析，都在reference_ril.c中
要想知道处理的函数在哪，就得找到上面所说的请求ID号所映射的字符串， 搜索字符串便能找到相应的请求函数。
请求均在onRequest()里面，再通过respon进行解析。
同时reference_ril.c将解析好的消息传回给socket，将字节流返回到上层。
============================================================================================
而返回到上层的时候，便是RILReceiver的工作，它会将返回上来的字节流进行处理。
处理函数为RIL::processRespon（）
其中：
AT的respon有两种，一是主动上报的，比如网络状态，短信，来电等都不需要经过请求，有一unsolicited词语专门描述。
另一种才是真正意义上的respon，也就是命令的响应，用solicited描述。
最后将处理后的消息，返回给最初的mSetOptionComplete
流程：
CallFeaturesSetting::onPreferenceTreeClick()
->CallFeaturesSetting::handleCWClickRequest()
->Phone::tCallWaiting()
->GSMPhone::tCallWaiting()
->CommandInterface::tCallWaiting()
->RIL::tCallWaiting()
->RIL::nd()
与此同时，RILSender mSender把RILRequest rr里面所打包好的数据解包，以字节流写入socket。
此时底层的GSM驱动对此字节流进行请求和解析，将结果返回给上层。这结果恰好就是以引用方式所传下来的Message。
->Message::ndToTarget()
->CallFeaturesSetting::mSetOptionComplete::handleMessage()
