Android Mms receiving information process

Information receiving is done at the underlying layer. When a new information is received at the underlying layer, the upper-layer application is notified in Intent mode, the information is also included in the Intent, and the information Intent supported by Android is defined in android. provider. telephony. intents.

Receive SMS

The upper-layer application processes the broadcast event SMS_RECEIVED_ACTION, which is sent by Frameworks to notify the upper-layer that a new SMS has been received. In Mms, it is handled by PrivilegedSmsReceiver. It receives SMS_RECEIVED_ACTION (android. provider. telephony. intents. SMS_RECEIVED_ACTION = "android. provider. telephony. SMS_RECEIVED) will start SmsReceiverService for specific processing.

SmsReceiverService first checks the type of the SMS. If it is a Class0 SMS, it is directly displayed in the GUI without any other processing, that is, it is not stored in the database, and do not do Notification in the Notification Bar.

For other text messages, existing messages are replaced or inserted as new messages. The principle is that if the existing text messages in the database are the same as the original address and protocol ID of the new SMS, they will be replaced with the new SMS, otherwise, it will be inserted as a new text message.

Specific replacement process: generate a ContentValues with the new text message, and then query the ContentValues with the text message address and protocol ID as the condition. If the information is found, replace the text message. Otherwise, it will be stored.

The storage process is to form a CotentValues, and then take out the Thread Id and address of the SMS. The address must be synchronized with the contact database to ensure that the address is recognizable. If the Thread Id is not valid, use the synchronized address to re-generate the Thread Id five times. Then, place the refreshed Thread Id in ContentValues and insert ContentValues into the database. If you want to store the information to the SIM card, you also need to call SmsManager to copy the information to the SIM card. Calculate the SMS size and update it to the database. Delete expired SMS messages and SMS messages that have exceeded the limit, and then return the inserted SMS Uri.

Finally, use Uri to go to StatusBar for Notification for the replaced or inserted text message.

The GUI can also get new text messages when refreshing the list, because the text messages have been stored in the database.

Receiving of MMS

The receiving process of MMS is slightly different from that of SMS. The application is responsible for downloading the MMS information from the MMSC Multimedia Messaging Service Center. The general process is that Frameworks sends a text message to inform the application of a MMS Message, which contains some information such as the expiration date, the sender's mobile phone number, and the mms url, then the application automatically retrieves the MMS content specified by the URL through HTTP. The specific process is as follows:

Telephony Frameworks sends an Intent: android. provider. Telephony. Intents. WAP_PUSH_RECEIVED_ACTION = "android. provider. Telephony. WAP_PUSH_RECEIVED" message to the upper-layer application. This Intent will contain a "data" byte array (through byte [] data = intent. getByteArrayExtra ("data"). This Byte array describes some information about the mms. It is a NotificationInd, which contains some information about the MMS, such as the mobile phone number of the sender, the ContentLocation (URL) of the MMS ). Then, the application determines how to proceed.

In Mms, transaction. pushReceiver. java receives WAP_PUSH_RECEIVED_ACTION. After receiving the Intent message of the MMS, it performs some preprocessing, retrieves the data field, parses it into GenericPdu using the Pdu tool, and then converts it to icationicationind, write it to the database, and then start TransactionService for further icationication_transaction processing. At the same time, the Uri of notifind IND is also passed.

TransactionService is triggered. In its onStartCommand, the Intent sent by pushcycler is placed in its MessageQueue, and icationication_transaction is processed when TRANSACTION_REQUEST is processed in Handler. handleMessage. First, load some default MMS-related configuration information, mainly MMSC, Proxy and Port. These are all information related to the carrier and can be changed through the APN settings. TransactionService uses the Uri of icationicationind sent by PushReciver and the loaded configuration information TransactionSettings to construct a NotificationTransaction object. After that, TransactionService checks the two queues in the queue, adds the queue to the Pending queue, or directly processes the queue (adds the queue to the processing queue), and directly calls icationicationtransaction. process ().

The NotificationTransaction process () method inherits from the parent class Transaction. It simply starts a new thread and returns, in this way, the Service can process other Transaction requests.

In the thread, first load some configuration information from DownloadManager and TelephonyManager, whether the MMS is set to auto retrieve, and whether Telephony is set to DATA_SUSPEND ), then, different measures are taken to retrieve the expiration date of the MMS from icationind ind. If the configuration is not to fetch data (more specifically, it is not to fetch data now), Mark DownloadManager's status as STATE_UNSTARTED first, send a Response y Response Indication to MMSC, and end the processing, function return. The notification processing process for MMS ends here. You can manually download the MMS by using other methods through the UI, which will be discussed in detail later.

If it is set to automatic acquisition or data transmission is smooth, mark the DownloadManager status as START_DOWNLOADING and start to download MMS data. The color message is obtained through the ContentLocation (URL) from HTTP to the MMS. First, call the parent method getPdu (), pass in the mms url, and finally call the httpConnection method of HttpUtils to send an http get request. MMSC will return the MMS data as the return value of getPdu. We get a byte array. We need to use the Pdu tool to parse it into GenericPdu, then use PduPersister to write it into the database, and then update the MMS size to the database, the receiving of a MMS Message is complete. The rest is that, because the MMS data has been obtained, You need to delete the previous notification information (notifind IND), update the related status, and return Notify Response Indication to MMSC, end Processing. Because the database has changed, the UI will receive the ContentChanged event, refresh the UI list, and the new information will be displayed.

As mentioned above, if the MMS configuration is set to not automatically obtained, after the UI is refreshed, the MMS notification will be displayed: expiration date, MMS size, etc., and a "Download" button will be provided. You can click the button to download the MMS content. After you click the button, TransactionService is started to package the Uri of the MMS notification and RETRIEVE_TRANSACTION request into an Intent and send it to TransactionService. TransactionService, like processing other transactions, is put into its own MessageQueue, then load the default TransactionSettings, build the RetrieveTransaction object, and then process and call RetrieveTransaction. process ().

RetrieveTransaction is also inherited from Transaction, and its process () is also used to create a thread and then return. In the process, it first uses the Pdu tool to load the multimedia notification (notifind IND) from the database according to the Uri, obtains the expiration date of the multimedia message from icationind ind, and checks the expiration date. If the multimedia message has expired, send y Response Indication to MMSC. Mark the DownloadManager status as start download. If the MMS has expired, mark the Transaction status as Failed, return, and end the processing process. If everything is normal, getPdu () is used to obtain the MMS content from the ContentLocation (URL) of the mms. It is obtained through HTTP through HttpUtils. httpConnection () and a byte array is returned. Use the Pdu tool to parse the byte array and obtain the GenericPdu. check whether it is a new message or duplicate information. If it is repeated, mark it as failed, return it, and end the processing. If it is a new message, first write the GenericPdu into the database with PduPersister, update the information size and ContentLocation (URL) to the database, where all the MMs have been obtained. Next, send the received confirmation message to MMSC, mark the processing status as successful, and end the processing. At this time, the UI should listen to database changes and refresh. New information should be displayed to users.

Summary: similar to sending information, a database also plays an important role in receiving information. After receiving the information, it parses the information and writes it to the database, which is different from sending, the received information is not in that many States. Once the information is written to the database, it means that the information is successfully received. The UI only listens to changes in the database, and immediately refreshes the display information.