I created an Android app that can receive push notifications. I've installed the app on two different phones and verified that both can receive GCM push notifications. This test was done in the United States.
The following week, one of the phones traveled to Asia. But push notification could not be received on the phone in Asia. It had internet access but could not receive push notification.
Does anyone know why? Does there need to be special configuration. Can network block GCM messages?
It must be blocked by the country. e.g. google is blocked in China.
Do other google services work on the device.
If you tried your application in Asian phones, surly it will work. or else You can change your location by changing IMEI number based on the country.
In developing countries, some telecom networks / home routers will aggressively disconnect idle TCP connections to save resources, preventing your GCM/FCM notifications from arriving on time.
FCM uses a heartbeat mechanism to keep its connection alive, by sending a "keepalive" packet every X minutes to the FCM servers. However, the heartbeat intervals used by FCM do not take into account aggressive networks in developing countries which will terminate idle connections.
This makes GCM/FCM quite unreliable in such developing regions:
https://eladnava.com/google-cloud-messaging-extremely-unreliable/
As per China, GCM/FCM are blocked entirely by the Great Firewall of China.
As a workaround, check out Pushy which uses a fine-tuned MQTT connection with a faster heartbeat interval to prevent the connection from being terminated, and is not blocked in China.
Full disclosure - I founded Pushy.
Related
On my device using wifi network sometimes I have to refresh internet connection to receive notifications.I have set time_to_live = 5 to receive instant notifications only. It seems that connection of device with gcm servers is broken some times. But as soon as I refresh wifi internet, notifications start to come properly. This is strange and practically unreliable because I have to refresh internet connection again and again to receive notifications. Please help in this regard! Thanks in advance.
I have read about this same problem in Products Forum - Push notifications delayed, Hearbeat Interval not reliable. According to the old thread:
Android push notifications works through one TCP connection on the port 5228 between the phone and google servers. This connection is established when the phone connect to a network. All android push apps (gmail, whatsapp, hangouts, etc.) use Google Cloud Messaging (GCM) to send and receive push notifications thought that connection.
By definition a TCP connection does not have a timeout. But in the real world, wifi routers and mobile carriers have some rules to limit the number of opened tcp connections. So they usually close/kill what they think to be an inactive connection after some times that no packets are transmitted. For example my wifi router kill connections after 300 seconds (5 minutes) of inactivity (no packets on the tcp connection).
Then, it was given in this Google thread - Delay in getting GCM notification that this particular case is not a bug with GCM, rather it is an over-zealous router.
To fix it:
We found we could keep the connection alive with a ping every two minutes from the GCM server (which is free). There may be battery life implications for the device as I suspect the 15 minute timer that triggers the cooee is the same one you are supposed to align internal alarms with to minimize battery use.
Along with my searches, I also found this SO post - Do not receive GCM message while android device bein connected to WIFI which suggests upgrading to FCM as one that solved the issue and maybe it will work for you too.
I have an android app that uses GCM for push notifications. Lets say I need this for ambulance drivers when new calls are received. Right now there is a delay between when the server sends out the push notification and when the android device receives it, sometimes more than a minute. I've read on Stack Overflow about sending the heartbeat out, set delay_while_idle to true/false( yes I've seen both) etc...
What I need to know is if this is just how it is with GCM or if there is a way to make push notification times much more reliable. I've had suggestions of sockets, test messages etc... Because this is potentially for medical services I can't afford to have delays longer than what is absolutely necessary.
I've read that GCM notification delivery isn't guaranteed so is there a direction someone can point me to maybe do this on my own so that I can make something is guaranteed???
GCM push notifications are not reliable.
Have a look at "Pushy": https://pushy.me/
They state the following on their website:
The most reliable push notification gateway, perfect for real-time
applications.
Google Cloud Messaging simply doesn't cut it for time-sensitive,
real-time apps, due to its instability and push notification
throttling.
Pushy works by maintaining a dedicated background socket connection
using the MQTT protocol, an extremely light-weight pub/sub protocol
that consumes very little network bandwidth and battery, which makes
it perfect for mobile.
You can use it for free with up to 100 devices, so you could just give it a try to see, if it fits your needs. I didn't try it.
I successfully integrated my app for receiving push notification using GCM. Its working correctly, I just saw a strange behavior while receiving push notification on one of my android set which is using my wifi network, in the same time others whose are using EDGE or 3G network are receiving notifications correctly. When I try to switch off and switch on the wifi, it receives the pending notification.
I tried opening the ports which normally used by GCM i.e 5228,5229 and 5230 in my router's firewall however with no success.
NB: After seeing this, I tried to configure the app for Parse API and its working as same as GCM so I think it depends upon the network packet receiving or something.
I believe, what you're facing is a known issue about TCP connection between GCM servers and your handset is timing out because of inactivity. Network devices (like your Wi-Fi router, your ISP hardware, etc.) between your handset and GCM servers could kill the TCP connection if no packets are sent every now and then.
There are some workarounds for this which you might try. For example, there are apps on Google Play that modify the default Android behavior and make it update this connection more often, increasing chances that it will not timeout. You could try them and see if it fixes the problem for you.
I implemented push notification system and I noticed that push messages do not ever come when I am on 3G or 4G (mobile Internet).
When I connect to wifi, they come regularly.
Is this behavior bound to Android OS or we can write a code to change it?
I implemented Parse.com 3rd party library. Regardless of myself, I noticed that push messages from other apps do not come unless I am connected to wifi.
If you see the same behavior with stuff from Google (Gmail, Google Play app updates, etc.), then the problem lies with your phone or carrier. If the Google stuff works (they use what amounts to GCM), then your problem lies with Parse.com and whatever the other apps are using for push.
GCM (and the C2DM precursor) work over mobile data or WiFi. It is a bit tricky to implement a push system as a third-party library, which is why I recommend firmware solutions (GCM, Amazon's just-announced Kindle Fire equivalent, etc.). In particular, maintaining a mobile data connection to the push server, with enough heartbeats to keep the connection alive without really draining the battery, is difficult to get right, particularly given subtle mobile carrier or device variations. Google has more experience with this than do most firms, and Amazon only has to worry about a handful of Kindle Fire models.
I am having issues with C2DM. Sometimes works perfectly, sometimes my messages simply do not get pushed. Is there reliable way to enforce this connection? To pull messages. I read somewhere that what google do is keep low bandwidth TCP connection to their server at all time. So I assume that
when switching between network types TCP connection falls down and Android tries to reestablish connection to C2DM servers. So that might fail on WiFi with restricted network. Is that wrong assumption?
I have noticed with WhatsApp that on WiFi sometimes I do not get messages. When I switch to 3G I usually get them at the moment of the switch. What tips from your experience with C2DM would you offer?
C2DM is not suitable for critical parts of your application, since Google currently does not offer an SLA or paid tiers that will guarantee you reliable service and throughput.
I've considered several alternatives myself: XMPP via asmack, Parse, Deacon, Urban Airship, and MQTT.
After some reading and experimenting I decided to go with MQTT. It is a very lightweight telemetry protocol invented at IBM that fits quite nicely in the Android push notifications scenario. I recommend you give it a try, here's a nice blog post to guide you: Using MQTT in Android mobile applications.
Hope this helps.
C2DM does not guarantee that your message will be delivered, and your application should not assume that in order to work correctly. Therefore, your C2DM message should never contain the data itself but, rather, a notification that there is data available. In other words, the loss of a C2DM message should never cause your application to lose data; it should, at most, cause it to take longer to notice that a certain piece of data is available on your server.
A typical app should connect to its server once in a while (a long while) to retrieve messages, even when using C2DM, to cover the case where C2DM messages might not be delivered.
Depending on network configuration, the device might not be able to receive C2DM messages; restrictive firewalls or other strange WiFi configs might do that.
With C2DM reliability is not a guarantee. So best to have a ACK
message or some way in which you (the sender) the realize the message was received successfully.
Also make it a point to override onRegister class properly because the device Reg ID keep on shuffling.
Lastly, if you are planning to send updates regularly, I'd prefer polling to C2DM just because of the amount of requirements to get it functioning while reliability and ultimate control is still not assured.
I've been struggling with the same problem myself. The behaviour you describe is accurate. I'm developing an app that uses c2dm mainly with Wifi connection, and I had to implement an AsyncTask to periodically (minute and a half) call WifiManager.reassociate() (turning wifi off and on again triggers the arrival of all pending notifications, that's what inspired this solution) so I can keep the notification arrival as accurate as possible. Not so sure about the correctness of this practice, though.
Have you tested it every 15 minute connection? I created a schedule task to send the message. I use NotifyMyAndroid to push it. C2DM sometime pushes the message about 10 mninutes after not instantly. But, sometimes you get it in around a second.
The best way you can do this is by testing. I have a mechanism in my app that when I enable debugging I receive a HTTP request from the client saying that they received the message.
I find that this number is about 80%. Fortunately that's enough for the scope of my application.
Wifi shouldn't interfere in the C2DM ability of receive messages. At least while the phone is active.
What happens is that android turns the wifi OFF after the phone is in standby for a while. The messages won't be available at that period of time, simply because there's no internet connection available. Right after the user wakes the phone up, they should receive the messages.
After a long time research pretty much "all the internet" for an answer, I've found it. As I posted before, I was struggling with the problem myself and found out it was not a C2DM problem, or even a implementation problem. It was simply a router or firewall misconfiguration. Android uses a persistent TCP connection with a heartbeat keep-alive mecanism to ensures that the connection stays up. Google uses the state of the connection to determine if your device is idle or not. But if your router has a protection policy that checks for "unused" connections and terminates them, that won't work. Android notifications should be delivered (close to) instantly. I've tested this in my school network and home network, with two diferrent behaviour.
To resume: be sure to check your network configurations.
Some APNs work better than others with C2DM. Google "gtalk apn", for example, to find forums about the impact of the APN on C2DM.