短息接收

android之情殇 2012-12-29

展开全文

2012-07-07 13:13

目录(?)[+]

短彩信的接收流程

涉及的文件

[plain] view plain copy

com.android.internal.telephony/Ril.java
com.android.internal.telephony/SMSDispatcher
com.android.internal.telephony/CommandsInterface
com.android.internal.telephony/GsmSMSDispatcher
com.android.internal.telephony/CdmanSMSDispatcher
com.android.internal.telephony/ImsSMSDispatcher
hardware/ril/libril/ril.cpp
com.android.mms.transaction/PrivilegedSmsReceiver

流程分析

时序图

android ril java层接收短息的流程

1）监听底层上报的数据

在Ril.java中定义了一个receive的框架：当接收到短信时，底层首先通过rild将接收到的短信通过 socket传送给Ril.java,那大家都知道这个短信接收是一个不定时的，所以就必须有一个监听器一直监视这个socket一旦有短信就触发其相应的操作。那Ril.java是否有定义这样的一个监听器或者类似的功能了？（补充：这涉及一个Modem端与rild的通信，rild是一个守护进程，是整个android ril层的入口点，这部分笔者不是很清楚，推荐网页http://blog.163.com/yan_zhennan@126/blog/static/10934475020122275412446/）

通过查看代码我们可以发现RILReceiver的内部类：

[html] view plain copy

