3

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.

Roee G
  • 31
  • 2
  • Using GCM (the older version) also means that previous bugs (whatever they are) may still occur (which could be causing this unexpected behavior). I'm not saying upgrading to FCM would definitely fix this, but FCM contains the bug fixes that were occurring in GCM. – AL. Jul 05 '17 at 13:18
  • Also, it may be a long shot, but could you post your code for `onTokenRefresh()` as well? – AL. Jul 05 '17 at 13:20
  • Thanks @AL. We are testing migration to FCM but this doesn't feel like it would solve our issue. I expect GCM to stay in production and keep working for the time being. – Roee G Jul 05 '17 at 19:16
  • 1
    Our `onTokenRefresh()` code is wrapped quite good with Rx and other abstractions, but bottom line is the callback starts another intent service and the service itself invokes `InstanceID.getInstance(mAppContext).getToken(OurAppGcmSenderId, GoogleCloudMessaging.INSTANCE_ID_SCOPE);` But I can guarantee we refresh and save the tokens. We stop sending notifications to expired devices (so they are not part of the funnel) and we are not getting back any canonical IDs from GCM to update so we're using valid tokens. – Roee G Jul 05 '17 at 19:28
  • I see. Then are yiubat least seeing a patter where this occurs (OS version, device model, etc)? It might be worth looking into those details. Is your app on prod for quite sometime? If yes, did this behavior just occur recently? Were there any recent changes related to GCM prior to that changes? (Sorry if the multiple questions is annoying) With that, if you're still unable to pinpoint it out, I suggest reaching out to GCM support directly. Cheers! – AL. Jul 06 '17 at 00:38
  • 1
    That's fine @AL. I appreciate any suggestion or direction. We're in production for around 2 years and this issue started around February-March 2017. We're seeing it happening for both Android M & N, but the drop is bigger for N. And we can find sense in that since Android N started rolling out to most US carriers around February-March. Haven't managed to correlate it with a specific device vendor or model. And no, no change to our GCM code lately :-( – Roee G Jul 06 '17 at 08:04
  • Also, we couldn't find evidence for increased uninstalls (according to Google Play console stats). Any chance Android N force stops apps that are not in frequent use? Any other battery optimization apps that can do that to other apps? – Roee G Jul 06 '17 at 08:06

0 Answers0