So, I had a play, and it is possible to delete a received SMS.
Unfortunately it's not all plain sailing :(
I have a receiver that picks up on incoming SMS messages. Now the way the Android SMS incoming routing works is that the piece of code responsible for decoding the messages sends a Broadcast (it uses the sendBroadcast()
method - which unfortunately is NOT the version that lets you simply call abortBroadcast()
) whenever a message arrives.
My receiver may or may not be called before the Systems SMS receiver, and in any case the received broadcast has no property that could reflect the _id
column in the SMS table.
However, not being one to be stopped that easily I post myself (via a Handler) a delayed message with the SmsMessage as the attached object. (I suppose you could post yourself a Runnable too...)
handler.sendMessageDelayed(handler.obtainMessage(MSG_DELETE_SMS, msg), 2500);
The delay is there to ensure that by the time the message arrives all of the Broadcast receivers will have finished their stuff and the message will be safely ensconced in the SMS table.
When the message (or Runnable) is received here is what I do:
case MSG_DELETE_SMS:
Uri deleteUri = Uri.parse("content://sms");
SmsMessage msg = (SmsMessage)message.obj;
getContentResolver().delete(deleteUri, "address=? and date=?", new String[] {msg.getOriginatingAddress(), String.valueOf(msg.getTimestampMillis())});
I use the originating address and timestamp field to ensure a very high probability of deleting ONLY the message I am interested in. If I wanted to be even more paranoid I could include the msg.getMessageBody()
content as part of the query.
Yes, the message IS deleted (hooray!).
Unfortunately the notification bar is not updated :(
When you open up the notification area you'll see the message sitting there for you... but when you tap on it to open it up - it's gone!
To me, this isn't quite good enough - I want all trace of the message to disappear - I don't want the user to think there is a TXT when there isn't (that would only cause bug reports).
Internally in the OS the phone calls MessagingNotification.updateNewMessageIndicator(Context)
, but I that class has been hidden from the API, and I did not want to replicate all of that code just for the sake of making the indicator accurate.