Pushbullet Logo

Debugging Issues with Pushbullet and Google Play Services

Background

I’m posting this because every day there’s a new post on /r/pushbullet about people not getting their Pushbullet messages until they open the Pushbullet app.  There’s a number of reasons that this issue can arise, some of them are unrelated to Pushbullet itself, but will cause the symptoms, some are related to Pushbullet though no definitive answer has been found for this yet.  This article will help you to diagnose issues unrelated to Pushbullet – if following the steps and suggestions don’t help then escalating to Pushbullet’s support would be a good next step.

To kick off this article, I’ll explain briefly how push notifications work for most applications, but not all on Android.  Almost every Android phone out there has Google Play Services installed.  This “App” is pre-installed on your phone and is the support library that all Google Apps and many others rely on.  One of it’s many jobs is to provide the “Google Cloud Messaging” (GCM) service.

2019 update.  GCM is now FCM (Firebase Cloud Messaging) but I’m not going to update this blog post to change it all, it’s still the same basic thing.

This, very simply, allows a server/service hosted somewhere to send a message to Google, and Google will then, using GCM, push a message to the user’s phone.

The reason that GCM is so useful is that apps can register with it when they’re installed.  This means that each app doesn’t have to have it’s own network/infrastructure for pushing messages to your phone, but rather there is a single push service on your phone that all apps can use.  This helps with battery life and means that App developers can focus on writing apps, not having to also host and maintain a network dedicated to pushing messages to phones. It also means your phone only has to have one network connection open to get push messages, instead of each app having to keep a network connection open, which is a drain on resources and battery life.

The Problem

Now the problem comes about with Pushbullet when it doesn’t get messages from GCM.  These messages should “Wake it up” so that you instantly get the push on your phone.

But if Pushbullet doesn’t get the GCM notification, it has no idea that anything new has happened.  It only realises when you open the app and it Sets up it’s own connection to the Pushbullet Servers and gets the latest notifications.  In fact, that’s all a GCM message is, a message to say “Hey, wake up and check your server for the message waiting for you, Pushbullet”.

So if this isn’t working for you, there’s a few things you can do to debug (and hopefully resolve) the issues so that your Pushbullet app starts working as you expect.  Depending on the problem, you might find other apps you didn’t even realise were lagging seem to be a lot faster too!

Debugging Google Play Services

Thankfully, Google have included a way to find out the status of Google Play Services and whether or not it has an active connection to the GCM services.  Type the following code into your dialer and you’ll open up the Google Play Services status page:

Dialer Debug Code
*#*#426#*#*

You will open up a screen that looks like this:

GCM Connected

GCM Connected

Notice the following things about this image:

Device ID: The Device ID that Google has assigned your device.
Connected: This is the key we’re looking for! We want to see that it says connected and a lot of information about how it’s connected.

This is what a bad/broken/non-working GCM screen looks like:

GCM Disconnected

GCM Disconnected

What follows is a list of  reasons (and some workarounds/fixes) as to why Google Play Services might not have a connection…

Why doesn’t it work?

IPv6 is enabled. For me, IPv6 works fine. But for a lot if people, if their router/WiFi is giving them an IPv6 connection, but it’s not properly routed, then it won’t work. But for reasons unknown, Google will keep trying to use the IPv6 connection, even though it’s broken. Sadly on Android the only way to disable IPv6 is via root methods, there is no simple way for a non-rooted person to do it. The best option if you’re not rooted is to disable the router/WiFi you’re connected to from giving you an IPv6 address. Of course if you’re at work etc then getting the IT people to do this is probably an impossible task.

The GCM Ports are Firewalled. This is less likely, but certainly possible if your work environment only allows port 80/443 out.  GCM uses TCP Port 5228 (The standard Jabber Port!), but it can also sometimes use TCP Port 5229 and 5230.  If these ports are blocked, you won’t get a stable GCM connection.

Your Firewall has dumb sessions timeout. I’m not sure how valid this one is with later versions of GCM, but if you have a firewall that times out TCP sessions after 5 minutes, you could well have issues with GCM which only sends keepalives every ~29 minutes (This is not confirmed yet).

The Fixes

Use Mobile data (disable WiFi).

Annoying, but great as a quick workaround to see if it fixes the problem.

Run a VPN.

This is what I did at a place of employment where IPv6 was broken. The VPN gives your phone a IPv4 only address and Google Play Services will connect via it and work fine.

Is GCM not the issue?

If you’ve looked at the above but you’re finding that you’re still missing push messages, one “fix” is to uninstall and re-install Pushbullet.  Why this is required is still under investigated by the PB devs.  A way to test if only Pushbullet is affected is to get someone to send you a test Google Hangouts message, or to send yourself a Gmail (has to be Gmail, not an IMAP account).  These both notify your phone of a new message by using GCM.  If you’re getting Gmail/Hangouts notifications instantly with no delay, but getting delays with Pushbullet, then the issue isn’t GCM and something else is wrong.  Might be time to contact the PB Devs and see if there’s any information you can give them to help debug the issue.

Good luck!

2 thoughts on “Debugging Issues with Pushbullet and Google Play Services

  1. jetten

    Though I would (on this 4 year old article) share some of my experience with debugging FCM notifications from the last two years.

    Usually when GCM breaks because of IPv6, it’s not because of a broken IPv6 connection at the router/ISP, but caused by buggy firmware on the phone WiFi chip. When the phone goes into sleep, the Wifi chip is supposed to wake the phone when it receives IPv6 RA packets in order to renew its IPv6 address/route, but because of the buggy firmware this does not happen so the phone will lose its IPv6 connectivity after some time in sleep. This issue is probably fixed on most newer phones, but if interested more information about this can be found in Android’s issuetracker: https://issuetracker.google.com/issues/36949115

    About 1 year ago I also had a really strange issue with GCM that seemed to be specific to my mobile carrier (TELIA FI). The GCM connection seemed to work just fine for the first 30 minutes or so, but after 29 minutes of inactivity, as GCM tried to send the heartbeat to keep the connection alive, it would get stuck in Alarm state and was not able to refresh the connection until I toggled Airplane mode to force the connection to refresh. I say strange issue, because GCM worked perfectly with any other connection such as Wifi, VPN, or even when roaming abroad using another carrier. So you would draw the conclusion that it must have been a carrier issue, but on the other hand how can a such major carrier have such issues for ~2 months without anyone else noticing?

    Also these days GCM should work fine on connections with “dumb session timeouts” as it seems Google is able to determine the timeout on each network you are using, and adjust the heartbeat interval accordingly.

    I found this article when searching for people having issues with delayed notifications from Facebook messenger specifically. I came to the conclusion that it’s not GCM that is the issue in this case. The crappy FB messenger app indeed receives the notification from Google Play immediately, but somebody decided that the app needs to do some processing before it can show the notification, and if power optimizations is enabled on the phone this processing may not happen immediately.

    Reply
    1. Tim H Post author

      Thank you for your detailed and well written reply! I wasn’t aware of that firmware bug, so thank you very much for bringing it to my attention.

      As for the 29 minute thing, that does sound like a problem with your carrier and some sort of stateful firewall disgarding the session before it was supposed to, or before at least FCM was expecting it. You’re right though, I thought Google did some backend work to “figure out” what times carriers were using, but I don’t know the actual mechanism for that.

      But again, thank you for taking the time to write this up and post it for others. I really appreciate it.

      Kind Regards,
      Tim

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *