Home » Android » android – GCM / FCM: not receiving events, broadcast intent callback: result=CANCELLED

android – GCM / FCM: not receiving events, broadcast intent callback: result=CANCELLED

Posted by: admin May 14, 2020 Leave a comment

Questions:

There are discussions of this error, but seems they all end up with answers about “stopped state” (of apps).

I’m seeing something different.

I’ve got two cloud push samples, one is the official GCM sample and the other is an FCM project which followed the tutorial and they’re both affected.

Both are installed on a Samsung S6 with 6.0.1, the device is plugged in (no Doze) and connected to WiFi.

From time to time, sending push messages to either the GCM sample or to the FCM app starts to fail with these in the logcat:

07-17 14:37:38.851 W/GCM-DMM (29459): broadcast intent callback: result=CANCELLED forIntent { act=com.google.android.c2dm.intent.RECEIVE flg=0x10000000 pkg=gcm.play.android.samples.com.gcmquickstart (has extras) }

07-17 14:38:25.231 W/GCM-DMM (29459): broadcast intent callback: result=CANCELLED forIntent { act=com.google.android.c2dm.intent.RECEIVE flg=0x10000000 pkg=firebasetest.example.kman.firebasetest (has extras) }

Starting either app’s UI will make push messages go through again (to that app), but the old ones (which produced the errors) will not be re-delivered.

Now – I did not force stop either app. One of them I used just maybe 15 minutes ago. The device did not go to sleep (its screen was on and it was plugged in the whole time).

So the “force stopped” explanation does not apply here, Doze Mode does not apply here.

Besides, speaking of “force stopped”, I’ve done several tests, running then deliberately closing either (GCM or FCM) app from the “recent apps list”, verifying that the process was getting killed (via the logcat) and then either (GCM or FCM) push messages would go through just fine.

So it has to be something else (not “force stopped” or Doze Mode) and this something else is causing push messaging to become unreliable, which defeats the purpose.

Any ideas on how to track this down, to prevent / avoid this sudden breakage of push message delivery?

The GCM sample’s manifest:

https://github.com/googlesamples/google-services/blob/master/android/gcm/app/src/main/AndroidManifest.xml

The FCM test’s manifest:

“`xml

<application
    android:allowBackup="true"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:supportsRtl="true"
    android:theme="@style/AppTheme">
    <activity android:name=".MainActivity">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />

            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>

    <service android:name=".MyFirebaseMessagingService">
        <intent-filter>
            <action android:name="com.google.firebase.MESSAGING_EVENT" />
        </intent-filter>
    </service>


    <service android:name=".MyFirebaseInstanceIDService">
        <intent-filter>
            <action android:name="com.google.firebase.INSTANCE_ID_EVENT" />
        </intent-filter>
    </service>
</application>

“`

How to&Answers:

My conclusion is:

This is caused by Android Studio.

When you’re done working on a project for the day, and quit AS, it asks if the app (being debugged) should be terminated.

No matter what you select here, AS will always terminate the app and put it into a “stopped” state — not just GCM, alarms stop firing as well.

I see this happen all the time, and made it a habit to restart the app myself and do something there so it doesn’t say “stopped” and doesn’t surprise me (“what happened”) the next day.

Thought I had filed a bug for this, but can’t find it now. If anyone is interested, feel free…