You might remember a couple of weeks ago when Google gave developers a heads up about changes to KitKat that might cause problems for SMS apps. At the time, we knew that this only meant there would be a single app in charge of writing to the database, while all of the others would...well, that part wasn't really defined. Today, one in a series of developer videos gave us a little clarification on what it means to be a default app, and what it means for the rest of them.

As a quick refresher, here's specifically what we knew. One app at a time would be registered as the "Default SMS App" and it was the only app allowed to write to the SMS Content Provider, a central repository for all of my text messages. This app had to implement Receivers for SMS and MMS, a Service for creating and sending SMS, and provide an Activity for composing a new SMS (sorry for the developer terms there). By being the default, the app was guaranteed to get every single message by listening for SMS_DELIVER_ACTION and WAP_PUSH_DELIVER_ACTION. This last bit is important because it was previously possible for other apps to intercept a message and cancel it before your normal texting app ever saw it.

As for the apps that aren't default, we already knew that they could continue sending messages if they had the proper permissions, reading from the database of messages, and listening for new messages through SMS_RECEIVED_ACTION and WAP_PUSH_RECEIVED_ACTION. We were also told that any app can check which is the default for SMS using Telephony.Sms.getDefaultSmsPackage() method and request to turn itself or any other qualified app into the default with the Telephony.Sms.Intents.ACTION_CHANGE_DEFAULT Intent.


Ok, we already knew quite a bit; Google's blog post was pretty detailed. However, there are a few things covered by the video that should answer most of those nagging questions. To begin with, the SMS Content Provider will automatically log every SMS message sent by a non-default app. The same is not true for MMS, which can only be logged manually by the default SMS app. Further, only the default app is allowed to make any changes to the database, which can include actions like marking a message as read or deleting it.

Overall, this changes are pretty good if you like to use more than one messenger. Most people would already want everything they send to be recorded and shared across apps, which is precisely what is supported. As previously discussed, backup and restore tools will require a few extra button taps, but that should be little more than a minor inconvenience. Security apps that quietly send content like GPS coordinates and pictures aren't really in bad shape either, but they will have to adjust their methods to send everything through MMS to avoid detection from a thief. Unfortunately, if those security apps were triggered by a text message sent from another phone, there won't be much of a way to hide that without elevating the status of your security software to default. The only true casualty to this change will be the apps that rely on cloud syncing to duplicate text messages across devices. Sadly, this class of utility is going to have a hard time keeping everything organized.

As you can see, the threat level for this change is pretty insignificant. There will be a few casualties - and that is unfortunate - but there is no need to fear that you will be forced to use a single app for your texting requirements.