06
Dec
nexusae0_defaultSmsApp
Last Updated: December 12th, 2013

First, we heard that KitKat would bring some changes to the API, breaking many of the SMS apps we've come to rely on. On the day KitKat was released, we were given a more full explanation, shining some light on the technical details and exactly what types of apps would be affected. But did anybody really think this was the end of the story? It turns out that a hidden permission exists which can still grant non-default apps the right to modify the SMS database just like they used to - no rooting required.

The discovery was made by XDA Senior Member Stefano Picciolo (a.k.a. stepic) while digging through the Android 4.4 source code. This new permission isn't a part of the conventional system we've used since the burgeoning days of Android, but it's stowed away in the still semi-hidden App Ops interface. Named OP_WRITE_SMS, this permission is disabled by default and must be granted by the user manually. Of course, this means developers will have to explain to users how to enable the functionality and why it's needed. Yup, that's a good thing.

2013-12-06 10.56.072013-12-06 10.57.192013-12-06 10.57.28

With this capability, users don't have to give up on having multiple fully-functioning SMS apps and cloud-synced messages, they just have to decide which ones are allowed to modify the database. Unfortunately, most backup and restore apps probably won't gain very much, since enabling OP_WRITE_SMS is more of a hassle than switching the default SMS app for a minute while they do their work, but there might be some exceptions.

As Picciolo points out, only one classic function remains unaccounted for. Within KitKat, there is still no way to completely prevent a message from being seen by other apps since the default SMS app is guaranteed to receive a notification. The ability to abort a new message broadcast is frequently used by anti-theft software to allow the owner access to coordinates and other data on a phone without tipping off a thief that the device is being tracked. Obviously, this could be abused by a malicious app, but making the user responsible for making the decision to enable such a permission seems like a reasonable countermeasure.

If you're a user looking to return your texting apps to their regular working order, there are a couple of ways to get to App Ops. The easiest method is to simply install one of the many apps in the Play Store that simply open the screen. Once you're in, swipe over to the Messaging tab, find the app, and enable Write SMS/MMS. If an app isn't an option for any reason, hooking up to a computer and running this rather lengthy adb command will work in a pinch.

adb shell am start -n com.android.settings/com.android.settings.Settings -e :android:show_fragment com.android.settings.applications.AppOpsSummary --activity-clear-task --activity-exclude-from-recents

Since good developers should probably make things as easy as possible for their users, I'm including a handy snippet of code to put in your apps that will open App Ops for the user. Ideally, there should also be an explanation of why users would want to do this and instructions on what exactly to do once they are looking at the App Ops screen. This snippet has been tested on Android 4.3 through the recently released 4.4.1, but there are no promises about future versions.

Update: Sorry, this code stopped working with Android 4.4.2.

Intent intent = new Intent();
intent.setClassName("com.android.settings", "com.android.settings.Settings");
intent.setAction(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_DEFAULT);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK | Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
intent.putExtra(":android:show_fragment", "com.android.settings.applications.AppOpsSummary");
startActivity(intent);

Well, there you have it. We've got most of the original functionality back for SMS apps, it just requires the user to make an actual security decision, which seems like a good thing. This is evidence that App Ops can be a really important feature for advanced users, as it allows us to make more decisions about what apps should be allowed to do. Now, if App Ops would just become more streamlined and user-facing in future updates, we'll be set.

Source: XDA

