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

Question

I just received the update for Hangouts 2.0, installed it and enabled SMS → Turn 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.¹ 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.

¹ 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 1

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 999¹ → 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.

¹The maximum value

Answer 2

According to the most recent Google Hangouts Manifest, they have an AbortSmsReceiver set with a priority of "3" - so it seems that any app that wants to receive the SMS_RECEIVED broadcast on API 18 or lower should use a priority higher than 3:

<receiver android:name="com.google.android.apps.babel.sms.AbortSmsReceiver" android:permission="android.permission.BROADCAST_SMS" android:enabled="false">
    <intent-filter android:priority="3">
        <action android:name="android.provider.Telephony.SMS_RECEIVED" />
    </intent-filter>
</receiver>

You can use a build target of API 19. Apps on a device running API 19 (KitKat) will not be able to abort the broadcast as in prior API's. This prevents apps from performing a premature abort.

I assume they included this abort to prevent stock messaging apps from posting duplicate notifications. Stock messaging apps should process at priority 0 prior to KitKat - but any application that does not set a priority is processed at 0 also. IntentFilter objects are created with a default priority value of "0":

public IntentFilter() {
        mPriority = 0;
        mActions = new ArrayList<String>();
}

Answer 3

I can still get the broadcast fine. Just installed the new hangouts and enabled SMS. In my case, I am just reading the SMS contents and that continues to work. What I have done, though, was to set the priority of the intent-filter to 999 following a previous thread here:

<intent-filter android:priority="999" >
   <action android:name="android.provider.Telephony.SMS_RECEIVED" />
</intent-filter>

Maybe that is playing a role?

UPDATE: Just read that you changed your target to SDK level 19. In that case, I read that you have to change how your app behaves (can't find the link now) following API 19 guidelines. Change your target back to 18 and it should work just fine.

Answer 4

I'm having the same issue. I'm targeting sdk 17, and I'm still unable to get the broadcast if Hangouts is enabled to handle SMS. Who knows how many applications Hangouts just broke in the market.

I'll try tweaking the priority and see if that helps.

[edit] Yup, the priority fixed it for me on target sdk 17. thanks!

Answer 5

When you register receiver, set priority of filter to INTEGER.MAX_VALUE. Now abortBroadcast() will work;

receiver = new HightPrioritySmsReceiver();
IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
filter.setPriority(Integer.MAX_VALUE);
registerReceiver(receiver, filter);