ril

Android-RIL流程分析
2010-03-04 09:12
本文以通话设置中的呼叫等待的设置为例,讲解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()

你可能感兴趣的:(thread,android,socket)