一. 彩信发送:
彩信比短信麻烦很多。从sendMmsWorker函数的参数就可以看出来：(conv, mmsUri, persister, slideshow, sendReq) 上下文，uri，PduPersister（彩信是用pdu的），slideshow 包含了所有的彩信信息，sendreq包含了mime封装mms时的headers,也包括了from,to等信息 。 
(1)函数 sendMmsWorker： 

?

     前面挺长一段代码，检查这个对话（conversation)之前还有没有未发送的信息。需要提到一下MessageStatusListener，这个Interface接口定义在WorkingMessage.java里，而实现是在ComposeMessageActivity.java中，所以前者在一些状态改变的时候可以很方便的调用后者的一些函数作相应的改动。MessageStatusListener中主要包括：    onProtocolChanged彩信短信互切换，onAttachmentChanged附件改变，onPreMessageSent发消息前，onMessageSent发消息后。这里调用了onPreMessageSent这个监听函数， 然后ComposeMessageActivity 就会调用resetMessage函数 ，这个函数会调整显示，focus，软键盘等。 
检查mmsUri。如果这个uri是空的话，直接造一个新的uri继续发送。这个createDraftMmsMessage(persister, sendReq, slideshow);函数可以包含所有发送需要的信息, 如果uri不为空,调用的是updateDraftMmsMessage(mmsUri, persister, slideshow, sendReq); 总之功能是把这个将发送的mms，存disk了，也就是存draft了。
deleteDraftSmsMessage 删除草稿 。
创建一个MmsMessageSender，用这个sender来调用sendMessage函数。
如果函数返回值表示刚刚发送出去的其实是一个短信sms，而已。于是要把数据库里存着的draft删掉。
调用onMessageSent这个监听函数，调用ComposeMessageActivity的onMessageSent，这个函数功能是重新显示conversationList。 
(2)createDraftMmsMessage(persister, sendReq, slideshow); 和 updateDraftMmsMessage(mmsUri, persister, slideshow, sendReq); 这两个函数从本质上讲是一样的,把附件的东西以pdubody的形式存下来，另外就是更新uri。
3)MmsMessageSender.java类，在mms/transaction下面,实现了MessageSender接口,这个接口sendMessage并返回boolean的值。若发送的是mms，返回true。若发送的是sms，返回false。

单卡手机彩信发送的时序图如图所示

双卡手机彩信发送的时序图如图1.5所示：

二.彩信接收
彩信接收的时序图如图1.3所示：

三、接收Wappush信息及彩信附件增加删除
1..Wappush接收的时序图如图所示：

2.彩信附件增加删除
彩信附件添加：在ComposeMessageActivity里的addAttachment(int type) 函数 根据type的不同，分成7个case 

• MediaSelectListActivity.ADD_IMAGE
• MediaSelectListActivity.TAKE_PICTURE
• MediaSelectListActivity.ADD_VIDEO
• MediaSelectListActivity.RECORD_VIDEO
• MediaSelectListActivity.ADD_SOUND
• MediaSelectListActivity.RECORD_SOUND
• MediaSelectListActivity.ADD_SLIDESHOW

从外面的activity读取媒体数据的应用返回的时候都回到onActivityResult()函数。

删除附件，AttachmentEditor里面有个handler，用来给ComposeMessageActivity传消息。所有删除附件操作的按钮都在AttachmentEditor上。对不同的媒体类型有不同的按钮，但是按下之后出口是一样的，之所以一样是因为所有的附件都存在SlideshowModel里，而这个SlideshowModel是: ArrayList<SlideModel> mSlides; 一列儿slide组成的。 每个slide可以包含video,image,audio，text， 其中前三者一般不能两两同时存在，唯一的例外是image和audio.
说回到那个remove操作,composeMessageActivity的Handler里的handleMessage函数，接到这个删除msg之后的操作是setAttachment().

短信部分：
短信的发送，Framework部分从SmsManager的sendTextMessage（普通短信，无分段）与sendMultipartTextMessage（长短信，已分段）开始，一直到RIL。主要涉及到的类有。SmsManager、Isms、IccSmsInterfaceManager、SMSDispatcher、ImsSMSDispatcher、GsmSMSDispatcher、CdmaSMSDispatcher、SmsMessage、SmsTracker、CommandsInterface、BaseCommands、RIL、LocalSocket、RilRequest、Parcel等。



SmsManager->RIL：
sendTextMessage和sendMultipartTextMessage的过程其实差不多，无非是sendMultipartTextMessage对长短信进行了一下处理，为每一个part设置了SmsHeader。ImsSMSDispatcher中包含了两种不同的SmsDispatcher，IccSmsInterfaceManager调用SmsDispatcher中各个方法时，会根据手机类型的不同，调用不同SmsDispatcher的相应方法。大致过程为：1、计算编码方式；2、对每一个分段构造SmsHeader、SubmitPdu、SmsTracker，并设置RadioTechnologyFamily；3、利用SmsTracker构造当消息正常发送后调用的Message对象；4、调用与手机卡类型有关的RIL中的相应方法发送。



