IssueTracker

Under certain circumstances, SMSDispatcher can incorrectly construct multi-part SMS messages, resulting in a corrupted message being dispatched to the applications.  The corrupted message contains parts from previously received multi-part SMS messages instead of the corresponding parts from the newly received message.

The error occurs if the last received part of a multi-part message is retransmitted by the network (and therefore received twice by the handset), which can be normal network behaviour under certain conditions (for instance, in marginal coverage where the SMS acknowledgement from the handset for the first transmission of the SMS was not received).

The logic to reconstruct multi-part SMS messages is in SMSDispatcher.processMessagePart().  It uses the SMS provider to store parts of an incomplete multi-part message.  Once an entire multi-part message is received, the parts of the previously incomplete message are deleted from the provider.  The logic runs like this:

1. If the current message is part of a multi-part message, query the database for parts matching the address/reference-number of the current message.
2. If all parts have now been received, dispatch the message to the application and delete stored parts from the database.
3. If the message is incomplete (all parts have not been received), store the current message in the database.

The problem occurs if the last received part is retransmitted.  This results in this retransmitted last part being orphaned in the database, as it is treated like the first received part of a new multi-part message (but this "ghost" new multi-part message will obviously never be completed, so these orphans will hang around).

The results of this can be seen on a handset by dumping the contents of the provider database content://sms/raw which is likely to contain a number of old message parts (if the handset has been used extensively to receive multi-part messages... which mine has).

This would be relatively benign (the database slowly filling up), were it not for the fact that the reference-number (used to key the parts of multi-part messages together) can be an 8-bit quantity, so ultimately messages with the same address/reference-number will be received, if a large number of multi-part messages are received from the same source.

Unfortunately, the logic in SMSDispatcher.processMessagePart() results in the old orphaned retransmitted message parts being treated as part of a newly received multi-part message with a matching (recycled) reference-number.

In this failure condition, the logic behaves like this (in an example of a 2-part multi-part message matching a previously received retransmitted final part):

1. Received message is part 1 of a 2-part multi-part message, so query the database for an existing parts matching the address/reference-number of this message.
2. The database contains part 2 of a previously received 2-part message matching the address/reference-number, because part 2 of the previously received message was retransmitted by the network and was therefore orphaned in the database.
3. SMSDispatcher assumes that the entire 2-part message has now been received (part 1 just received, and part 2 orphaned in the database from the previous message) so it constructs a message consisting of the new part 1 and the old part 2 and dispatches it to the applications.  All entries matching the address/reference-number are deleted from the database.
4. Part 2 of the new message is received.  It doesn't match anything in the database, so remains there - perpetuating the problem of orphaned parts of multi-part messages in the database.

Step 3 above results in a corrupted message being dispatched to the applications.  Step 4 means that this problem only gets worse over time (I have 14 orphaned message parts in the database, accumulated over the last six months).

For my own benefit, I am writing an APK to query the content://sms/raw database table and allow the orphaned parts to be deleted.  However, the logic in SMSDispatcher.processMessagePart() needs to be fixed to prevent these orphaned message parts persisting.