class RILReceiver implements Runnable {
byte[] buffer;
RILReceiver() {
buffer = new byte[RIL_MAX_COMMAND_BYTES];
}
public void
run() {
int retryCount = 0;
String rilSocket = "rild";
try {for (;;) {
LocalSocket s = null;
LocalSocketAddress l;
boolean multiRild = SystemProperties.getBoolean("ro.multi.rild", false);
if (mInstanceId == 0 || multiRild == false) {
rilSocket = SOCKET_NAME_RIL;
} else {
rilSocket = SOCKET_NAME_RIL1;
}
try {
s = new LocalSocket();
l = new LocalSocketAddress(rilSocket,
LocalSocketAddress.Namespace.RESERVED);
s.connect(l);
}
if (retryCount == 8) {
Log.e (LOG_TAG,
"Couldn't find '" + rilSocket
+ "' socket after " + retryCount
+ " times, continuing to retry silently");
} else if (retryCount > 0 && retryCount < 8) {
Log.i (LOG_TAG,
"Couldn't find '" + rilSocket
+ "' socket; retrying after timeout");
}
try {
Thread.sleep(SOCKET_OPEN_RETRY_MILLIS);
} catch (InterruptedException er) {
}
retryCount++;
continue;
}
retryCount = 0;
mSocket = s;
Log.i(LOG_TAG, "Connected to '" + rilSocket + "' socket");
int length = 0;
try {
InputStream is = mSocket.getInputStream();
for (;;) {
Parcel p;
length = readRilMessage(is, buffer);
if (length < 0) {
// End-of-stream reached
break;
}
p = Parcel.obtain();
p.unmarshall(buffer, 0, length);
p.setDataPosition(0);
processResponse(p);
p.recycle(); }

2）对底层上报的数据进行处理从上面的代码看出这个线程一直和守护进程rild进行sorcket通信，并获取守护进程上报的数据。可以看出做了很多的工作但是最重要的是processResponse（）方法向上汇报数据，下面是其处理代码：

[html] view plain copy

<p>
private void
processResponse (Parcel p) {
int type;
type = p.readInt();
if (type == RESPONSE_UNSOLICITED) {
processUnsolicited (p);
} else if (type == RESPONSE_SOLICITED) {
processSolicited (p);
}
releaseWakeLockIfDone();
}</p>

可以看出在上报数据进行了分类处理，RESPONSE_UNSOLICITED表示接收到数据就直接上报的类型，主动上报，如网络状态和短信、来电等等。 RESPONSE_SOLICITED是必须先请求然后才响应的类型。当然这里是短信接收肯定会走前者。processUnsolicited该方法会根据当前的请求的类型，如果是短信则是RIL_UNSOL_RESPONSE_NEW_SMS，以下是其调用的代码；

[html] view plain copy

case RIL_UNSOL_RESPONSE_NEW_SMS: {
if (RILJ_LOGD) unsljLog(response);
// FIXME this should move up a layer
String a[] = new String[2];
a[1] = (String)ret;
SmsMessage sms;
sms = SmsMessage.newFromCMT(a);
if (mSMSRegistrant != null) {
mSMSRegistrant
.notifyRegistrant(new AsyncResult(null, sms, null));
}
break;
}

3）追溯该方法，mSMSRegistrant对象的创建过程mSMSRegistrant是BaseCommands的成员变量，且在调用 setOnNewSMS（）方法来赋值的，BaseCommands是干什么的有的童鞋会问,我们看一下Ril.java的继承关系就知道了，Ril.java是它的子类。了解了这些童鞋肯定会问那谁又调用了setOnNewSMS方法？以下是该流程的时序图。

最后发现该方法设置handler的源头是在GsmSMSDispatcher类里，但最后会调用SmsDispatcher的 handMessage方法。原因是GsmSMSDispatcher是SmsDispatcher的子类而且GsmSMSDispatcher没有复写 handMessage方法，所以接收到消息后肯定由父类的handMessage方法来处理。

到此为止android的ril java层走完了，剩余的就交给中间层慢慢去做。

注意：

1）这是2.3的代码，对比一下4.0的代码可以发现GsmSMSDispatcher复写了handMessage的方法，自己会去处理，但是仅限于EVENT_NEW_SMS_STATUS_REPORT、EVENT_NEW_BROADCAST_SMS、 EVENT_WRITE_SMS_COMPLETE其余的事件仍由父类SmsDispatcher来完成。

2）4.0中没有setOnNewSMS该方法，替换成了setOnNewGsmSms、setOnNewCdmaSms方法，对应于不同类型的phone做自己的注册。

framework SMSDispatcher接收短信后的处理流程

中间层SMSDispatcher处理流程：

1）该类做了一件重要的事：

给CommandInterface设置handler的处理方法，就是当接收到短信后触发mSMSRegistrant.notifyRegistrant(new AsyncResult(null, sms, null));方法

然后回调调用之前传入的handler，接着在handler里面处理短信消息。

2）handler处理接收到的短信消息：

[html] view plain copy

@Override
public void handleMessage(Message msg) {
AsyncResult ar;
switch (msg.what) {
case EVENT_NEW_SMS:
// A new SMS has been received by the device
if (Config.LOGD) {
Log.d(TAG, "New SMS Message Received");
}
SmsMessage sms;
ar = (AsyncResult) msg.obj;
if (ar.exception != null) {
Log.e(TAG, "Exception processing incoming SMS. Exception:"
+ ar.exception);
return;
}
sms = (SmsMessage) ar.result;
try {
int result = dispatchMessage(sms.mWrappedSmsMessage);
if (result != Activity.RESULT_OK) {
// RESULT_OK means that message was broadcast for app(s) to
// handle.
// Any other result, we should ack here.
boolean handled = (result == Intents.RESULT_SMS_HANDLED);
notifyAndAcknowledgeLastIncomingSms(handled, result, null);
}
} catch (RuntimeException ex) {
Log.e(TAG, "Exception dispatching message", ex);
notifyAndAcknowledgeLastIncomingSms(false,
Intents.RESULT_SMS_GENERIC_ERROR, null);
}
break;
}
}

说明：

int result = dispatchMessage(sms.mWrappedSmsMessage);

该段会通过子类（GsmSMSDispatcher）的dispatchMessage方法处理。
经一系列的判断处理最后普通短信将交给dispatchPdus(pdus);这个方法处理。

[html] view plain copy

protected void dispatchPdus(byte[][] pdus) {
Intent intent = new Intent(Intents.SMS_RECEIVED_ACTION);
intent.putExtra("pdus", pdus);
dispatch(intent, "android.permission.RECEIVE_SMS");
}
void dispatch(Intent intent, String permission) {
// Hold a wake lock for WAKE_LOCK_TIMEOUT seconds, enough to give any
// receivers time to take their own wake locks.
mWakeLock.acquire(WAKE_LOCK_TIMEOUT);
mContext.sendOrderedBroadcast(intent, permission, mResultReceiver,
this, Activity.RESULT_OK, null, null);
}

3）我们可以看出这个方法将短信通过顺序广播播放出去（action是SMS_RECEIVED_ACTION），无论广播是否被中断最后都会调用 mResultReceiver，这里会将已读或未读的状态告诉给对方。如果短信广播中间没有受到終止。然后短信app中 PrivilegedSmsReceiver广播接收器接收到广播后会调用onReceiveWithPrivilege方法，由于 PrivilegedSmsReceiver继承与SmsReceiver，所以会调用父类的该方法。其代码：

[html] view plain copy

protected void onReceiveWithPrivilege(Context context, Intent intent, boolean privileged) {
// If 'privileged' is false, it means that the intent was delivered to the base
// no-permissions receiver class. If we get an SMS_RECEIVED message that way, it
// means someone has tried to spoof the message by delivering it outside the normal
// permission-checked route, so we just ignore it.
if (!privileged && (intent.getAction().equals(Intents.SMS_RECEIVED_ACTION)
|| intent.getAction().equals(Intents.SMS_CB_RECEIVED_ACTION))) {
return;
}
intent.setClass(context, SmsReceiverService.class);
intent.putExtra("result", getResultCode());
beginStartingService(context, intent);
}