RIL中发送：
sendImsGsmSms、sendSms、sendCdmaSms、sendImsCdmaSms这四个方法基本流程是大致相同的，都是先构造RILRequest，再调用send方法发送。区别就在于不同的方法在获得RILRequest时传入的请求类型不同，构造出来的pdu结构不同，以及两个Ims方法需要先往RILRequest中写入一个数字。



发送后的处理：
已发送状态修改（sentIntent的调用过程）RILReceiver->SMSDispatcher：
在RIL的构造方法中，创建了一个RILReceiver对象，该对象实现了Runnable接口。它的作用是不停地从下层获取数据，分析类型，转到相应SMSDispatcher处理。
当短信通过LocalSocket发送出去后，由于是主动请求，下层会传上来一个响应，其基本类型为RESPONSE_SOLICITED，转入processSolicited处理。在该方法中，对于短信发送的处理，均调用responseSMS方法获取SmsResponse对象。（前面四种方式对应的事件类型为sendSMS-RIL_REQUEST_SEND_SMS、 sendCdmaSms-RIL_REQUEST_CDMA_SEND_SMS、sendImsGsmSms&sendImsCdmaSms-RIL_REQUEST_IMS_SEND_SMS）
然后创建AsyncResult对象，将SmsResponse对象与SmsTracker对象（SMSRequest中的）传入，更新之前在各个SMSDispatcher中创建的消息正常发送后调用的Message中的obj，设为创建的AsyncResult对象。将消息发送至相应SmsDispatcher处理。



已发送状态修改（sentIntent的调用过程）SMSDispatcher.handleMessage：
由于之前在构造Message对象时设置了what为SEND_SMS_COMPLETE，因此，此处调用handleSendComplete方法进行短信发送的后续处理。若需要发送报告，将SmsTracker加入deliveryPendingList中，这样后面收到发送报告时，能够从该列表中取出进行处理（具体参见应用层部分发送报告的处理）。



deliveryIntent（发送报告）RIL->SMSDispatcher：
对于GSM，在构造方法中，将GsmSMSDispatcher注册为RIL接收到发送报告时该事件的接收者，并设置消息类型为EVENT_NEW_SMS_STATUS_REPORT，相应的Registrant类为mSmsStatusRegistrant。
而对于CDMA，则设置消息类型为EVENT_NEW_SMS，相应的Registrant类为mCdmaSMSRegistrant。
当RIL收到底层传来的发送报告后（过程与已发送状态修改相同），会产生一个基本类型为RESPONSE_UNSOLICITED，转入processUnsolicited处理。
对于GSM，其事件类型为RIL_UNSOL_RESPONSE_NEW_SMS_STATUS_REPORT。先调用responseString从Parcel中获取数据，再调用mSmsStatusRegistrant的notifyRegistrant方法设置消息类型（what属性为EVENT_NEW_SMS_STATUS_REPORT）并转到SMSDispatcher进行处理。
而CDMA，事件类型为RIL_UNSOL_RESPONSE_CDMA_NEW_SMS。处理过程与GSM大致相同，只是从Parcel中获取数据是调用responseCdmaSms方法获取SmsMessage对象。然后调用mCdmaSMSRegistrant的notifyRegistrant方法设置消息类型（what属性为EVENT_NEW_SMS）并转到SMSDispatcher进行处理。
deliveryIntent（发送报告）SMSDispatcher：
对于GSM，直接调用handleStatusReport方法处理。从传入的AsyncResult对象中获取SmsMessage进而获取SmsTracker的索引，从deliveryPendingList中取出SmsTracker，发送deliveryIntent并发送消息确认。
对于CDMA，在handleMessage中转到EVENT_NEW_SMS。调用dispatchMessage进行消息的分发。



