GCM Notifications Delayed

[GoogleCodeExporter]

When the latest build of the app on a Nexus 5, I noticed that when switching 
from/to a VPN that the GCM notifications were get all screwed up (e.g. delayed 
messages from apps, sometimes no messages at all unless manually checking). 
Thinking about this problem, I realized it might be due to the low heartbeat 
interval of GCM (i.e. GCM doesn't realize your device switched networks for a 
while) 

Searching for a solution, I found this: 
http://stackoverflow.com/questions/19560448/how-to-avoid-delay-in-android-gcm-me
ssages-change-heartbeat

The solution for the low heartbeat time was to broadcast these intents upon a 
network change:
com.google.android.intent.action.MCS_HEARTBEAT
com.google.android.intent.action.GTALK_HEARTBEAT

Do you think that this would resolve the issue? Broadcasting those upon a) 
connection b) pause c) disconnect

Thanks,
Aakash

Original issue reported on code.google.com by cont...@aaka.sh on 26 Apr 2014 at 8:08

• Merged into: #150

[GoogleCodeExporter]

I should add that sometimes the GCM notifications come through fine while on 
VPN or not. 

Original comment by cont...@aaka.sh on 26 Apr 2014 at 8:12

[GoogleCodeExporter]

Broadcasting these events will trigger a heartbeat from the client and early 
reconnection. Without that the GCM will recover later. But basically this 
affects all Android apps and services keeping permanent connections because 
there is no way for an app to determinate the connectivity has changed when a 
VPN has been established.

Original comment by arne@rfc2549.org on 26 Apr 2014 at 8:17

• Changed state: Duplicate

[GoogleCodeExporter]

"Broadcasting these events will trigger a heartbeat from the client and early 
reconnection." 
To clarify, do you mean that when the VPN pauses and a GCM heartbeat is sent, 
it will cause the VPN to reconnect due to network activity?

Thanks for the response. 

Original comment by cont...@aaka.sh on 26 Apr 2014 at 8:22

[GoogleCodeExporter]

No. The broadcast will trigger communiction from the client over the GCM 
connection. Since the GCM conection is stale, the client will notice that and 
reestablish the connection. Otherwise the GCM client may take up to 15 minutes 
to detect that the connection is stale.

Original comment by arne@rfc2549.org on 26 Apr 2014 at 8:25

[GoogleCodeExporter]

I'm apologize if I'm missing something, but isn't that what we want? After a 
connection to a VPN, the GCM connection will be stale, so we would want to 
broadcast to trigger the reestablishment of a connection. Same thing for a 
pause/disconnect of the VPN.

Original comment by cont...@aaka.sh on 26 Apr 2014 at 8:29

[GoogleCodeExporter]

It is just a hack I don't really want to implement ics-openvpn itself. The 
other VPN solution don't have this hack either. I fine with someone doing a 
small addon or likewise that does exactly this. For example listens to the 
broadcast of ics-openvpn and send the GCM broadcasts.

Original comment by arne@rfc2549.org on 26 Apr 2014 at 8:34

[GoogleCodeExporter]

Is there a broadcast that is only sent when a disconnect happens?  I see 
"LEVEL_NOTCONNECTED, EXITING" and "LEVEL_NOTCONNECTED, NOPROCESS" however those 
are sent upon initiating a connection as well. 

Other than that, I'm pretty much done writing the add-on.

Thanks,
Aakash

Original comment by cont...@aaka.sh on 27 Apr 2014 at 8:27

[GoogleCodeExporter]

In addition, do you think you could enable the 
Intent.FLAG_INCLUDE_STOPPED_PACKAGES in your broadcasts? Otherwise the user 
would have to manually launch the add-ons before they could receive broadcasts. 
Another solution would be that the add-on would have to start a background 
service upon system boot, which seems unnecessary to me as the VPN connection 
isn't always active.

Let me know.
Thanks

Original comment by cont...@aaka.sh on 27 Apr 2014 at 10:28