GCM notifications stop arriving after a few weeks

[Roee Greenberg]

We have an Android app we use to send content (tech articles, walk-through guides, etc.) to our users using GCM. We're monitoring the sending at two points using a REST call to some service:

1. Immediately after our servers send a notification.
   
2. Immediately once our app receives it.
   

What interests us is the ratio of how many notifications reached the app out of those that were sent. Recently we noticed that starting March 2017 it looks like less notifications are reported as received and this ratio dropped. Obviously our primary concern is that notifications are simply not reaching the Android devices.

A few notes:

• We send a notification once every 7 days on average.
  
• Other than opening the notifications and reading the content that, it is most likely that the majority of our users won't use or launch the app on a regular basis.
  
• It looks like this drop started with the rolling out of Android N and is becoming more significant after the first two weeks since the app was first installed. Meaning comparing Android M to N, at the first two weeks both OS versions have the same ratio for received notifications but after that Android N's ratio drops more quickly.

At first we thought users are "blocking all notifications" for our app (easier to do on Android N) but using NotificationManagerCompat.areNotificationsEnabled() we found out this is not the case.
We then tested our app behavior under Doze and Standby modes but we couldn't find evidence that they are the cause for our issues.

Some technical info:

• We use GCM (not FCM). We use data type notifications with normal priority, and we're displaying the notification in the notifications tray manually.
  
• We use PushSharp to send the notifications from our servers. If we get a “Device subscription has expired” we’ll no longer send notifications to that device.
  
• On our Android app we’ve implemented the GCM token refresh according to Google’s guidelines.
• Our GcmBroadcastReceiver is a WakefulBroadcastReceiver that uses startWakefulService to start a GcmIntentService when receiving a notification intent.
• The GcmIntentService handles the notification intent (and among other stuff makes the monitoring REST call I mentioned above) and once done calls GcmBroadcastReceiver.completeWakefulIntent.
  

Not sharing code as it's very straight forward, will be happy to share if relevant.
I'll appreciate any insights or ideas someone can share.

[Diego Giorgini]

Hi Roee,

thanks for your report.

I suggest that you collect few message-id of messages that your system report has not being delivered, and communicate them to us via a Firebase support ticket.

In this way we can check if we have more insights on what happened to those messages.

Apart from that, these are other general advises:

1. are you setting priority: high ? if that is not set the message is not delivered while the device is in doze, this could delay the message or even expire it (if you set an aggressive TTL).

2. even when you set priority: high, if the device is in doze your app has only 10 seconds to access the network.
It's possible that the upload of the event "notification received" cannot complete in time.  It would be great if you could save that event in a file, and schedule a JobScheduler task to upload the event to your tracking system later.

3 did you notice differences between specific devices ?

Regarding your technical info, those look ok. Just few notes:

- in order to support Android O I strongly recommend to adopt the classes / api / callback provided by the latest GCM or FCM sdk. (= don't reimplement the receiver yourself) 

- independently from your approach, in android O you cannot use startService() anymore. If you need to perform a long task you need to schedule a JobScheduler task.

--
You received this message because you are subscribed to the Google Groups "android-gcm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-gcm...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-gcm/97158276-8555-444b-9e7a-cc81ec41be65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roee Greenberg]

Hi Diego

Thanks for the prompt reply!

Regarding the collection of message IDs, we actually tried using FCM diagnostics on the Google Play console to track some messages but the thing is that it's hard for us looking at a few random messages and from whatever we discover to assume statistically that this is indeed our issue for the rest of the users. Take for example the Galaxy Note 7 that Samsung shutdown using an OTA update - these devices simply "disappeared" so checking one of these won't help us understand our issue. Am I making sense?

We couldn't find it, but perhaps there's an API we can use to query each message for its GCM status and by that reach a more accurate result?

As for the other suggestions:

1) We only send "data" notifications and use its default "normal" priority. We haven't try sending "high" ones yet (actually we're "afraid" of Google's ML and being flagged in some way).

2) We use the default TTL (4 weeks if I'm not mistaken) and we're actually using android-priority-jobqueue to persist the "notification received" event until the network request succeed.

3) We experience this drop in the majority of vendors and models... nothing specific.

And thanks for the heads up for Android O and the JobScheduler. We actually just finished replacing our WakefulBroadcastReceiver implementation with the described here, hoping it'll help us with the issue.

But another question - our app references 'com.google.android.gms:play-services-gcm:9.6.1'. Any chance upgrading to 11.0.2 can help with what we're seeing?

I did see Android O requires version 10 and above so I'll guess we'll have to upgrade no matter what.

[Diego Giorgini]

On Thu, Jul 6, 2017 at 1:32 PM Roee Greenberg <ro...@soluto.com> wrote:

Hi Diego

Thanks for the prompt reply!

Regarding the collection of message IDs, we actually tried using FCM diagnostics on the Google Play console to track some messages but the thing is that it's hard for us looking at a few random messages and from whatever we discover to assume statistically that this is indeed our issue for the rest of the users. Take for example the Galaxy Note 7 that Samsung shutdown using an OTA update - these devices simply "disappeared" so checking one of these won't help us understand our issue. Am I making sense?

Agree.

Just sometimes you get lucky and you hit 6 out of 10 devices with some common pattern.

 

We couldn't find it, but perhaps there's an API we can use to query each message for its GCM status and by that reach a more accurate result?

There is no such API.

If you want to open a ticket with Firebase Support, we can dedicate some time to check if we spot any patter. But we will be doing a job similar to what you did on FCM diagnostic.

 

As for the other suggestions:

1) We only send "data" notifications and use its default "normal" priority. We haven't try sending "high" ones yet (actually we're "afraid" of Google's ML and being flagged in some way).

You should definitely not abuse it with frequent, not actually urgent, messages.

On the other side if your messages need to be displayed now, and they have a low / medium frequency you can use priority high.

I would suggest to give it a try to see if there is any change.

 

2) We use the default TTL (4 weeks if I'm not mistaken) and we're actually using android-priority-jobqueue to persist the "notification received" event until the network request succeed.

3) We experience this drop in the majority of vendors and models... nothing specific.

And thanks for the heads up for Android O and the JobScheduler. We actually just finished replacing our WakefulBroadcastReceiver implementation with the described here, hoping it'll help us with the issue.

yes. that is the correct approach.

 

But another question - our app references 'com.google.android.gms:play-services-gcm:9.6.1'. Any chance upgrading to 11.0.2 can help with what we're seeing?

I did see Android O requires version 10 and above so I'll guess we'll have to upgrade no matter what.

I doubt. GCM library is fairly stable and it receives only minor fixes (except for the Android-O compatibility which is a significant change,  but that will not impact you unless you use targetSdk = 26)

 

To view this discussion on the web visit https://groups.google.com/d/msgid/android-gcm/16c4b4ba-2713-437d-968d-82a22261229f%40googlegroups.com.

[Massimiliano]

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
LOAN DEAL
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA
UNIONPAY RECEIVER

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP
+44 7529 555638