Android: Delete SMS at particular threadId location

Question

I am trying to understand the difference between phones, and the software on them. I code and test on the Droid Incredible. A content observer of content://sms works fine and I am able to delete threadIds on the Incredible, but my app crashes on the Moto Droid Milestone. I test for the Milestone using Moto Dev Studio using the Milestone emulator package. It works fine in the emulator, but not on the actual device.

Why would content://sms work fine on the Incredible, but not on the Milestone? Why would it on work on the Milestone emulator and not on the Milestone Device?

Such a delete method is shown below with the uri being content://sms + threadId

getContentResolver().delete(deleteUri, "address=? and date=?", new String[] {msg.getOriginatingAddress(), String.valueOf(msg.getTimestampMillis())});

Many people say such a content observer is not part of the SDK. Understood. How can I delete an sms for legitimate reasons such as creating an separate application with a password that stores sms messages separate and apart from the main text messaging system?

Answer 1

Why would content://sms work fine on the Incredible, but not on the Milestone

Because, as I keep pointing out, content://sms is not part of the Android SDK. There is no reason for it to be the same. Device manufacturers are welcome to change it, eliminate it, and so forth. Google has told you not to use it. The Calendar content provider has already undergone similar revisions with similar impacts on applications. These are simply providers that are part of applications, they are not meant to be used by developers.

How can I delete an sms for legitimate reasons such as creating an separate application with a password that stores sms messages separate and apart from the main text messaging system.

You cannot delete messages from other SMS applications and stick within the bounds of the SDK. Trying to delete messages from the SMS content provider simply may not work on some devices, may have no effect on other devices, may cause other applications to crash on still other devices, and so forth.

For that matter, you cannot create a separate SMS application and stick within the bounds of the SDK, since the Intent you need to receive is undocumented (though widely known). It's not out of the realm of possibility for some device manufacturer to elect to change up this Intent to use a different action, for example. This is at least somewhat less likely, as this would be an OS change rather than a change to some random app (e.g., Messaging, home of the so-called SMS content provider). However, it is possible.