Google Cloud Messaging - messages sometimes not received until network state changed

Question

While working on a little project that integrates with GCM, I've stumbled across a bit of a strange issue.

Some times when I start watching the log to see if messages are received, messages do not appear to be coming through until I have changed the network state (I.E. originally on WiFi, if I turn off WiFi and move to Mobile Data, the messages arrive fine). After I've changed the network state, messages start to arrive perfectly fine, and the same applies once I change the network state back to what it was before (in this case, WiFi) the messages continue to be received.

The project itself includes the ability to start on boot (starts the GCMBaseIntentService on boot), which again works perfectly fine, and I'm sure the app / service is running as I've manually started up the app when this issue occurs (which also checks to see if the service is running, and if it's not it runs it and checks to see if it's registered).

Has anyone else come across this issue, or has any pointers as to how I could resolve this? I'm not seeing anything of much help in the log between the time messages are not being received and when they are (after changing the network state). I've gone through the GCM docs and can't see any mention of messages not being received due to a time-out (on the device itself), or any config options that might affect this.

Appreciate any assistance - I can provide source if needs be, although it hardly deviates from the demo app provided in the android-sdk.

Yes, I see similar, as do others. Receipt is instant when wifi on, variable delay via 3g. Switching airplane mode on, then off makes messages appear. I added a comment in the Google developer group (which I can't find at the moment!). My device is a Samsung Galaxy S2 — NickT, Dec 12 '12 at 09:53
Thanks - I understand that there will be a slight delay with 3G compared to WiFi, but my point is that messages are not arriving at all sometimes..however when I toggle the network (i.e. from wifi to 3G or vice-versa) messages start appearing again. I'd appreciate the link to the comment / topic you posted on for reference :) Thanks p.s. I'm also on a Galaxy S2. — Seidr, Dec 12 '12 at 09:57
Hi The link is https://groups.google.com/forum/?fromgroups=#!topic/android-gcm/bsYumo68fsc. My phone is with O2. I always get the messages eventually but it can take 30 minutes max. I have a strong (usually H+) signal here in London. — NickT, Dec 12 '12 at 12:24
Fantastic, cheers. I ran into a couple of similar posts on Google Groups while searching, but none with a solution. I'll have to check to see whether I eventually get messages or not later today. I'm just south of London (Dartford area), and usually have pretty strong H+, or office WiFi (where the issue most often occurs). Thanks for your input - I'll update if I find any kind of solution :) — Seidr, Dec 12 '12 at 14:06
Problem is now much worse since phone 'upgraded' to Jellybean from ICS. (Also I've moved from London to Liverpool) — NickT, May 16 '13 at 06:51
I don't believe the accepted answer is always the case. I can reproduce the problem on a handful of devices at the office where we have a reliable WiFi and HSDPA connection. Reconnecting WiFi _always_ delivers the push messages, and any subsequent message doesn't arrive until reconnecting again. Can you provide a little insight into your project's setup? Is it a library project? Does your app invoke GCM handling from a library project? Under which circumstances does your app register on GCM, and does it ever unregister? — Paul Lammertsma, Sep 09 '13 at 10:04
I know this post is really old, but just confirming that I too am encountering exactly the issue you describe with GCM. It occurs on some devices with long running applications after a week or two without device reboot. It seems to be system-wide: other apps also stop receiving push notifications. An on/off toggle of WiFi results in push notifications being delivered again. So maybe a solution is to periodically toggle WiFi programatically. — Michael Pedersen, Dec 15 '15 at 06:51

score 39 · Accepted Answer · answered Feb 13 '13 at 18:49

I've noticed this as well. Although I haven't dug into the actual code, here's my understanding of why this happens.

GCM (and most push messaging services) works by keeping a long-lived socket open to Google's push notification server. The socket is kept open by sending "heartbeat" messages between the phone and server.

Occasionally, the network state may change and this socket will be broken (because the IP address of the device changes, from 3g to wifi, for example). If the message comes in before the socket is reestablished, then the device will not immediately get the message.

The reconnection only happens when the phone notices the socket is broken, which only happens when it tries to send a heartbeat message.

Again, just my basic understanding of how it works and why it happens, and I could be wrong.

Accepted your answer, due to the fact there doesn't appear to be a solution for this at present, but your answer best describes the root of the issue. — Seidr, May 23 '13 at 07:33
you got the point, GCM does not handle well a tcp timeout, see more: http://stackoverflow.com/questions/16749038/google-cloud-messaging-messages-either-received-instantly-or-with-long-delay/18428357#18428357 — andQlimax, Mar 12 '14 at 11:18

score 21 · Answer 2 · answered Dec 16 '13 at 20:14

21

There are many causes for GCM message delays. If message start to arrive after you changed network state, or switched on/off airplane mode - the most likely cause is a network that closes the connection without sending FIN/RST.

GCM maintains a long-lived connection - and reconnects if it knows the connection was broken. A router/AP/NAT is supposed to send a FIN or RST to terminate the TCP connection - so GCM and servers will know the connection is dead.

However a number of routers and mobile operators don't do this, and then GCM needs to rely on the heartbeat, ~15 min on Wifi, more on mobile. There is a trade-off between battery life/network use and heartbeat frequency.

answered Dec 16 '13 at 20:14

Costin Manolache

481
4
5

Nice technical expansion on the actual cause for this. – Seidr Jan 16 '14 at 13:42
`GCM maintains a long-lived connection - and reconnects if it knows the connection was broken.` → Not sure if this explanation is correct. Even if GCM servers determined that connection was broken, here is no way to initiate new connection from servers. Because client device usually placed behind NAT and don't have global white IP address. Only client able to initiate new connection. So only thing that we can do is just wait for new heartbeat packet to approve new connection and keep it alive. – rzlvmp Sep 08 '21 at 01:57

score 1 · Answer 3 · answered Feb 12 '13 at 16:44

As per your comment in above answer and according to my experience with GCM push notifications there isn't any reason that if network(internet connection) is available you should not receive push notifications I always check internet connection availability before running the application for push notification like this try checking this if this is true you should receive push notifications

    private boolean isNetworkAvailable() {
    ConnectivityManager connectivityManager 
          = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo activeNetworkInfo = connectivityManager.getActiveNetworkInfo();
    return activeNetworkInfo != null;
}

score 0 · Answer 4 · answered Nov 07 '14 at 17:37

so, If @theelfismike thinking is true, may I use something like:

  ConnectivityManager cm = (ConnectivityManager) context
            .getSystemService(Context.CONNECTIVITY_SERVICE);

    NetworkInfo activeNetwork = cm.getActiveNetworkInfo();
    if (null != activeNetwork) {
        if(activeNetwork.getType() == ConnectivityManager.TYPE_WIFI)
           // here the network changed to Wifi so I can send a heartbeat to GCM to keep connection

        if(activeNetwork.getType() == ConnectivityManager.TYPE_MOBILE)
          //here the network changed to mobileData so I can send a heartbeat to GCM to keep connection
    }

is my solution good?

Unnecessary, GCM does this autonomously – Tim Sep 12 '16 at 09:45 — Tim, Sep 12 '16 at 09:45

score -4 · Answer 5 · answered Feb 09 '13 at 08:43

in the GCMIntentSevice class ,when you receive message from server ,onMessage method gets called so at that time you can do something like...

PowerManager pm = (PowerManager) getApplicationContext()
                .getSystemService(Context.POWER_SERVICE);
        WakeLock wakeLock = pm.newWakeLock(
                        (PowerManager.SCREEN_BRIGHT_WAKE_LOCK
                                | PowerManager.FULL_WAKE_LOCK | PowerManager.ACQUIRE_CAUSES_WAKEUP),"TAG");
        wakeLock.acquire();

and you have to add

<uses-permission android:name="android.permission.WAKE_LOCK" /> permission in you manifest file..

this should do the trick...

Thank you for your answer, however the alive state is not the issue here. I believe it's to do with the long-lived connection being lost, and not re-created in a timely fashion. — Seidr, Feb 12 '13 at 08:27

Google Cloud Messaging - messages sometimes not received until network state changed

5 Answers5

Linked

Related