Enabling SMS support in Hangouts 2.0 breaks the BroadcastReceiver of SMS_RECEIVED in my app

Flow picture Flow · Nov 16, 2013 · Viewed 7.7k times · Source

I just received the update for Hangouts 2.0, installed it and enabled SMSTurn on SMS. Now my application, running under Android 4.3, is unable to receive SMS any more, i.e. my BroadcastReceiver for SMS_RECEIVED is no longer called. :-(

As soon as I disable Turn on SMS in Hangouts 2.0, my app is able to receive SMS_RECEIVED intents again.

The Broadcast receiver is registered in the Manifest like this

AndroidManifest.xml

…
<receiver android:name=".SMSReceiver" >
    <intent-filter>
        <action android:name="android.provider.Telephony.SMS_RECEIVED" />
    </intent-filter>
</receiver>
…

SMSReceiver.java

public class SMSReceiver extends BroadcastReceiver {

    private static final Log LOG = Log.getLog();

    @Override
    public void onReceive(Context context, Intent intent) {
            LOG.d("onReceive");
            …
    }
}

I already tried to change the priority of the receiver to INT_MAX or 999, which is the highest possible priority as of the intent-filter documentation, but without success. I know that SMS_RECEIVED intents are send ordered and that high priority apps have the ability to abort the broadcast.1 But it seems unlikely that Hangouts 2.0 is registering the SMS_RECEIVED receiver with a high priority and calling abortBroadcast(), therefore preventing any other apps from receiving the intent.

What further confused me, is that my Pebble is still able to receive SMS, even with Hangouts 2.0 as default SMS app. I wonder what Pebble does different? I just noticed that the incoming SMS notification on my Pebble are no longer notifications for new SMS that are received by the Pebble app, but instead are "new Hangout message" notifications that are caused by hangouts receiving the incoming SMS. So the Pebble app is also not able to receive incoming text messages with SMS_RECEIVED.

On a side note and not really related to this issue, because I am still on Android 4.3 (but my app targets SDK level 19, Android 4.4 in case it matters) Google's Android Developers Blog post about the new SMS API in Kitkat, said that nothing would change for apps using just SMS_RECEIVED and don't try to write the SMS to the SMS Provider.

1 I always believed that the SMS_RECEIVED broadcast is abortable. But the Android 4.4 APIs site says something different: "…when a new SMS arrives by listening for the SMS_RECEIVED_ACTION broadcast, which is a non-abortable broadcast…"

Answer

Flow picture Flow · Nov 19, 2013

Fixed it.

The first problem was that, as you can see in revision 2 of my question, I put the priority attribute within the action element, when it actually belongs into the intent-filter element. So the priority didn't work.

While still targeting API 19, I did some experiences with Hangouts SMS enabled and different priorities.

  • No priority set → BroadcastReceiver doesn't receive SMS_RECEIVED intent
  • Priority 500 → BroadcastReceiver does receive SMS_RECEIVED intent
  • Priority 9991 → BroadcastReceiver does receive SMS_RECEIVED intent

So it seems that you need to have a minimum value for priority in order to get the intent with Hangouts SMS enabled. I didn't bother to bisect the lowest possible value. ;) I am going with 999 as I don't see any reason to get lower because my app does just some quick checks on the received sms and does not further process it. But it should really make a difference, as the broadcast is non-abortable.

1The maximum value