Android Mms receives information flow

The reception of information is done by the bottom, when there is a new information when the bottom of the completion of the reception will be intent to notify the upper application, information related content is also included in the intent, Android support information intent are determined Righteousness is inside the android.provider.Telephony.Intents.

Receipt of SMS

SMS receive, for the upper application is to deal with broadcast event Sms_received_action, it is sent by frameworks to tell the upper layer that there is a new SMS received. In MMS, which is handled by Privilegedsmsreceiver, it receives sms_received_action (Android.provider.Telephony.Intents.SMS_RECEIVED_ACTION = "Android.provider.Telephony.SMS_RECEIVED") will start Smsreceiverservice to do the specific processing.

Smsreceiverservice will first check the type of text messages, if it is Class0 text messages, directly in the GUI display, do not do any other processing, it will not be stored in the database, and will not do notification in notification bar.

For other text messages, either replace the existing message or insert it as a new message. The principle is that if in the database already has the text message, and the new incoming text message's original address and the Agreement logo are the same, then replace it with the new incoming text message, otherwise as the new text message inserts.

Specific replacement process: First use a new text message to generate a contentvalues, and then use the address of the text message and protocol identification as a condition to the database to query, if found, replace, otherwise it will be stored.

The stored process is also Mr. Cotentvalues, then take out the thread ID and address of the text message, and the address should be synchronized with the contact database to ensure that it is an identifiable address. If the thread ID is not legal, try to regenerate the thread ID with the synchronized address and try 5 times. Then put the refreshed thread ID into the contentvalues and insert the contentvalues into the database. If set to store information on a SIM card, also call Smsmanager to copy the information to the SIM card. Calculates the size of the text message and updates it to the database. Delete expired text messages, and exceed the number limit SMS, then return the text message URI after inserting.

Finally, for replacement or insertion of text messages, use the URI to StatusBar do notification.

The GUI can also get new text messages when it refreshes the list, because the text messages are stored in the database.

Receiving of MMS

The receiving process of MMS is slightly different from SMS, and it is primarily the application's responsibility to download MMS messages from the MMS Service Center (MMSC Multimedia Messaging Service centre). The general process is that frameworks will send a text message informing the application that there is an MMS message that contains information such as the expiration date, the sender's mobile phone number, the URL of the MMS, and so on, and the application uses HTTP to retrieve the MMS content referred to by the URL. The specific process is:

Telephony Frameworks will issue a intent:android.provider.telephony.intents.wap_push_received_action= first " Android.provider.Telephony.WAP_PUSH_RECEIVED "informs the upper application that there is a multimedia message coming up. This intent contains a "data" byte array (via byte[] data = Intent.getbytearrayextra ("Data"), which is a description of some information about the MMS, which is a Notificationind, which contains some information about MMS, such as the sender's mobile phone number, MMS contentlocation (URL). It is then up to the application to decide how to do the next processing.

In MMS is by Transaction.PushReceiver.java to receive wap_push_received_action, after receiving the MMS notification intent, it will do some preprocessing, the data field out, Use the PDU tool to parse into a GENERICPDU, then convert it to Notificationind, write it to the database, and then start Transactionservice for further notification_transaction processing, At the same time, the Notificationind URI is also passed.

Transactionservice is aroused, in its onstartcommand will deal with Pushreceiver from the intent into their own MessageQueue, and then in Handler.handlemessage Processing notification_transaction when Transaction_request is processed in (). First load the default some MMS-related configuration information, mainly Mmsc,proxy and port, these are carrier-related information, can be changed through the APN settings. Transactionservice Pushreciver a Notificationtransaction object with the URI of the Notificationind and the loaded configuration information. After that, Transactionservice checks the two queues in it, either joins the pending queue, or directly processes (joins to the processing queue), and the processing also calls Notificationtransaction.process () directly.

Notificationtransaction's process () method is inherited from the parent class transaction method, it simply opens a new thread, and then returns, so that the service can handle the other transaction Request now.

In the thread, some configuration information is first loaded from Downloadmanager and Telephonymanager, whether the MMS is set to Auto-get (auto retrieve), and whether the telephony is set to data latency (data_suspend) , and then take different measures to remove the expiration date of the MMS from the Notificationind. If it is configured to not fetch data (more specifically, it is not fetching the data now), then the status of Downloadmanager is marked as state_unstarted, then a notify Response indication is sent to MMSc, and then the processing is ended, function returns, the notification processing flow for multimedia messages ends here. Users can manually download MMS messages by manipulating the UI, and this will be discussed in more detail later.

If set to auto get or data transfer is unblocked, then mark the Downloadmanager status as start_downloading and start downloading MMS data. The acquisition of MMS is the Contentlocation (URL) of HTTP to MMS to get data. First calls the parent class method GETPDU (), the URL of the incoming MMS, and finally calls the Httputils Httpconnection method to send an HTTP GET request, MMSC returns the MMS data as the return value of the GETPDU (). Get is a byte array, need to use the tool of the PDU to parse into GENERICPDU, then use Pdupersister to write it to the database, and then update the size of the MMS to the database, where a MMS receive even completed. The rest is, because the MMS has been obtained data, so to remove the previous notification information (Notificationind), and then update the relevant state, to MMSC return notify Response indication, end processing. Because the database has changed, the UI receives the Contentchanged event, refreshes the UI list, and the new information is displayed.

As mentioned earlier, if the MMS configuration is set to not get automatically, the UI refreshes and then displays the MMS notification: expiration date, MMS size, and so on, and provides a "Download" button. Users can click the button to download MMS content, click on the button will start Transactionservice, the MMS notification URI, and retrieve_transaction Request is packaged into a intent and passed to Transactionservice. Transactionservice, like other transaction, are put into their own MessageQueue, then load the default transactionsettings, build Retrievetransaction objects, The call Retrievetransaction.process () is then processed.

Retrievetransaction is also inherited from transaction, whose process () also creates a thread and then returns. In the thread, first it uses the PDU tool to load the MMS notification (NOTIFICATIONIND) from the database according to the URI, gets the expiration date of the MMS from the Notificationind, checks the expiration date, and if the MMS has expired, send the MMSc notify Response indication. Mark the Downloadmanager status as starting the download, and then if the MMS has expired, mark the transaction status as failed, and then return to the end of the processing process. If everything is OK, the MMS content will be retrieved from the Contentlocation (URL) of the MMS message using GETPDU (), which will be retrieved by HTTP with Httputils.httpconnection (), returning a byte array. Use the PDU tool to parse a byte array, get GENERICPDU, check whether it is new information, whether it is duplicate information, if duplicate, mark as failed, then return, end processing. If it is new information, first write GENERICPDU with Pdupersister to the database, update the information size and contentlocation (URL) into the database, where a multimedia message is actually all finished. The next step is to send a confirmation message to MMSC, marking the processing status as successful and ending processing. At this point the UI should listen to changes in the database, and refresh, the new information should be displayed to the user.

Summary, similar to the information sent, the database in the process of receiving information also played an important role, the information received after the parsing, and then write to the database, and send different, receive the information is not so many states, once written to the database means that the information received has been successful, the UI is only listening to changes in the database Refresh the display information as soon as there is a change.