Cody Toombs
Cody is a Software Engineer and Writer with a mildly overwhelming obsession with smartphones and the mobile world. If he’s been pulled away from the computer for any length of time, you might find him talking about cocktails and movies, sometimes resulting in the consumption of both.

  • sean

    why would you want more than one SMS app though?

    • Darryl

      My main use for it is to block Spam SMS. Where I am, carriers routinely send dozens of Spam texts every week, and SMS blocking apps are very useful.

    • fixxmyhead

      Ninja sms. Floating sms app

    • Andy Stetson

      MightyText. Doesn't do native texting on the phone, but allows you to use a tablet or Chrome for texting via your google account. This will allow it to continue to function like in 4.3 and prior, where it updates the conversation in your primary SMS app.

  • jonathan3579

    I'm wondering if this would help re-enable SMS/MMS on the 3G/LTE versions of the Nexus 7. It was possible through a third party app prior to KitKat.

  • Zargh

    No point even bothering getting familiar with this since it was designed to be a behind the scenes API for the system to use: http://developer.android.com/reference/android/app/AppOpsManager.html

    Dianne Hackborn spelled it out on Google+ here: https://plus.google.com/+DannyHolyoake/posts/FkfBxA5i3iG

    Becoming dependent on App Ops is only going to end in heartbreak since its supposed to be hidden to the end user, so from the Android teams perspective this is a bug to be fixed. A bug which has probably gone up several notches in priority now that its broken the restrictions on the public facing SMS API.

    • Cole Mickens

      Whoa, you mean Google doesn't want to encourage users to tweak things that will just outright causes apps to crash or produce other undefined and untested behaviors.

      This is the same story that played out when custom roms very first floated the idea of just failing those API calls or return bunk data. It's not "easy" when the permissions model is all-or-nothing and declarative the way it is. They'd have to switch to a runtime permission-grant/opt-in functionality to solve this correctly, IMO.

    • http://www.androidpolice.com/author/cody-toombs/ Cody Toombs

      If App Ops goes away, it goes away. So be it. For now, App Ops provides a mechanism for people to continue using the apps they've already been depending on for a few years. If something changes in the next OTA, the next version, or somewhere down the road, then people will have to deal with it at that time. Until then, this is valuable to the users that need this capability.

      • john

        So in other words, you are saying enjoy your cake while it lasts. lol Love the re-wording of the previous guys post though.

        • http://www.androidpolice.com/author/cody-toombs/ Cody Toombs

          Not exactly what I was saying. I hope and expect App Ops to stick around, albeit, probably not in its current form. I know there's a very real chance it will disappear or become nearly impossible to access, and if that happens people will adapt. However, there's no good reason people shouldn't leverage OP_WRITE_SMS while they have it at their disposal.

          For what it's worth, if everybody stops using cloud syncing/backup apps in preparation for a doomsday that may never come, then it only makes it easier for somebody else to argue that this capability has no demand and it should be abandoned. I personally don't use anything for cloud syncing my text messages, but I regularly switch phones, so I do want to set it up.

          Oh, and are you talking about all of the edits he made to his comment? I hadn't even noticed it until now. No harm, he's sticking to the same points he originally made.

    • didibus

      I hope aps ops doesn't go away. So useful to regulate app permissions with.

  • crackinthewall

    Am I the only one who thinks that those Holo blue switches looks out of place?

    • Zargh

      Seems the design team disagrees: "Use your brand color for accent by overriding the Android framework's default blue in UI elements like checkboxes, progress bars, radio buttons, sliders, tabs, and scroll indicators."

      - New in Android, http://developer.android.com/design/patterns/new.html

  • hackbod

    Note: providing source code using private implementation details is irresponsible, since that code is likely to break on future platform versions or different devices.

    • http://www.androidpolice.com/author/cody-toombs/ Cody Toombs

      The words immediately preceding the code do make it clear that it is only known to work on those versions of Android. Ideally, there would be a more reliable way to achieve the desired effect, but for the time being, this is the only viable method without rooting. I would be very happy to see an official workflow for managing permissions, as it would likely solve the needs of some power users and also allow reasonable control over misbehaving apps.

  • MrNinjaPanda

    I don't have Write SMS/MMS option under any of my apps, even my default SMS app. I only have Receive SMS/MMS and Send SMS/MMS. For my default texting app they're all selected, and for others Send SMS/MMS is deselected.

    • Walkop

      Send SMS/MMS is the same as Write, AFAIK. Because you need to be able to write to send.

      • http://www.androidpolice.com/author/cody-toombs/ Cody Toombs

        No, any app (with the standard send SMS permission) can send an SMS/MMS regardless of being default or not. That ability was not removed with KitKat.

        The "default SMS app" can send SMS/MMS messages, and is always guaranteed to get a special system broadcast when one of those messages is received. It can insert new and modify/delete existing messages to the SMS Content Provider (database) without actually sending a message, which is what Backup/Restore apps and cloud syncing apps need. When this app sends a message, it doesn't have to write anything to the database.

        Non-default apps can send SMS/MMS messages, but all SMS messages are automatically written to the database by the OS, and this can't be prevented. I don't know why MMS isn't treated the same way. These apps can still read from the database, but cannot modify it at all. They can also receive a different system broadcast, but it's not guaranteed because another non-default app can abort it.

        There are more details (and complications), but those are most of the pertinent ones.

  • Wyatt Neal

    Man, I was stupid excited when I saw this and then found out that it wouldn't really work with Voice+ the way I was hoping. Google Voice + SMS Hangouts has to be getting closer ... I just have to keep believing and it will happen, right?

  • Ian Kavanagh

    Been using this since about a few days after the Nexus 4 factory images were released. Wasn't aware it would be such a big thing or I'd have let ye know.

    And, for anybody interested, the reason I have more than 1 app writing to the SMS Content Provider is because I have a normal day to day SMS app and an additional one which allows me to send Webtexts for free which I then want written to the SMS Content Provider so I can see my conversations in my day to day SMS app.

  • DS

    Since this is no longer possible with Android 4.4.2, does this mean that I can't seamlessly use multiple SMS apps when I upgrade to 4.4.2 -- once it comes out for my phone -- as I do now on 4.3 (chompSMS for Quick Compose, HoverChat for the "ChatHeads", and sometimes Hangouts if I'm already in the app)? That would be pretty disappointing, as there isn't one app that does everything I would like it to do, and my current setup is pretty functional as is.

  • Ronald Luna

    I was working on a technical language translator program that basically runs when whatever default sms program opens and it converts the text to the specified language on send....does anyone know if this is going to be a problem in kit kat??

Quantcast