The GCM is part of the platform - 3rd party apps depend on it and so there's no mechanism for deactivating it.
If you can allow the GCM connection to succeed, you should avoid the current problems, but if you're going for a secure platform you may not want the GCM connection to succeed. You could potentially hijack the dns resolution: have your dns server report an address you control for mtalk.google.com, then allow connections to your own server, but no real functionallity. With some reverse engineering you may be able to get to a quiet connection that doesn't trigger these data-stall triggers. The easiest solution is to adjust your keep-alive ping to < 6 minutes. That will effect the battery, but less than allowing the resets to happen. I have created internal issues to examine this issue, but even if we fixed it today internally you wouldn't see it for a long while. The first issue is to find what traffic is causing this connection reset. The second is to re-eval counting udp packets (I am assuming that's causing part of this problem). I'm sorry you have hit this issue. Robert On Thu, Dec 20, 2012 at 4:30 AM, Goncalo Oliveira <[email protected]>wrote: > Robert, > > Any updates on this? > > Cheers > > > On 18 December 2012 10:06, Goncalo Oliveira <[email protected]> wrote: > >> consider opening up the addre > > > > > -- > Gonçalo Oliveira > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