短信接收RIL->SMSDispatcher：
GSM，在构造方法中，将GsmSMSDispatcher注册为RIL接收短信时该事件的接收者，并设置消息类型为EVENT_NEW_SMS，相应的Registrant类为mSMSRegistrant。
CDMA，与发送报告相同，消息类型为EVENT_NEW_SMS，相应的Registrant类为mCdmaSMSRegistrant。
RILReceiver接收到短信后，会转到processUnsolicited进行处理。
对于GSM，其事件类型为RIL_UNSOL_RESPONSE_NEW_SMS。先调用responseString从Parcel中获取数据，再使用newFromCMT方法获取SmsMessage对象，最后调用mSMSRegistrant的notifyRegistrant方法设置消息类型（what属性为EVENT_NEW_SMS）并转到SMSDispatcher进行处理。
而CDMA，事件类型为RIL_UNSOL_RESPONSE_CDMA_NEW_SMS。过程与接收报告相同。
短信接收SMSDispatcher：
GSM，首先获取SmsHeader。
如果SmsHeader或SmsHeader.concatRef均不为空，说明是长短信，则调用processMessagePart将短信分段存入raw表，待所有分段都收到后，将其组装。然后根据端口的不同，按照彩信通知（WapPushOverSms的dispatchWapPdu方法）、指定端口的彩信（dispatchPortAddressedPdus）、长短信（dispatchPdus）进行分发处理。
若SmsHeader或SmsHeader.concatRef有一个为空，说明不是长短信。然后根据端口的不同，按照彩信通知（WapPushOverSms的dispatchWapPdu方法）、指定端口的彩信（dispatchPortAddressedPdus）、普通短信（dispatchPdus）进行分发处理。
GSM和CDMA的短信接收有很大一部分是相同的，只是CDMA由于标准定义的不同，需要进行一些其他的处理。
CDMA没有类似GSM中的User Data Header（UDA）来存储一些额外信息，而是使用一个16位整数CDMA TELESERVICE来确定消息的类型。
如果其为TELESERVICE_WAP，说明是CDMA彩信通知，则调用processCdmaWapPdu来处理。该方法的作用是将接收到的分段数据先存入raw表。只有当所有分段都接收到后，如果端口是WAP_PUSH的彩信，才调用WapPushOverSms的dispatchWapPdu方法将彩信通知内容解码后通过广播发送到应用层。否则，调用dispatchPortAddressedPdus方法将其发送到指定端口（sms://localhost:port）。
另外，CDMA中提供了一种cmas消息。如果是这种消息，当收到时，立即调用dispatchBroadcastPdus方法发送紧急广播。



彩信接收：
在Android中，彩信的接收分为两部分。彩信通知通过短信的方式接收，如上文所述。彩信数据的下载在应用层中处理。

短信部分：
短信的发送，Framework部分从SmsManager的sendTextMessage（普通短信，无分段）与sendMultipartTextMessage（长短信，已分段）开始，一直到RIL。主要涉及到的类有。SmsManager、Isms、IccSmsInterfaceManager、SMSDispatcher、ImsSMSDispatcher、GsmSMSDispatcher、CdmaSMSDispatcher、SmsMessage、SmsTracker、CommandsInterface、BaseCommands、RIL、LocalSocket、RilRequest、Parcel等。



SmsManager->RIL：
sendTextMessage和sendMultipartTextMessage的过程其实差不多，无非是sendMultipartTextMessage对长短信进行了一下处理，为每一个part设置了SmsHeader。ImsSMSDispatcher中包含了两种不同的SmsDispatcher，IccSmsInterfaceManager调用SmsDispatcher中各个方法时，会根据手机类型的不同，调用不同SmsDispatcher的相应方法。大致过程为：1、计算编码方式；2、对每一个分段构造SmsHeader、SubmitPdu、SmsTracker，并设置RadioTechnologyFamily；3、利用SmsTracker构造当消息正常发送后调用的Message对象；4、调用与手机卡类型有关的RIL中的相应方法发送。



RIL中发送：
sendImsGsmSms、sendSms、sendCdmaSms、sendImsCdmaSms这四个方法基本流程是大致相同的，都是先构造RILRequest，再调用send方法发送。区别就在于不同的方法在获得RILRequest时传入的请求类型不同，构造出来的pdu结构不同，以及两个Ims方法需要先往RILRequest中写入一个数字。



发送后的处理：
已发送状态修改（sentIntent的调用过程）RILReceiver->SMSDispatcher：
在RIL的构造方法中，创建了一个RILReceiver对象，该对象实现了Runnable接口。它的作用是不停地从下层获取数据，分析类型，转到相应SMSDispatcher处理。
当短信通过LocalSocket发送出去后，由于是主动请求，下层会传上来一个响应，其基本类型为RESPONSE_SOLICITED，转入processSolicited处理。在该方法中，对于短信发送的处理，均调用responseSMS方法获取SmsResponse对象。（前面四种方式对应的事件类型为sendSMS-RIL_REQUEST_SEND_SMS、 sendCdmaSms-RIL_REQUEST_CDMA_SEND_SMS、sendImsGsmSms&sendImsCdmaSms-RIL_REQUEST_IMS_SEND_SMS）
然后创建AsyncResult对象，将SmsResponse对象与SmsTracker对象（SMSRequest中的）传入，更新之前在各个SMSDispatcher中创建的消息正常发送后调用的Message中的obj，设为创建的AsyncResult对象。将消息发送至相应SmsDispatcher处理。



