GCM wake-up is considered to be one of the most unreliable feature among the experimental features, thus still stuck as donation-only.
There're many factors behind a working GCM push, and trouble with either may lead to the failure of the whole expectation.
Let's discuss the common misunderstandings first.
Now if you believe your app failed to wake up by a GCM push, follow these instructions to find the cause:
1. Open and monitor the logcat (Android log system), either on a USB-connected computer, or on your device with tool app like CatLog.
2. Set the filter to only include keyword (or tag) "GCM".
3. Let's trigger an expected GCM push (by sending an instant message from another device or so). You will soon read a line like this in logcat upon the arrival of GCM push:
This means Google Play services received the GCM message from Google's server and ready to deliver it to the corresponding app (indicated by the package name in the line, com.joaomgcd.autoremote in the example). If you cannot find this line in a reasonable time span, then it may be that app which lose the registion to GCM. Try logout and login your account, or clear the data of the app, or even uninstall and re-install it to restore its registration to GCM.
In all good situation, you should now receive the notification. If not, read on.
4. If the target app is hibernated before the arrive of GCM push and you have activated "GCM Wake-up" feature, then open Greenify ASAP (since it may hibernate again in a few minutes).
You will probably find that app is awake and listed in the "WILL HIBERNATE..." section. In this case, Greenify had managed to wake up the hibernated app and deliver the GCM message to it, but that app may failed to process it correctly and show a notification. This does happen to some apps which can't deal with GCM message upon wake-up. Try trigger another GCM push manually, if the notification shows up this time, that app falls into this category. It's hard to blame the developers for that, since they may not prepare for the arrival of GCM push when their background service is not running. So I'm still trying to figure out a better solution to make "GCM Wake-up" compatible with these apps.
5. If the app still stays hibernated, then the wake-up attempt might fail.
Back to the logcat, you probably read another line like this:
It means the push is not delivered successfully. If you did activated "GCM Wake-up" but still read this line, then it may be Greenify's fault, except if you have disabled the notification of that app in system Settings - Apps - That App - Show notifications (unticked). Greenify checks this setting before trying to wake-up an app to deliver GCM push.
Note: As a reference, try "AutoRemoteLite" with its web interface to trigger GCM push.
There're many factors behind a working GCM push, and trouble with either may lead to the failure of the whole expectation.
Let's discuss the common misunderstandings first.
1. The GCM indicator in App Analyzer does not necessarily mean the app uses GCM for the very notification feature you are expecting.
The GCM indicator only means GCM-related code is in that app's package. But the app may use GCM only for some of its notifications, or only in some criterias, or even the worse, does not use at all. To find out the actual usage of GCM within an app, read the trouble shooting instructions below.
2. Not all notifications are backed by GCM push.
Most instant messaging apps and some social apps use hybrid implementation with GCM and persistent connection (in a background service) to deliver more reliable instant notification, than relying on GCM only. In this case, some of the notifications you have received may not even come from a GCM push.
Hiberated apps lose its background service and thus fall-back to a GCM-only solution, effectively reducing the reliability of notification. If you noticed obvious delay or loss of some notifications after greenifying, it's probably the case.
3. The latency of GCM is affected by many factors, most notably how your carrier restrict the persistent connection.
The foundation implementation of GCM itself is also a persistent connection to Google's server. That means if your devices failed to keep this persistent connection, the latency of GCM is out of control. Carriers all over the world do restrict persistent connection to preserve their limited capability of signalling resources (not the bandwidth), by dropping connections idle for a while. GCM use periodic heartbeat packets to keep the persistent connection, but the default interval of 28 minutes for mobile network is far beyond the connection dropping threshold of some carriers (varying from minutes to hours), causing the persistent connection to drop frequently. As a result, GCM push may delay in minutes, or even half an hour. There's also a few carriers in the world even block the connections to Google's server in most time(China for example), causing GCM totally out of work.
To reduce latency caused by carrier restriction on persistent connection, try "Push Notification Fixer".
Now if you believe your app failed to wake up by a GCM push, follow these instructions to find the cause:
1. Open and monitor the logcat (Android log system), either on a USB-connected computer, or on your device with tool app like CatLog.
2. Set the filter to only include keyword (or tag) "GCM".
3. Let's trigger an expected GCM push (by sending an instant message from another device or so). You will soon read a line like this in logcat upon the arrival of GCM push:
Code:
I/GCM﹕ GCM message com.joaomgcd.autoremote 0:1426418730738334%0#02db4288f9fd7ecd
In all good situation, you should now receive the notification. If not, read on.
4. If the target app is hibernated before the arrive of GCM push and you have activated "GCM Wake-up" feature, then open Greenify ASAP (since it may hibernate again in a few minutes).
You will probably find that app is awake and listed in the "WILL HIBERNATE..." section. In this case, Greenify had managed to wake up the hibernated app and deliver the GCM message to it, but that app may failed to process it correctly and show a notification. This does happen to some apps which can't deal with GCM message upon wake-up. Try trigger another GCM push manually, if the notification shows up this time, that app falls into this category. It's hard to blame the developers for that, since they may not prepare for the arrival of GCM push when their background service is not running. So I'm still trying to figure out a better solution to make "GCM Wake-up" compatible with these apps.
5. If the app still stays hibernated, then the wake-up attempt might fail.
Back to the logcat, you probably read another line like this:
Code:
W/GCM-DMM﹕ broadcast intent callback: result=CANCELLED forIntent { act=com.google.android.c2dm.intent.RECEIVE pkg=com.joaomgcd.autoremote (has extras) }
Note: As a reference, try "AutoRemoteLite" with its web interface to trigger GCM push.
Last edited: