Android MMS: Receive information flow (text) _android

The information receives the work is completes by the bottom, when has a new information when the bottom completes receives the intent way to inform the upper level application, the information related content also includes in intent, The information intent that Android supports are defined in android.provider.Telephony.Intents.
Receipt of SMS

SMS reception, for the upper application is to deal with the broadcast event sms_received_action, it is sent by the frameworks to tell the upper layer that a new SMS has been 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 SMS, if it is Class0 SMS, directly in the GUI display, do not do any other processing, it will not be stored in the database, and will not be in notification bar to do notification.

For other text messages, either replace the existing message or insert it as a new message. The principle is that if the existing text in the database, and the original address of the new message and the identity of the protocol is the same, then replace it with a new text message, or as a new text message inserted.

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

The stored process is also a cotentvalues, and then takes out the thread ID and address of the SMS, which is synchronized with the contact database to ensure that it is an identifiable address. If the thread ID is not legal, attempt to regenerate the thread ID with a synchronized address, try 5 times. The refreshed thread ID is then placed in the Contentvalues, and the contentvalues is inserted into the database. If set to store the information to the SIM card, also call Smsmanager to copy the information to the SIM card. Calculate the size of the SMS and update to the database. Delete expired text messages, and text messages that exceed the number limit, and then return the inserted SMS URI.
Finally, for the replacement or insertion of text messages, use the URI to StatusBar do notification.
The GUI can also get new text messages when refreshing the list, because the text messages are already stored in the database.

Reception of MMS
MMS reception process and SMS slightly different, it is mainly by the application is responsible for MMS from the Service Center (MMSC Multimedia Messaging service centre) download MMS information. The general process is frameworks will send a text message, told the application has a MMS, message contains some information such as the expiration date, the sender's mobile phone number, MMS URL, and so on, and then the application through HTTP to retrieve the URL refers to the MMS content. The specific process is:

Telephony Frameworks will send out a intent first:android.provider.telephony.intents.wap_push_received_action= " Android.provider.Telephony.WAP_PUSH_RECEIVED "tells the top application to have a MMS coming. This intent contains a "data" byte array (via byte[] data = Intent.getbytearrayextra ("Data"), and this byte array is a description of some information about this MMS, It is a notificationind, which contains some information about MMS, such as the sender cell phone number, MMS contentlocation (URL). Then it is up to the application to decide how to do the next process.

In MMS is by Transaction.PushReceiver.java to receive wap_push_received_action, receive MMS notification intent, it will do some preprocessing, the data field out, The PDU's tool resolves to become GENERICPDU, then translates it into a notificationind, writes it to the database, and then starts transactionservice for further notification_transaction processing, At the same time, the URI of the Notificationind is passed over.

Transactionservice is aroused, and in its onstartcommand, it handles the intent of pushreceiver into his own MessageQueue, and then in Handler.handlemessage () handles notification_transaction when processing transaction_request. First, load the default configuration information related to MMS, primarily mmsc,proxy and port, which are related to carrier information and can be changed by APN settings. Transactionservice constructs a Notificationtransaction object transactionsettings with the URI of the Notificationind and loaded configuration information from Pushreciver. After that, Transactionservice checks the two queues in it, either joins the pending queue, or processes directly (joins to the processing queue), and the processing is directly called notificationtransaction.process ().

The notificationtransaction process () method is inherited from the parent class transaction, which simply opens a new thread and then returns, allowing the service to handle other transaction Request it.

In the thread, first load some configuration information from Downloadmanager and Telephonymanager, whether the MMS is set to Automatic (auto retrieve), and whether the telephony is set to data latency (data_suspend) , and then take different steps to remove the expiration date of the MMS from the Notificationind. If the configuration is not to fetch the data (or, more specifically, not to fetch the data now), then the Downloadmanager status is marked as state_unstarted, then the MMSC is sent a notify Response indication, and then the processing is terminated. function returns, the notification processing process for MMS ends here. Users can manually download MMS in other ways by manipulating the UI, which is discussed in more detail later.

If set to automatic acquisition or data transfer is unblocked, then the Downloadmanager status marked as start_downloading and start downloading MMS data. The acquisition of MMS is obtained by contentlocation (URL) of HTTP to MMS. First, the parent class method GETPDU () is invoked, the URL of the MMS is passed in, and the Httputils Httpconnection method is eventually invoked to send an HTTP GET request, MMSC will return the MMS data as the return value of GETPDU (). Get a byte array, you need to use the PDU tool to resolve to become GENERICPDU, and then use Pdupersister to write it to the database, and then update the size of the MMS to the database, where a MMS received 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 be automatically acquired, then the UI refresh will display MMS notification: Expiration date, MMS size, and so on, and provide a "Download" button. Users can click the button to download MMS content, click on the button, will start Transactionservice, the MMS notification of the URI, and Retrieve_transaction The request is packaged into a intent and passed to Transactionservice. Transactionservice, like dealing with other transaction, is put into its own MessageQueue, then load the default transactionsettings, build the Retrievetransaction object, Then process the call Retrievetransaction.process ().

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, obtains the multimedia message expiration date from the Notificationind, examines the expiration date, if the MMS has expired, then sends the MMSC notify Response indication. Mark the Downloadmanager status as the start download, and then if the MMS has expired, mark the transaction status as failed, and then return to end the processing process. If everything is OK, use GETPDU () to get the MMS content from the contentlocation (URL) of the MMS, which will be retrieved using Httputils.httpconnection () via HTTP, returning a byte array. Use the PDU tool to parse the byte array, get GENERICPDU, check for new information, duplicate information, if repeated, mark as failure, then return, end processing. If it is new information, first write the GENERICPDU with Pdupersister to the database, update the information size and contentlocation (URL) to the database, to where a MMS is actually all finished. The next step is to send a confirmation message to MMSc, and the tag processing status is successful and end processing. The UI should then monitor the database changes and refresh, and 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 resolution, and then write to the database, and send different, received information is not so many states, once written to the database means that information received has been successful, The UI also listens only for changes to the database, and immediately refreshes the display information once it has changed.