已发送状态修改（sentIntent的调用过程）SMSDispatcher.handleMessage：
由于之前在构造Message对象时设置了what为SEND_SMS_COMPLETE，因此，此处调用handleSendComplete方法进行短信发送的后续处理。若需要发送报告，将SmsTracker加入deliveryPendingList中，这样后面收到发送报告时，能够从该列表中取出进行处理（具体参见应用层部分发送报告的处理）。



deliveryIntent（发送报告）RIL->SMSDispatcher：
对于GSM，在构造方法中，将GsmSMSDispatcher注册为RIL接收到发送报告时该事件的接收者，并设置消息类型为EVENT_NEW_SMS_STATUS_REPORT，相应的Registrant类为mSmsStatusRegistrant。
而对于CDMA，则设置消息类型为EVENT_NEW_SMS，相应的Registrant类为mCdmaSMSRegistrant。
当RIL收到底层传来的发送报告后（过程与已发送状态修改相同），会产生一个基本类型为RESPONSE_UNSOLICITED，转入processUnsolicited处理。
对于GSM，其事件类型为RIL_UNSOL_RESPONSE_NEW_SMS_STATUS_REPORT。先调用responseString从Parcel中获取数据，再调用mSmsStatusRegistrant的notifyRegistrant方法设置消息类型（what属性为EVENT_NEW_SMS_STATUS_REPORT）并转到SMSDispatcher进行处理。
而CDMA，事件类型为RIL_UNSOL_RESPONSE_CDMA_NEW_SMS。处理过程与GSM大致相同，只是从Parcel中获取数据是调用responseCdmaSms方法获取SmsMessage对象。然后调用mCdmaSMSRegistrant的notifyRegistrant方法设置消息类型（what属性为EVENT_NEW_SMS）并转到SMSDispatcher进行处理。
deliveryIntent（发送报告）SMSDispatcher：
对于GSM，直接调用handleStatusReport方法处理。从传入的AsyncResult对象中获取SmsMessage进而获取SmsTracker的索引，从deliveryPendingList中取出SmsTracker，发送deliveryIntent并发送消息确认。
对于CDMA，在handleMessage中转到EVENT_NEW_SMS。调用dispatchMessage进行消息的分发。



短信接收RIL->SMSDispatcher：
GSM，在构造方法中，将GsmSMSDispatcher注册为RIL接收短信时该事件的接收者，并设置消息类型为EVENT_NEW_SMS，相应的Registrant类为mSMSRegistrant。
CDMA，与发送报告相同，消息类型为EVENT_NEW_SMS，相应的Registrant类为mCdmaSMSRegistrant。
RILReceiver接收到短信后，会转到processUnsolicited进行处理。
对于GSM，其事件类型为RIL_UNSOL_RESPONSE_NEW_SMS。先调用responseString从Parcel中获取数据，再使用newFromCMT方法获取SmsMessage对象，最后调用mSMSRegistrant的notifyRegistrant方法设置消息类型（what属性为EVENT_NEW_SMS）并转到SMSDispatcher进行处理。
而CDMA，事件类型为RIL_UNSOL_RESPONSE_CDMA_NEW_SMS。过程与接收报告相同。
短信接收SMSDispatcher：
GSM，首先获取SmsHeader。
如果SmsHeader或SmsHeader.concatRef均不为空，说明是长短信，则调用processMessagePart将短信分段存入raw表，待所有分段都收到后，将其组装。然后根据端口的不同，按照彩信通知（WapPushOverSms的dispatchWapPdu方法）、指定端口的彩信（dispatchPortAddressedPdus）、长短信（dispatchPdus）进行分发处理。
若SmsHeader或SmsHeader.concatRef有一个为空，说明不是长短信。然后根据端口的不同，按照彩信通知（WapPushOverSms的dispatchWapPdu方法）、指定端口的彩信（dispatchPortAddressedPdus）、普通短信（dispatchPdus）进行分发处理。
GSM和CDMA的短信接收有很大一部分是相同的，只是CDMA由于标准定义的不同，需要进行一些其他的处理。
CDMA没有类似GSM中的User Data Header（UDA）来存储一些额外信息，而是使用一个16位整数CDMA TELESERVICE来确定消息的类型。
如果其为TELESERVICE_WAP，说明是CDMA彩信通知，则调用processCdmaWapPdu来处理。该方法的作用是将接收到的分段数据先存入raw表。只有当所有分段都接收到后，如果端口是WAP_PUSH的彩信，才调用WapPushOverSms的dispatchWapPdu方法将彩信通知内容解码后通过广播发送到应用层。否则，调用dispatchPortAddressedPdus方法将其发送到指定端口（sms://localhost:port）。
另外，CDMA中提供了一种cmas消息。如果是这种消息，当收到时，立即调用dispatchBroadcastPdus方法发送紧急广播。



彩信接收：
在Android中，彩信的接收分为两部分。彩信通知通过短信的方式接收，如上文所述。彩信数据的下载在应用层中处理。