Android short MMS sending and receiving process (Framework)

Text message section:
For short message sending, the Framework starts from sendTextMessage (common short message without segmentation) and sendMultipartTextMessage (long short message, segmented) of SmsManager until RIL. The main classes involved are. SmsManager, Isms, secure, SMSDispatcher, ImsSMSDispatcher, GsmSMSDispatcher, CdmaSMSDispatcher, SmsMessage, SmsTracker, CommandsInterface, BaseCommands, RIL, LocalSocket, RilRequest, and Parcel.
 

 
SmsManager-> RIL:
The process of sendTextMessage is similar to that of sendMultipartTextMessage. Instead, sendMultipartTextMessage processes long messages and sets SmsHeader for each part. ImsSMSDispatcher contains two different SmsDispatcher methods. When IccSmsInterfaceManager calls each method in SmsDispatcher, it calls the corresponding methods of different SmsDispatcher Based on the mobile phone type. The general process is as follows: 1. Calculation encoding method; 2. Construct SmsHeader, SubmitPdu, and SmsTracker for each segment, and set radiopolicyfamily; 3. Use SmsTracker to construct the Message object called after the Message is normally sent; 4. Call the corresponding method in RIL related to the mobile phone card type for sending.
 

 
Send in RIL:
The basic processes of sendImsGsmSms, sendSms, sendCdmaSms, and sendImsCdmaSms are roughly the same. They all construct an RILRequest and then call the send method to send the request. The difference is that different methods have different request types when obtaining RILRequest, the structure of the constructed pdu is different, and two Ims methods need to write a number to RILRequest first.
 

 
Processing after sending:
Sent status modification (sentIntent call process) RILReceiver-> SMSDispatcher:
In the RIL constructor, an rilcycler object is created, which implements the Runnable interface. Its function is to constantly retrieve data from the lower layer, analyze the type, and transfer it to the corresponding SMSDispatcher for processing.
After the text message is sent through LocalSocket, a response is sent to the lower layer because it is an active request. The basic type of the response is RESPONSE_SOLICITED, which is transferred to processSolicited for processing. In this method, the responseSMS method is called to obtain the SmsResponse object. (The event types corresponding to the previous four methods are sendSMS-RIL_REQUEST_SEND_SMS, sendCdmaSms-RIL_REQUEST_CDMA_SEND_SMS, sendImsGsmSms & sendImsCdmaSms-RIL_REQUEST_IMS_SEND_SMS)
Create an AsyncResult object, pass in the SmsResponse object and the SmsTracker object (in SMSRequest), and update the obj in the Message called after messages created in each SMSDispatcher are normally sent, set as the created AsyncResult object. Send the message to the SmsDispatcher for processing.
 

 
Sent status modification (sentIntent call process) SMSDispatcher. handleMessage:
Because the SEND_SMS_COMPLETE is set when constructing the Message object, the handleSendComplete method is called for subsequent processing of text Message sending. To send a report, add SmsTracker to the deliveryPendingList so that the report can be retrieved from the list for processing when it is received (For details, refer to the report sending process at the application layer ).
 

 
DeliveryIntent (Send Report) RIL-> SMSDispatcher:
For GSM, In the constructor, register the GsmSMSDispatcher as the receiver of the event when the RIL receives the report and set the message type to EVENT_NEW_SMS_STATUS_REPORT. The corresponding Registrant class is mSmsStatusRegistrant.
For CDMA, set the message type to EVENT_NEW_SMS and the corresponding Registrant class to mcmasmsregistrant.
After the RIL receives the Send Report from the underlying layer (the process is the same as the sent status change), a basic type of RESPONSE_UNSOLICITED is generated and transferred to processUnsolicited for processing.
For GSM, the event type is RIL_UNSOL_RESPONSE_NEW_SMS_STATUS_REPORT. Call responseString to obtain data from Parcel, call the mSmsStatusRegistrant's policyregistrant method to set the Message Type (what attribute is EVENT_NEW_SMS_STATUS_REPORT), and convert it to SMSDispatcher for processing.
For CDMA, the event type is ril_unsol_response_cdma _new_sms. The processing process is roughly the same as that of GSM, except that the responseCdmaSms method is called to obtain the SmsMessage object from Parcel. Call the notifyRegistrant method of mCdmaSMSRegistrant to set the Message Type (what attribute is EVENT_NEW_SMS) and go to SMSDispatcher for processing.
DeliveryIntent (Send Report) SMSDispatcher:
For GSM, The handleStatusReport method is called directly for processing. Obtain smessage from the input AsyncResult object to obtain the index of SmsTracker. Extract SmsTracker from deliveryPendingList, send deliveryIntent, and send message confirmation.
For CDMA, transfer to EVENT_NEW_SMS in handleMessage. Call dispatchMessage to distribute messages.
 

 
Message recipient RIL-> SMSDispatcher:
GSM: In the constructor, register the GsmSMSDispatcher as the receiver of the event when the RIL receives the SMS, set the message type to EVENT_NEW_SMS, and set the Registrant class to mSMSRegistrant.
CDMA, which is the same as sending a report. The message type is EVENT_NEW_SMS, and the corresponding Registrant class is mcmasmsregistrant.
After receiving the text message, rilcycler forwards it to processUnsolicited for processing.
For GSM, the event type is RIL_UNSOL_RESPONSE_NEW_SMS. Call responseString to obtain data from Parcel, use newFromCMT to obtain the SmsMessage object, call the mSMSRegistrant notifyRegistrant method to set the Message Type (what attribute is EVENT_NEW_SMS), and convert it to SMSDispatcher for processing.
For CDMA, the event type is ril_unsol_response_cdma _new_sms. The process is the same as that of receiving reports.
SMS receiving SMSDispatcher:
GSM: first obtain the SmsHeader.
If neither SmsHeader nor SmsHeader. concatRef is blank, it indicates that the message is a long message, you can call processMessagePart to save the text message segments to the raw table. After all segments are received, assemble them. Then, based on the port, the distribution process is performed according to the MMS notification (dispatchWapPdu method of WapPushOverSms), the specified port MMS (dispatchPortAddressedPdus), and the long SMS (dispatchPdus.
If either SmsHeader or SmsHeader. concatRef is empty, the message is not a long message. Then, based on the port, the distribution process is performed according to the MMS notification (dispatchWapPdu method of WapPushOverSms), the specified port MMS (dispatchPortAddressedPdus), and the general text message (dispatchPdus.
Most of the messages received by GSM and CDMA are the same, but CDMA needs to be processed according to different standard definitions.
CDMA does not store additional information like the User Data Header (UDA) in GSM, but uses a 16-bit integer cdma teleservice to determine the message type.
If it is TELESERVICE_WAP, it indicates that it is a CDMA Multimedia Message notification, and it will be handled by calling processcdn mawappdu. The function of this method is to first store the received segment data into the raw table. The dispatchWapPdu method of WapPushOverSms is called to decode the MMS notification content and send it to the application layer through broadcasting only after all segments are received. Otherwise, call the dispatchPortAddressedPdus method to send it to the specified port (sms: // localhost: port ).
In addition, a cmas message is provided in CDMA. If the message is received, immediately call the dispatchBroadcastPdus method to send an emergency broadcast.
 

 
MMS reception:
In Android, MMS is received in two parts. MMS notifications are received by SMS, as described above. The download of MMS data is processed at the application layer.

 

Author haliluya4