Re: [android-developers] Mobile network idle sockets disconnected
Thanks for the reply Robert. I also had the idea that this was device side
only, but I'm still confused by these behaviors.
I do bet that Samsung's is doing something different (not that uncommon).
I'm pasting the radio logs below. The SIM card used here is the one that
works in the other device.
There's still something else I don't understand... the other SIM card
doesn't work with either phones. I don't think it's the APN, at least, it
shouldn't, but maybe the SIM card has any particularity. I'm going to check
the radio logs also to see if I can trace something at all.
The previous problem log
*D/GSM ( 2104): [GsmDCT] enableApnType: mms is type not available* //
when startUsingNetworkFeature
E/RIL ( 1702): ReaderLoop after select
E/RIL ( 1702): ReaderLoop after FD_ISSET
D/GSM ( 2104): [GsmDCT] disableApnType:mms // when
StopUsingNetworkFeature
D/GSM ( 2104): [GsmDCT] setEnabled(1, false) with old state = false and
enabledCount = 1
D/GSM ( 2104): [GsmDCT] disableApnType: return APN_ALREADY_INACTIVE
D/GSM ( 2104): [GsmDCT] handleMessage msg={ what=270349 when=0 arg1=1 }
D/GSM ( 2104): [GsmDCT] onEnableApn: apnContext=state=IDLE apnType=mms
call applyNewState
D/GSM ( 2104): [GsmDCT] applyNewState(mms, false(false), true(true))
D/GSM ( 2104): [ApnContext] set enabled as false, for type mms, current
state is false
D/GSM ( 2104): [ApnContext] set mDependencyMet as true, for type mms,
current state is true
On 29 January 2013 16:48, Robert Greenwalt rgreenw...@google.com wrote:
There aren't any network requirements I think. This is purely device side
and connects using different parameters and doesn't apply default routes
(it's a secondary net supposedly used next to a default connection). Can
you do a logcat -b radio on the note and see?
It looks like the only way to get that log (and nothing in between) is to
call stopUsingNetworkFeature. However it needs to be called by the same
process/user. That's according the code we ship - Samsung code can be
doing something different. There weren't any log lines between those two?
On Tue, Jan 29, 2013 at 6:45 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Some more information... I tried using another SIM card, using a
different APN, and it didn't work on any of the devices.
What are the network requirements for this special network feature?
On 29 January 2013 13:58, Goncalo Oliveira gonc...@minkan.net wrote:
logcat on galaxy note drops this
01-29 13:50:03.252: D/ConnectivityService(1865):
startUsingNetworkFeature reconnecting to 0: enableMMS
01-29 13:51:03.332: D/ConnectivityService(1865):
stopUsingNetworkFeature: teardown net 0: enableMMS
On 29 January 2013 13:43, Goncalo Oliveira gonc...@minkan.net wrote:
Well, the MMS APN trick does work.. on some devices. On others it
doesn't.
Tested with 2 devices with Android 2.3.3 and 3.2 and worked.
On Samsung Galaxy Note with Android 4.0.4 it's not working. I wonder if
it's the feature string that is different or if it has something to do with
Android version...
Any hints?
On 28 January 2013 17:15, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks Robert, I really appreciate your help. I'll try as you suggest.
On 28 January 2013 16:59, Robert Greenwalt rgreenw...@google.comwrote:
I don't think you're making your own builds, so you'll have to set
the APN data on each device (though you probably already have to do this
as
it's not a public apn). In the apn data set the type of the apn to mms
instead of default or blank. Remove any default/blank apn for your
mcc/mnc pair.
In your app, you will need to call
CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn
off
every 10 minutes (by default - may be different on different phones) so
you
need to call it repeatedly forever perhaps every 9.5 minutes. Then you
need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP
addr you're accessing. Then you should be able to access the servers
normally.
R
On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.net
wrote:
Hi Robert, thanks for such a prompt answer.
Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the
addresses correctly, but the connections will fail. Unfortunately I
don't
have access to DNS servers, so it's a bit harder to capture this
traffic.
I've installed Onavo count to capture the traffic, and I can see the
usage
growing up with Android OS.
The APN idea seems to be a good workaround. Breaking the brower or
other apps isn't really a problem for us, as this is something very
specific. Can you tell me where can I find more information on how to do
this?
Cheers
On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.comwrote:
I am curious what the 3mb/day of data consists of if the servers
can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's
DNS
perhaps you could populate your local DNS server
Re: [android-developers] Mobile network idle sockets disconnected
Well, the MMS APN trick does work.. on some devices. On others it doesn't. Tested with 2 devices with Android 2.3.3 and 3.2 and worked. On Samsung Galaxy Note with Android 4.0.4 it's not working. I wonder if it's the feature string that is different or if it has something to do with Android version... Any hints? On 28 January 2013 17:15, Goncalo Oliveira gonc...@minkan.net wrote: Thanks Robert, I really appreciate your help. I'll try as you suggest. On 28 January 2013 16:59, Robert Greenwalt rgreenw...@google.com wrote: I don't think you're making your own builds, so you'll have to set the APN data on each device (though you probably already have to do this as it's not a public apn). In the apn data set the type of the apn to mms instead of default or blank. Remove any default/blank apn for your mcc/mnc pair. In your app, you will need to call CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn off every 10 minutes (by default - may be different on different phones) so you need to call it repeatedly forever perhaps every 9.5 minutes. Then you need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP addr you're accessing. Then you should be able to access the servers normally. R On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.comwrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.netwrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to
Re: [android-developers] Mobile network idle sockets disconnected
logcat on galaxy note drops this 01-29 13:50:03.252: D/ConnectivityService(1865): startUsingNetworkFeature reconnecting to 0: enableMMS 01-29 13:51:03.332: D/ConnectivityService(1865): stopUsingNetworkFeature: teardown net 0: enableMMS On 29 January 2013 13:43, Goncalo Oliveira gonc...@minkan.net wrote: Well, the MMS APN trick does work.. on some devices. On others it doesn't. Tested with 2 devices with Android 2.3.3 and 3.2 and worked. On Samsung Galaxy Note with Android 4.0.4 it's not working. I wonder if it's the feature string that is different or if it has something to do with Android version... Any hints? On 28 January 2013 17:15, Goncalo Oliveira gonc...@minkan.net wrote: Thanks Robert, I really appreciate your help. I'll try as you suggest. On 28 January 2013 16:59, Robert Greenwalt rgreenw...@google.com wrote: I don't think you're making your own builds, so you'll have to set the APN data on each device (though you probably already have to do this as it's not a public apn). In the apn data set the type of the apn to mms instead of default or blank. Remove any default/blank apn for your mcc/mnc pair. In your app, you will need to call CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn off every 10 minutes (by default - may be different on different phones) so you need to call it repeatedly forever perhaps every 9.5 minutes. Then you need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP addr you're accessing. Then you should be able to access the servers normally. R On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.comwrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.netwrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates
Re: [android-developers] Mobile network idle sockets disconnected
Some more information... I tried using another SIM card, using a different APN, and it didn't work on any of the devices. What are the network requirements for this special network feature? On 29 January 2013 13:58, Goncalo Oliveira gonc...@minkan.net wrote: logcat on galaxy note drops this 01-29 13:50:03.252: D/ConnectivityService(1865): startUsingNetworkFeature reconnecting to 0: enableMMS 01-29 13:51:03.332: D/ConnectivityService(1865): stopUsingNetworkFeature: teardown net 0: enableMMS On 29 January 2013 13:43, Goncalo Oliveira gonc...@minkan.net wrote: Well, the MMS APN trick does work.. on some devices. On others it doesn't. Tested with 2 devices with Android 2.3.3 and 3.2 and worked. On Samsung Galaxy Note with Android 4.0.4 it's not working. I wonder if it's the feature string that is different or if it has something to do with Android version... Any hints? On 28 January 2013 17:15, Goncalo Oliveira gonc...@minkan.net wrote: Thanks Robert, I really appreciate your help. I'll try as you suggest. On 28 January 2013 16:59, Robert Greenwalt rgreenw...@google.comwrote: I don't think you're making your own builds, so you'll have to set the APN data on each device (though you probably already have to do this as it's not a public apn). In the apn data set the type of the apn to mms instead of default or blank. Remove any default/blank apn for your mcc/mnc pair. In your app, you will need to call CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn off every 10 minutes (by default - may be different on different phones) so you need to call it repeatedly forever perhaps every 9.5 minutes. Then you need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP addr you're accessing. Then you should be able to access the servers normally. R On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.comwrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.net wrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans
Re: [android-developers] Mobile network idle sockets disconnected
There aren't any network requirements I think. This is purely device side and connects using different parameters and doesn't apply default routes (it's a secondary net supposedly used next to a default connection). Can you do a logcat -b radio on the note and see? It looks like the only way to get that log (and nothing in between) is to call stopUsingNetworkFeature. However it needs to be called by the same process/user. That's according the code we ship - Samsung code can be doing something different. There weren't any log lines between those two? On Tue, Jan 29, 2013 at 6:45 AM, Goncalo Oliveira gonc...@minkan.netwrote: Some more information... I tried using another SIM card, using a different APN, and it didn't work on any of the devices. What are the network requirements for this special network feature? On 29 January 2013 13:58, Goncalo Oliveira gonc...@minkan.net wrote: logcat on galaxy note drops this 01-29 13:50:03.252: D/ConnectivityService(1865): startUsingNetworkFeature reconnecting to 0: enableMMS 01-29 13:51:03.332: D/ConnectivityService(1865): stopUsingNetworkFeature: teardown net 0: enableMMS On 29 January 2013 13:43, Goncalo Oliveira gonc...@minkan.net wrote: Well, the MMS APN trick does work.. on some devices. On others it doesn't. Tested with 2 devices with Android 2.3.3 and 3.2 and worked. On Samsung Galaxy Note with Android 4.0.4 it's not working. I wonder if it's the feature string that is different or if it has something to do with Android version... Any hints? On 28 January 2013 17:15, Goncalo Oliveira gonc...@minkan.net wrote: Thanks Robert, I really appreciate your help. I'll try as you suggest. On 28 January 2013 16:59, Robert Greenwalt rgreenw...@google.comwrote: I don't think you're making your own builds, so you'll have to set the APN data on each device (though you probably already have to do this as it's not a public apn). In the apn data set the type of the apn to mms instead of default or blank. Remove any default/blank apn for your mcc/mnc pair. In your app, you will need to call CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn off every 10 minutes (by default - may be different on different phones) so you need to call it repeatedly forever perhaps every 9.5 minutes. Then you need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP addr you're accessing. Then you should be able to access the servers normally. R On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.comwrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.net wrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for
Re: [android-developers] Mobile network idle sockets disconnected
Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.com wrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert Greenwalt rgreenw...@google.comwrote: 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 gonc...@minkan.netwrote: Robert, Any updates on this? Cheers On 18 December 2012 10:06, Goncalo Oliveira gonc...@minkan.netwrote: 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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
Re: [android-developers] Mobile network idle sockets disconnected
I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.netwrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert Greenwalt rgreenw...@google.comwrote: 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 gonc...@minkan.netwrote: Robert, Any updates on this? Cheers On 18 December 2012 10:06, Goncalo Oliveira gonc...@minkan.netwrote: 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 android-developers@googlegroups.com To unsubscribe from this group, send
Re: [android-developers] Mobile network idle sockets disconnected
Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.com wrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.netwrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert Greenwalt rgreenw...@google.comwrote: 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
Re: [android-developers] Mobile network idle sockets disconnected
I don't think you're making your own builds, so you'll have to set the APN data on each device (though you probably already have to do this as it's not a public apn). In the apn data set the type of the apn to mms instead of default or blank. Remove any default/blank apn for your mcc/mnc pair. In your app, you will need to call CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn off every 10 minutes (by default - may be different on different phones) so you need to call it repeatedly forever perhaps every 9.5 minutes. Then you need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP addr you're accessing. Then you should be able to access the servers normally. R On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.com wrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.netwrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert Greenwalt rgreenw...@google.comwrote: 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
Re: [android-developers] Mobile network idle sockets disconnected
I wonder if you don't resolve the DNS if your data use will decline? You could test that on an isolated wifi I suppose. On Mon, Jan 28, 2013 at 8:59 AM, Robert Greenwalt rgreenw...@google.comwrote: I don't think you're making your own builds, so you'll have to set the APN data on each device (though you probably already have to do this as it's not a public apn). In the apn data set the type of the apn to mms instead of default or blank. Remove any default/blank apn for your mcc/mnc pair. In your app, you will need to call CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn off every 10 minutes (by default - may be different on different phones) so you need to call it repeatedly forever perhaps every 9.5 minutes. Then you need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP addr you're accessing. Then you should be able to access the servers normally. R On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.com wrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.netwrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something
Re: [android-developers] Mobile network idle sockets disconnected
Thanks Robert, I really appreciate your help. I'll try as you suggest. On 28 January 2013 16:59, Robert Greenwalt rgreenw...@google.com wrote: I don't think you're making your own builds, so you'll have to set the APN data on each device (though you probably already have to do this as it's not a public apn). In the apn data set the type of the apn to mms instead of default or blank. Remove any default/blank apn for your mcc/mnc pair. In your app, you will need to call CM.startUsingNetworkFeature(TYPE_MOBILE, enableMMS). This will turn off every 10 minutes (by default - may be different on different phones) so you need to call it repeatedly forever perhaps every 9.5 minutes. Then you need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP addr you're accessing. Then you should be able to access the servers normally. R On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, thanks for such a prompt answer. Firstly, it's 3 mb in 3 days, 1mb/day. The DNS resolves the addresses correctly, but the connections will fail. Unfortunately I don't have access to DNS servers, so it's a bit harder to capture this traffic. I've installed Onavo count to capture the traffic, and I can see the usage growing up with Android OS. The APN idea seems to be a good workaround. Breaking the brower or other apps isn't really a problem for us, as this is something very specific. Can you tell me where can I find more information on how to do this? Cheers On 28 January 2013 16:14, Robert Greenwalt rgreenw...@google.com wrote: I am curious what the 3mb/day of data consists of if the servers can't be reached. 3mb of tcp connect attempts? DNS lookups? If it's DNS perhaps you could populate your local DNS server with bogus records so that the DNS requests die down to be replaced with perhaps fewer failing connect attempts? Can you capture this traffic? You could potentially use a different APN type. Instead of using a default type you could put it on type IMS or type MMS. This will involve a bit more work for you, but if you don't a a default connection the other apps shouldn't use any data. This would also mean things like the browser won't work. On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira gonc...@minkan.netwrote: Sorry for reopening this, but I have a consequence behavior with this and was hoping for some insights. As I said earlier, we are using a very specific APN that allows the connection only to a restricted range of servers. I managed to use a heartbeat every 5 minutes to workaround the GCM issue, and with the app everything is working fine. However, I have another consequence. Because the APN restricts access to anything outside our safe little world, the system is consuming a whole load of data. Android OS consumed 3 mb in three days, Google Services 416 k. In the data settings I was able to restrict Google Services (as well as software updates and others) from using data but I can't do the same for Android OS. This is killing us completely because we have a very restrictive data plans. Any ideas on how I can disable data transfer for everything except my application? Thanks On 21 December 2012 15:55, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.comwrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.net wrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert
Re: [android-developers] Mobile network idle sockets disconnected
Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert Greenwalt rgreenw...@google.com wrote: 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 gonc...@minkan.netwrote: Robert, Any updates on this? Cheers On 18 December 2012 10:06, Goncalo Oliveira gonc...@minkan.net 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert Greenwalt rgreenw...@google.com wrote: 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 gonc...@minkan.netwrote: Robert, Any updates on this? Cheers On 18 December 2012 10:06, Goncalo Oliveira gonc...@minkan.net 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Robert, Thanks again for clarifying. Basically if I open up GCM I'm allowing user to work with gtalk, so I will want to avoid that. Looks like sending the heartbeat every 5 minutes is the only option I have left. Thanks for the help. Much appreciated. Cheers On 21 December 2012 15:44, Robert Greenwalt rgreenw...@google.com wrote: I believe most of the google apps rely on GCM (calendar, gmail, contacts, talk, etc), also 3rd party apps that need pushed notifications are encouraged to use GCM. Unless you are making a custom build and denying app installs you probably have apps that will be broken without GCM. Of course, if you have very limited data plans on special purpose phones, you may wish for all those apps to be broken - they can use quite a bit of data. I don't know what GCM's steady-state data rate is for a device. I believe it does a carrier keep-alive ping every 20-30 minutes. It also checks for updates whenever the screen comes on. Other than that I think it is dependent on user or network-originating app traffic. R On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thank you for the explanation. There's just one more thing that I'd like you to help me understand. If we choose to allow the GCM connection, what kind of traffic can we expect to have? Like I said previously, we have a very tight data plan, so if the GCM connection adds more than just a few bytes, that might be a bad idea to enable it. Also, by enabling GCM connection, what am I allowing the users to do? Can they use gtalk or something else? Cheers On 21 December 2012 00:17, Robert Greenwalt rgreenw...@google.comwrote: 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 gonc...@minkan.netwrote: Robert, Any updates on this? Cheers On 18 December 2012 10:06, Goncalo Oliveira gonc...@minkan.net 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Robert, Any updates on this? Cheers On 18 December 2012 10:06, Goncalo Oliveira gonc...@minkan.net 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
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 gonc...@minkan.netwrote: Robert, Any updates on this? Cheers On 18 December 2012 10:06, Goncalo Oliveira gonc...@minkan.net 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Robert,
The DNS server isn't disconnected, and resolves correctly
mobile-gtalk.l.google.com TTL=222 A 173.194.78.188
However, the APN does not allow the connection. We might consider opening
up the address (or addresses), but in that case I'll need more information
on what comes through there and on what can the user do with them open.
To answer your questions, yes the production environment will be very
isolated. Most of the times (90% of the cases) the device will be for
exclusive usage. There's a very low data transfer plan, particularly with
roaming, and that's basically why I'm not polling or using C2M or GCM. We
use a very small binary protocol with a very small footprint. The
development headache is bigger true, but it's part of the requirements. The
battery life doesn't trouble me very much as the devices will be connected
to the power supply most of the times.
Cheers
On 17 December 2012 19:59, Robert Greenwalt rgreenw...@google.com wrote:
It seems we switched our traffic stats strategy recently (JB) and now UDP
packets are getting included when they arguably shouldn't be. If your DNS
server is disconnected from the internet and can't resolve the
mtalk.google.com queries you'll end up with outgoing queries and no
responses. This will cause the resets you see every 6 minutes. If the DNS
is resolving, then we probably have some other packet slipping out with no
return.
A couple questions:
Is your production environment going to be this isloated? Gtalk is what's
providing the GCM channel that many 3rd party apps need.
Why aren't you using GCM? It provides a push notification system for
apps, and by sharing it you get better battery life and have less
development headache.
I'm trying to contact the gcm/gtalk team to find out if there's a non-root
way to turn off the service, but I'm not hopeful.
R
On Mon, Dec 17, 2012 at 10:13 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Can't get QTAGUID STATS INFO on samsung. On the other device also fails
retrieving that info. I'm going to try to get another device.
Meanwhile, I published the whole bugreport output, maybe you can see
something that I can't...
https://www.dropbox.com/sh/18o32mndge2rrpd/vAeETMVnh6
Cheers
On 17 December 2012 17:46, Goncalo Oliveira gonc...@minkan.net wrote:
Robert,
Kind of a wild guess but... GTalkService?
logcat
12-17 17:14:47.212 473 1312 E *GTalkService: connectionClosed: no
XMPPConnection - That's strange*!
12-17 17:14:47.220 213 223 E AlarmManagerService:
android_server_AlarmManagerService_set to type=2, 4627.14900
12-17 17:14:47.665 292 292 D STATUSBAR-NetworkController:
onServiceStateChanged state=0
12-17 17:14:47.673 292 292 W SignalStrength: getGsmLevel=3
12-17 17:14:47.673 292 292 W SignalStrength: getLevel=3
(SignalStrength: 99 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 gsm|lte 3)
12-17 17:14:47.673 292 292 D StatusBar.NetworkController:
getDataServiceState : NoSuchMethodException
12-17 17:14:47.673 213 988 D STATUSBAR-NotificationService:
cancelNotification - pkg:com.android.systemui, id:273, tag:null
12-17 17:14:47.689 3183 3183 D StatusChecker: onReceive :
android.intent.action.SERVICE_STATE
12-17 17:14:47.689 3183 3183 D StatusChecker: Service state changed :
0
12-17 17:14:47.689 292 292 D STATUSBAR-NetworkController:
onDataConnectionStateChanged: state=2 type=3
radio
12-17 17:15:49.618 371 371 D GSM : [GsmDCT] updateDataStallInfo:
OUT sent=12 mSentSinceLastRecv=29
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] onDataStallAlarm:
tag=24748 do recovery action=1
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] handleMessage msg={
what=270354 when=-3ms }
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] overall state is
CONNECTED
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] doRecovery() cleanup
all connections
SERVICE com.google.android.gsf/.gtalkservice.service.GTalkService
12-17 17:15:08.158 473 473 D GTalkService: [ReconnectMgr]
setInternalNetworkState: type=0, state=CONNECTED
12-17 17:15:08.158 473 473 I GTalkService/c:
[AndroidEndpoint@1093684528] connect: acct=100, state=CONNECTING
12-17 17:15:08.168 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] doConnectDelegate: making main connection
12-17 17:15:08.168 473 1312 D Smack: [SSLXMPPConnection@1094231880]
create socket connection(mtalk.google.com, 5228)
12-17 17:15:52.215 473 1312 D GTalkService:
[AndroidEndpoint@1093684528] doConnect: caught XMPPError connecting to
mtalk.google.com:5228.: (502)
-- caused by: java.net.ConnectException: failed to connect to
mtalk.google.com/173.194.78.188 (port 5228): connect failed: ETIMEDOUT
(Connection timed out)
12-17 17:15:52.215 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] handleDoConnectError for 100, error=2,
xmppError=null
12-17 17:15:52.215 473 1312 D GTalkService/c:
Re: [android-developers] Mobile network idle sockets disconnected
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm only
sending the heartbeat every 30 minutes. Well, currently I'm doing less than
that, but only as a workaround for this problem. For the test in case, I'm
not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but this
time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio is
on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL 1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE for
type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(mms):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE for
type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(cbs):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.com wrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is detected.
In your log you can see that 21 packets have been sent since you last
received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.comwrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the radio
log like updateDataStallInfo: OUT send=... that show what'
What are you doing in your keepalive pings? Sending a char with no
response, or echoing a response back? That could cause the problem because
there'd be outgoing traffic but no incoming traffic. If there were NO
outgoing the data stall detector shouldn't fire. If you change your
keep-alive to send both ways you should be fine.
This makes me wonder what your other test device is doing - the one that
doesn't show this problem. Are you using rooted devices? They would allow
you to use tcpdump and look at the network traffic..
On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt rgreenw...@google.com
wrote:
Interesting.
Maybe it is an android bug!
What kind of traffic are you sending? tcp? udp?
On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira
gonc...@minkan.netwrote:
Got the radio logs...
http://pastebin.com/754wJ2jd
This seems to be it
GSM : [GsmDCT] onReceive:
action=com.android.internal.telephony.gprs-data-stall
On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.comwrote:
3319 is fine. It's just the tethering code noting an interface is
going away.
Can you get radio logs? This is the system log - there are several
log buffers. A bugreport (adb bugreport mybug.txt) would get them all.
Then you can match the
Re: [android-developers] Mobile network idle sockets disconnected
Robert, isn't there any way to override the data stall detector behavior?
or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm only
sending the heartbeat every 30 minutes. Well, currently I'm doing less than
that, but only as a workaround for this problem. For the test in case, I'm
not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but this
time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio is
on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL 1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE for
type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(mms):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE for
type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(cbs):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.com wrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is detected.
In your log you can see that 21 packets have been sent since you last
received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt rgreenw...@google.com
wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the radio
log like updateDataStallInfo: OUT send=... that show what'
What are you doing in your keepalive pings? Sending a char with no
response, or echoing a response back? That could cause the problem because
there'd be outgoing traffic but no incoming traffic. If there were NO
outgoing the data stall detector shouldn't fire. If you change your
keep-alive to send both ways you should be fine.
This makes me wonder what your other test device is doing - the one that
doesn't show this problem. Are you using rooted devices? They would allow
you to use tcpdump and look at the network traffic..
On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt
rgreenw...@google.com wrote:
Interesting.
Maybe it is an android bug!
What kind of traffic are you sending? tcp? udp?
On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira
gonc...@minkan.netwrote:
Got the radio logs...
http://pastebin.com/754wJ2jd
This seems to be it
GSM : [GsmDCT] onReceive:
action=com.android.internal.telephony.gprs-data-stall
On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.comwrote:
3319 is fine. It's
Re: [android-developers] Mobile network idle sockets disconnected
Robert, some more information that might be relevant.
As I told you, I was using a sim card that connects through our own APN,
that restricts access to our servers.
Today I decided to try the same scenario with a different SIM, so I plugged
a generic 3G sim card, without the APN restrictions. The result was that
I no longer had the stall problem... Could any Android background service
be failing to connect and giving this outcome?
Also, browsing the web I found this issue:
http://code.google.com/p/android/issues/detail?id=35856 might it be
related?
Cheers
On 17 December 2012 12:22, Goncalo Oliveira gonc...@minkan.net wrote:
Robert, isn't there any way to override the data stall detector behavior?
or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm only
sending the heartbeat every 30 minutes. Well, currently I'm doing less than
that, but only as a workaround for this problem. For the test in case, I'm
not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but this
time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio
is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL 1
2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(mms):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(cbs):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is detected.
In your log you can see that 21 packets have been sent since you last
received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.com wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the radio
log like updateDataStallInfo: OUT send=... that show what'
What are you doing in your keepalive pings? Sending a char with no
response, or echoing a response back? That could cause the problem because
there'd be outgoing traffic but no incoming traffic. If there were NO
outgoing the data stall detector shouldn't fire. If you change your
keep-alive to send both ways you should be fine.
This makes me wonder what your other test device is doing - the one
that doesn't show
Re: [android-developers] Mobile network idle sockets disconnected
If you have root you can alter the global settings database
(DATA_STALL_ALARM_AGRESSIVE_DELAY_IN_MS,
DATA_STALL_ALARM_NON_AGGRESSIVE_DELAY_IN_MS).
On Mon, Dec 17, 2012 at 4:22 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Robert, isn't there any way to override the data stall detector behavior?
or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm only
sending the heartbeat every 30 minutes. Well, currently I'm doing less than
that, but only as a workaround for this problem. For the test in case, I'm
not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but this
time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio
is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL 1
2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(mms):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(cbs):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn string
for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited(): resp_id
(11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is detected.
In your log you can see that 21 packets have been sent since you last
received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.com wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the radio
log like updateDataStallInfo: OUT send=... that show what'
What are you doing in your keepalive pings? Sending a char with no
response, or echoing a response back? That could cause the problem because
there'd be outgoing traffic but no incoming traffic. If there were NO
outgoing the data stall detector shouldn't fire. If you change your
keep-alive to send both ways you should be fine.
This makes me wonder what your other test device is doing - the one
that doesn't show this problem. Are you using rooted devices? They would
allow you to use tcpdump and look at the network traffic..
On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt
rgreenw...@google.com wrote:
Interesting.
Maybe it is an android bug!
What kind of traffic are you sending? tcp? udp?
On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira gonc...@minkan.net
wrote:
Got the radio logs...
Re: [android-developers] Mobile network idle sockets disconnected
Interesting.
If you run a test and take a bugreport you whould be able to look at
QTAGUID STATS INFO in the bugreport. It shows the packets/bytes sent per
app. Take a bugreport first, let your device sit for 10 minutes and take
another. The 4th column is the UID of the app and you should be able to
figure our who is responsible for the data.
R
On Mon, Dec 17, 2012 at 7:00 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Robert, some more information that might be relevant.
As I told you, I was using a sim card that connects through our own APN,
that restricts access to our servers.
Today I decided to try the same scenario with a different SIM, so I
plugged a generic 3G sim card, without the APN restrictions. The result
was that I no longer had the stall problem... Could any Android background
service be failing to connect and giving this outcome?
Also, browsing the web I found this issue:
http://code.google.com/p/android/issues/detail?id=35856 might it be
related?
Cheers
On 17 December 2012 12:22, Goncalo Oliveira gonc...@minkan.net wrote:
Robert, isn't there any way to override the data stall detector behavior?
or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm only
sending the heartbeat every 30 minutes. Well, currently I'm doing less than
that, but only as a workaround for this problem. For the test in case, I'm
not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but this
time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio
is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL
1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(mms):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(cbs):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is detected.
In your log you can see that 21 packets have been sent since you last
received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.com wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the
radio
log like updateDataStallInfo: OUT send=...
Re: [android-developers] Mobile network idle sockets disconnected
What if I don't have root access? Is there anything else I can do?
On 17 December 2012 16:08, Robert Greenwalt rgreenw...@google.com wrote:
If you have root you can alter the global settings database
(DATA_STALL_ALARM_AGRESSIVE_DELAY_IN_MS,
DATA_STALL_ALARM_NON_AGGRESSIVE_DELAY_IN_MS).
On Mon, Dec 17, 2012 at 4:22 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Robert, isn't there any way to override the data stall detector behavior?
or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm only
sending the heartbeat every 30 minutes. Well, currently I'm doing less than
that, but only as a workaround for this problem. For the test in case, I'm
not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but this
time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio
is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL
1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(mms):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] isDataPossible(cbs):
possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is detected.
In your log you can see that 21 packets have been sent since you last
received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.com wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the
radio
log like updateDataStallInfo: OUT send=... that show what'
What are you doing in your keepalive pings? Sending a char with no
response, or echoing a response back? That could cause the problem
because
there'd be outgoing traffic but no incoming traffic. If there were NO
outgoing the data stall detector shouldn't fire. If you change your
keep-alive to send both ways you should be fine.
This makes me wonder what your other test device is doing - the one
that doesn't show this problem. Are you using rooted devices? They would
allow you to use tcpdump and look at the network traffic..
On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt
rgreenw...@google.com wrote:
Interesting.
Maybe it is an android bug!
What kind
Re: [android-developers] Mobile network idle sockets disconnected
I am wondering why you are trying to maintain an idle connection?
Usually when my apps send data the socket connection is made, then the data
is sent, then the socket is closed.
This is the normal way of operating.
Regards,
Fred
On 17 December 2012 16:34, Goncalo Oliveira gonc...@minkan.net wrote:
What if I don't have root access? Is there anything else I can do?
On 17 December 2012 16:08, Robert Greenwalt rgreenw...@google.com wrote:
If you have root you can alter the global settings database
(DATA_STALL_ALARM_AGRESSIVE_DELAY_IN_MS,
DATA_STALL_ALARM_NON_AGGRESSIVE_DELAY_IN_MS).
On Mon, Dec 17, 2012 at 4:22 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Robert, isn't there any way to override the data stall detector
behavior? or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm
only sending the heartbeat every 30 minutes. Well, currently I'm doing less
than that, but only as a workaround for this problem. For the test in case,
I'm not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but
this time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio
is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL
1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(mms): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(cbs): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is
detected. In your log you can see that 21 packets have been sent since
you
last received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.com wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries
a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the
radio
log like updateDataStallInfo: OUT send=... that show what'
What are you doing in your keepalive pings? Sending a char with no
response, or echoing a response back? That could cause the problem
because
there'd be outgoing traffic but no incoming traffic. If there were NO
outgoing the data stall detector shouldn't fire. If you change your
keep-alive to send both ways you should be fine.
This makes me wonder what your other
Re: [android-developers] Mobile network idle sockets disconnected
On Mon, Dec 17, 2012 at 11:37 AM, Fred Niggle fred.nig...@googlemail.com wrote: I am wondering why you are trying to maintain an idle connection? You would do this for any sort of push delivery from the server: standard push notifications, VOIP for incoming calls, etc. So, for example, C2DM used to have this sort of heartbeat logic, and I presume GCM does too. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Aqui estão alguns sites onde você pode perguntar ou responder dúvidas sobre desenvolvimento de aplicações para Android: http://www.andglobe.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Fred, I do understand that this is not a standard for most android apps. Therefore, there are a number of scenarios, like Mark pointed out. In this case, the connection is also used for data pushing. Polling would be much simpler, but it does not fit the required scenario. On 17 December 2012 16:43, Mark Murphy mmur...@commonsware.com wrote: On Mon, Dec 17, 2012 at 11:37 AM, Fred Niggle fred.nig...@googlemail.com wrote: I am wondering why you are trying to maintain an idle connection? You would do this for any sort of push delivery from the server: standard push notifications, VOIP for incoming calls, etc. So, for example, C2DM used to have this sort of heartbeat logic, and I presume GCM does too. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Aqui estão alguns sites onde você pode perguntar ou responder dúvidas sobre desenvolvimento de aplicações para Android: http://www.andglobe.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
I don't think so. This is not designed for users to tweak.
If you can figure out who is sending data we might be able to do something.
R
On Mon, Dec 17, 2012 at 8:34 AM, Goncalo Oliveira gonc...@minkan.netwrote:
What if I don't have root access? Is there anything else I can do?
On 17 December 2012 16:08, Robert Greenwalt rgreenw...@google.com wrote:
If you have root you can alter the global settings database
(DATA_STALL_ALARM_AGRESSIVE_DELAY_IN_MS,
DATA_STALL_ALARM_NON_AGGRESSIVE_DELAY_IN_MS).
On Mon, Dec 17, 2012 at 4:22 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Robert, isn't there any way to override the data stall detector
behavior? or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm
only sending the heartbeat every 30 minutes. Well, currently I'm doing less
than that, but only as a workaround for this problem. For the test in case,
I'm not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but
this time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio
is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL
1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(mms): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(cbs): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is
detected. In your log you can see that 21 packets have been sent since
you
last received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.com wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries
a
bunch of things and one of those steps is to tear down and rebuild the
connection. That's what you're seeing. I believe UDP packets may get
ignored, thus my tcp/udp question. You can see some log lines in the
radio
log like updateDataStallInfo: OUT send=... that show what'
What are you doing in your keepalive pings? Sending a char with no
response, or echoing a response back? That could cause the problem
because
there'd be outgoing traffic but no incoming traffic. If there were NO
outgoing the data stall detector shouldn't fire. If you change your
keep-alive to send both ways you should be fine.
This makes me wonder what your other test device is doing - the one
that doesn't show this problem. Are you using rooted
Re: [android-developers] Mobile network idle sockets disconnected
Guess I need a rooted device for that...
-- QTAGUID STATS INFO (su root cat /proc/net/xt_qtaguid/stats) --
*** exec(su): Permission denied
On 17 December 2012 16:33, Robert Greenwalt rgreenw...@google.com wrote:
Interesting.
If you run a test and take a bugreport you whould be able to look at
QTAGUID STATS INFO in the bugreport. It shows the packets/bytes sent per
app. Take a bugreport first, let your device sit for 10 minutes and take
another. The 4th column is the UID of the app and you should be able to
figure our who is responsible for the data.
R
On Mon, Dec 17, 2012 at 7:00 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Robert, some more information that might be relevant.
As I told you, I was using a sim card that connects through our own APN,
that restricts access to our servers.
Today I decided to try the same scenario with a different SIM, so I
plugged a generic 3G sim card, without the APN restrictions. The result
was that I no longer had the stall problem... Could any Android background
service be failing to connect and giving this outcome?
Also, browsing the web I found this issue:
http://code.google.com/p/android/issues/detail?id=35856 might it be
related?
Cheers
On 17 December 2012 12:22, Goncalo Oliveira gonc...@minkan.net wrote:
Robert, isn't there any way to override the data stall detector
behavior? or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm
only sending the heartbeat every 30 minutes. Well, currently I'm doing less
than that, but only as a workaround for this problem. For the test in case,
I'm not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but
this time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio
is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903] DEACTIVATE_DATA_CALL
1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(mms): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(cbs): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={
what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903] DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is
detected. In your log you can see that 21 packets have been sent since
you
last received a packet.
On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt
rgreenw...@google.com wrote:
The data stall detector is watching for outgoing packets with no
corresponding return. If it sees this for X (6 minute default) it tries
a
bunch of things and one of
Re: [android-developers] Mobile network idle sockets disconnected
Well, just to recap: You know that android is not supposed to keep an idle connection open for an extended period. Also you have declined the option to use of a heartbeat to keep the connection open. You also know that GCM (C2DM) have a way of keeping in touch. At this point the main(only?) route to pursue is to look over the GCM libs from google and see how they do it. Best regards, Fred On 17 December 2012 16:49, Goncalo Oliveira gonc...@minkan.net wrote: Fred, I do understand that this is not a standard for most android apps. Therefore, there are a number of scenarios, like Mark pointed out. In this case, the connection is also used for data pushing. Polling would be much simpler, but it does not fit the required scenario. On 17 December 2012 16:43, Mark Murphy mmur...@commonsware.com wrote: On Mon, Dec 17, 2012 at 11:37 AM, Fred Niggle fred.nig...@googlemail.com wrote: I am wondering why you are trying to maintain an idle connection? You would do this for any sort of push delivery from the server: standard push notifications, VOIP for incoming calls, etc. So, for example, C2DM used to have this sort of heartbeat logic, and I presume GCM does too. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Aqui estão alguns sites onde você pode perguntar ou responder dúvidas sobre desenvolvimento de aplicações para Android: http://www.andglobe.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Sent from an Ubuntu Desktop. Ubuntu Speech inputhttps://play.google.com/store/apps/details?id=com.nds.ubuntuspeechinputis now available on Google Play, along with Magnetic Door Alarm apphttps://play.google.com/store/apps/details?id=com.nds.magneticdooralarm . -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Fred, Just to clarify, I haven't declined the heartbeat option. I just would like to avoid low timestamps such as every 5 minute. I'm trying to identify what's happening behind the scenes like Robert suggested, as it seems that it's not just my app that throws this stall. I'll post my results as soon as possible. On 17 December 2012 17:03, Fred Niggle fred.nig...@googlemail.com wrote: Well, just to recap: You know that android is not supposed to keep an idle connection open for an extended period. Also you have declined the option to use of a heartbeat to keep the connection open. You also know that GCM (C2DM) have a way of keeping in touch. At this point the main(only?) route to pursue is to look over the GCM libs from google and see how they do it. Best regards, Fred On 17 December 2012 16:49, Goncalo Oliveira gonc...@minkan.net wrote: Fred, I do understand that this is not a standard for most android apps. Therefore, there are a number of scenarios, like Mark pointed out. In this case, the connection is also used for data pushing. Polling would be much simpler, but it does not fit the required scenario. On 17 December 2012 16:43, Mark Murphy mmur...@commonsware.com wrote: On Mon, Dec 17, 2012 at 11:37 AM, Fred Niggle fred.nig...@googlemail.com wrote: I am wondering why you are trying to maintain an idle connection? You would do this for any sort of push delivery from the server: standard push notifications, VOIP for incoming calls, etc. So, for example, C2DM used to have this sort of heartbeat logic, and I presume GCM does too. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Aqui estão alguns sites onde você pode perguntar ou responder dúvidas sobre desenvolvimento de aplicações para Android: http://www.andglobe.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Sent from an Ubuntu Desktop. Ubuntu Speech inputhttps://play.google.com/store/apps/details?id=com.nds.ubuntuspeechinputis now available on Google Play, along with Magnetic Door Alarm apphttps://play.google.com/store/apps/details?id=com.nds.magneticdooralarm . -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
You could try using the UI in the Settings Data usage screen, but it's
going to be hard to select a small enough time slice. Perhaps if you left
it for a while so you had a bigger window to work from.
On Mon, Dec 17, 2012 at 9:01 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Guess I need a rooted device for that...
-- QTAGUID STATS INFO (su root cat /proc/net/xt_qtaguid/stats) --
*** exec(su): Permission denied
On 17 December 2012 16:33, Robert Greenwalt rgreenw...@google.com wrote:
Interesting.
If you run a test and take a bugreport you whould be able to look at
QTAGUID STATS INFO in the bugreport. It shows the packets/bytes sent per
app. Take a bugreport first, let your device sit for 10 minutes and take
another. The 4th column is the UID of the app and you should be able to
figure our who is responsible for the data.
R
On Mon, Dec 17, 2012 at 7:00 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Robert, some more information that might be relevant.
As I told you, I was using a sim card that connects through our own APN,
that restricts access to our servers.
Today I decided to try the same scenario with a different SIM, so I
plugged a generic 3G sim card, without the APN restrictions. The result
was that I no longer had the stall problem... Could any Android background
service be failing to connect and giving this outcome?
Also, browsing the web I found this issue:
http://code.google.com/p/android/issues/detail?id=35856 might it be
related?
Cheers
On 17 December 2012 12:22, Goncalo Oliveira gonc...@minkan.net wrote:
Robert, isn't there any way to override the data stall detector
behavior? or at least change the default value?
On 17 December 2012 12:02, Goncalo Oliveira gonc...@minkan.net wrote:
Thanks again for the feedback Robert.
I'm sending a heartbeat package but an answer is given. Though, I'm
only sending the heartbeat every 30 minutes. Well, currently I'm doing
less
than that, but only as a workaround for this problem. For the test in
case,
I'm not even sending data. I'm just connecting and listening.
More information that might be relevant - I ran the test again, but
this time I'm not even making a connection. I'm just listening to the
connectivity changes - I was suspecting someone else was causing this.
Turns out that the same behavior occurs, so someone else is causing this?
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearing down
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState
msg.what=EVENT_DISCONNECT RefCount=0
12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData
radio is on, call deactivateDataCall
12-17 11:50:27.951 374 1486 D RILJ: [1903]
DEACTIVATE_DATA_CALL 1 2
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState:
DISCONNECTING for type default, previous state:CONNECTED
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type mms,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type mms, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(mms): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:mms
12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as
pdpReset, for type cbs,current state IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection:
tearDown=true reason=pdpReset
12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE
for type cbs, previous state:IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT]
isDataPossible(cbs): possible=true isDataAllowed=true apnTypePossible=true
apnContextisEnabled=false apnContextState()=IDLE
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn
string for type:cbs
12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll
12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage
msg={ what=270368 when=-1ms arg1=1 }
12-17 11:50:28.576 111 209 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 115 194 D RILClient: processUnsolicited():
resp_id (11010), len(59)
12-17 11:50:28.576 756 784 D RILS: Executing Am broadcast -a
android.intent.action.PROXIMITY_CP --es cmd on
12-17 11:50:30.576 374 496 D RILJ: [1903]
DEACTIVATE_DATA_CALL
Cheers
On 14 December 2012 19:58, Robert Greenwalt rgreenw...@google.comwrote:
oops.. I truncated a sentence..
updateDataStallInfo logs show what's going on when a stall is
detected. In your log you can see that 21 packets have been sent since
Re: [android-developers] Mobile network idle sockets disconnected
I'll try this here as well and see if I can repro the problem on a rooted device. On Mon, Dec 17, 2012 at 9:20 AM, Goncalo Oliveira gonc...@minkan.netwrote: Fred, Just to clarify, I haven't declined the heartbeat option. I just would like to avoid low timestamps such as every 5 minute. I'm trying to identify what's happening behind the scenes like Robert suggested, as it seems that it's not just my app that throws this stall. I'll post my results as soon as possible. On 17 December 2012 17:03, Fred Niggle fred.nig...@googlemail.com wrote: Well, just to recap: You know that android is not supposed to keep an idle connection open for an extended period. Also you have declined the option to use of a heartbeat to keep the connection open. You also know that GCM (C2DM) have a way of keeping in touch. At this point the main(only?) route to pursue is to look over the GCM libs from google and see how they do it. Best regards, Fred On 17 December 2012 16:49, Goncalo Oliveira gonc...@minkan.net wrote: Fred, I do understand that this is not a standard for most android apps. Therefore, there are a number of scenarios, like Mark pointed out. In this case, the connection is also used for data pushing. Polling would be much simpler, but it does not fit the required scenario. On 17 December 2012 16:43, Mark Murphy mmur...@commonsware.com wrote: On Mon, Dec 17, 2012 at 11:37 AM, Fred Niggle fred.nig...@googlemail.com wrote: I am wondering why you are trying to maintain an idle connection? You would do this for any sort of push delivery from the server: standard push notifications, VOIP for incoming calls, etc. So, for example, C2DM used to have this sort of heartbeat logic, and I presume GCM does too. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Aqui estão alguns sites onde você pode perguntar ou responder dúvidas sobre desenvolvimento de aplicações para Android: http://www.andglobe.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Sent from an Ubuntu Desktop. Ubuntu Speech inputhttps://play.google.com/store/apps/details?id=com.nds.ubuntuspeechinputis now available on Google Play, along with Magnetic Door Alarm apphttps://play.google.com/store/apps/details?id=com.nds.magneticdooralarm . -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Robert,
Kind of a wild guess but... GTalkService?
logcat
12-17 17:14:47.212 473 1312 E *GTalkService: connectionClosed: no
XMPPConnection - That's strange*!
12-17 17:14:47.220 213 223 E AlarmManagerService:
android_server_AlarmManagerService_set to type=2, 4627.14900
12-17 17:14:47.665 292 292 D STATUSBAR-NetworkController:
onServiceStateChanged state=0
12-17 17:14:47.673 292 292 W SignalStrength: getGsmLevel=3
12-17 17:14:47.673 292 292 W SignalStrength: getLevel=3
(SignalStrength: 99 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 gsm|lte 3)
12-17 17:14:47.673 292 292 D StatusBar.NetworkController:
getDataServiceState : NoSuchMethodException
12-17 17:14:47.673 213 988 D STATUSBAR-NotificationService:
cancelNotification - pkg:com.android.systemui, id:273, tag:null
12-17 17:14:47.689 3183 3183 D StatusChecker: onReceive :
android.intent.action.SERVICE_STATE
12-17 17:14:47.689 3183 3183 D StatusChecker: Service state changed : 0
12-17 17:14:47.689 292 292 D STATUSBAR-NetworkController:
onDataConnectionStateChanged: state=2 type=3
radio
12-17 17:15:49.618 371 371 D GSM : [GsmDCT] updateDataStallInfo:
OUT sent=12 mSentSinceLastRecv=29
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] onDataStallAlarm:
tag=24748 do recovery action=1
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] handleMessage msg={
what=270354 when=-3ms }
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] overall state is
CONNECTED
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] doRecovery() cleanup
all connections
SERVICE com.google.android.gsf/.gtalkservice.service.GTalkService
12-17 17:15:08.158 473 473 D GTalkService: [ReconnectMgr]
setInternalNetworkState: type=0, state=CONNECTED
12-17 17:15:08.158 473 473 I GTalkService/c:
[AndroidEndpoint@1093684528] connect: acct=100, state=CONNECTING
12-17 17:15:08.168 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] doConnectDelegate: making main connection
12-17 17:15:08.168 473 1312 D Smack: [SSLXMPPConnection@1094231880]
create socket connection(mtalk.google.com, 5228)
12-17 17:15:52.215 473 1312 D GTalkService:
[AndroidEndpoint@1093684528] doConnect: caught XMPPError connecting to
mtalk.google.com:5228.: (502)
-- caused by: java.net.ConnectException: failed to connect to
mtalk.google.com/173.194.78.188 (port 5228): connect failed: ETIMEDOUT
(Connection timed out)
12-17 17:15:52.215 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] handleDoConnectError for 100, error=2,
xmppError=null
12-17 17:15:52.215 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] closeConnection for 100, notify=true,
xmppConn=null
12-17 17:15:52.216 473 1312 E GTalkService: connectionClosed: no
XMPPConnection - That's strange!
12-17 17:15:52.216 473 1312 D GTalkService: [ReconnectMgr] ###
report Inet status: online=false, networkType=0
like I said, kind of a wild guess. I'll try to replicate here with another
device also (rooted), as in this one I can't get the QTAGUID STATS.
Cheers
On 17 December 2012 17:24, Robert Greenwalt rgreenw...@google.com wrote:
I'll try this here as well and see if I can repro the problem on a rooted
device.
On Mon, Dec 17, 2012 at 9:20 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Fred,
Just to clarify, I haven't declined the heartbeat option. I just would
like to avoid low timestamps such as every 5 minute.
I'm trying to identify what's happening behind the scenes like Robert
suggested, as it seems that it's not just my app that throws this stall.
I'll post my results as soon as possible.
On 17 December 2012 17:03, Fred Niggle fred.nig...@googlemail.comwrote:
Well, just to recap:
You know that android is not supposed to keep an idle connection open
for an extended period.
Also you have declined the option to use of a heartbeat to keep the
connection open.
You also know that GCM (C2DM) have a way of keeping in touch.
At this point the main(only?) route to pursue is to look over the GCM
libs from google and see how they do it.
Best regards,
Fred
On 17 December 2012 16:49, Goncalo Oliveira gonc...@minkan.net wrote:
Fred,
I do understand that this is not a standard for most android apps.
Therefore, there are a number of scenarios, like Mark pointed out. In this
case, the connection is also used for data pushing. Polling would be much
simpler, but it does not fit the required scenario.
On 17 December 2012 16:43, Mark Murphy mmur...@commonsware.com wrote:
On Mon, Dec 17, 2012 at 11:37 AM, Fred Niggle
fred.nig...@googlemail.com wrote:
I am wondering why you are trying to maintain an idle connection?
You would do this for any sort of push delivery from the server:
standard push notifications, VOIP for incoming calls, etc.
So, for example, C2DM used to have this sort of heartbeat logic, and I
presume GCM does too.
--
Mark Murphy (a Commons Guy)
http://commonsware.com |
Re: [android-developers] Mobile network idle sockets disconnected
Can't get QTAGUID STATS INFO on samsung. On the other device also fails
retrieving that info. I'm going to try to get another device.
Meanwhile, I published the whole bugreport output, maybe you can see
something that I can't...
https://www.dropbox.com/sh/18o32mndge2rrpd/vAeETMVnh6
Cheers
On 17 December 2012 17:46, Goncalo Oliveira gonc...@minkan.net wrote:
Robert,
Kind of a wild guess but... GTalkService?
logcat
12-17 17:14:47.212 473 1312 E *GTalkService: connectionClosed: no
XMPPConnection - That's strange*!
12-17 17:14:47.220 213 223 E AlarmManagerService:
android_server_AlarmManagerService_set to type=2, 4627.14900
12-17 17:14:47.665 292 292 D STATUSBAR-NetworkController:
onServiceStateChanged state=0
12-17 17:14:47.673 292 292 W SignalStrength: getGsmLevel=3
12-17 17:14:47.673 292 292 W SignalStrength: getLevel=3
(SignalStrength: 99 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 gsm|lte 3)
12-17 17:14:47.673 292 292 D StatusBar.NetworkController:
getDataServiceState : NoSuchMethodException
12-17 17:14:47.673 213 988 D STATUSBAR-NotificationService:
cancelNotification - pkg:com.android.systemui, id:273, tag:null
12-17 17:14:47.689 3183 3183 D StatusChecker: onReceive :
android.intent.action.SERVICE_STATE
12-17 17:14:47.689 3183 3183 D StatusChecker: Service state changed : 0
12-17 17:14:47.689 292 292 D STATUSBAR-NetworkController:
onDataConnectionStateChanged: state=2 type=3
radio
12-17 17:15:49.618 371 371 D GSM : [GsmDCT] updateDataStallInfo:
OUT sent=12 mSentSinceLastRecv=29
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] onDataStallAlarm:
tag=24748 do recovery action=1
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] handleMessage msg={
what=270354 when=-3ms }
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] overall state is
CONNECTED
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] doRecovery() cleanup
all connections
SERVICE com.google.android.gsf/.gtalkservice.service.GTalkService
12-17 17:15:08.158 473 473 D GTalkService: [ReconnectMgr]
setInternalNetworkState: type=0, state=CONNECTED
12-17 17:15:08.158 473 473 I GTalkService/c:
[AndroidEndpoint@1093684528] connect: acct=100, state=CONNECTING
12-17 17:15:08.168 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] doConnectDelegate: making main connection
12-17 17:15:08.168 473 1312 D Smack: [SSLXMPPConnection@1094231880]
create socket connection(mtalk.google.com, 5228)
12-17 17:15:52.215 473 1312 D GTalkService:
[AndroidEndpoint@1093684528] doConnect: caught XMPPError connecting to
mtalk.google.com:5228.: (502)
-- caused by: java.net.ConnectException: failed to connect to
mtalk.google.com/173.194.78.188 (port 5228): connect failed: ETIMEDOUT
(Connection timed out)
12-17 17:15:52.215 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] handleDoConnectError for 100, error=2,
xmppError=null
12-17 17:15:52.215 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] closeConnection for 100, notify=true,
xmppConn=null
12-17 17:15:52.216 473 1312 E GTalkService: connectionClosed: no
XMPPConnection - That's strange!
12-17 17:15:52.216 473 1312 D GTalkService: [ReconnectMgr] ###
report Inet status: online=false, networkType=0
like I said, kind of a wild guess. I'll try to replicate here with another
device also (rooted), as in this one I can't get the QTAGUID STATS.
Cheers
On 17 December 2012 17:24, Robert Greenwalt rgreenw...@google.com wrote:
I'll try this here as well and see if I can repro the problem on a rooted
device.
On Mon, Dec 17, 2012 at 9:20 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Fred,
Just to clarify, I haven't declined the heartbeat option. I just would
like to avoid low timestamps such as every 5 minute.
I'm trying to identify what's happening behind the scenes like Robert
suggested, as it seems that it's not just my app that throws this stall.
I'll post my results as soon as possible.
On 17 December 2012 17:03, Fred Niggle fred.nig...@googlemail.comwrote:
Well, just to recap:
You know that android is not supposed to keep an idle connection open
for an extended period.
Also you have declined the option to use of a heartbeat to keep the
connection open.
You also know that GCM (C2DM) have a way of keeping in touch.
At this point the main(only?) route to pursue is to look over the GCM
libs from google and see how they do it.
Best regards,
Fred
On 17 December 2012 16:49, Goncalo Oliveira gonc...@minkan.net wrote:
Fred,
I do understand that this is not a standard for most android apps.
Therefore, there are a number of scenarios, like Mark pointed out. In this
case, the connection is also used for data pushing. Polling would be much
simpler, but it does not fit the required scenario.
On 17 December 2012 16:43, Mark Murphy mmur...@commonsware.comwrote:
On Mon, Dec 17, 2012 at 11:37
Re: [android-developers] Mobile network idle sockets disconnected
It seems we switched our traffic stats strategy recently (JB) and now UDP
packets are getting included when they arguably shouldn't be. If your DNS
server is disconnected from the internet and can't resolve the
mtalk.google.com queries you'll end up with outgoing queries and no
responses. This will cause the resets you see every 6 minutes. If the DNS
is resolving, then we probably have some other packet slipping out with no
return.
A couple questions:
Is your production environment going to be this isloated? Gtalk is what's
providing the GCM channel that many 3rd party apps need.
Why aren't you using GCM? It provides a push notification system for apps,
and by sharing it you get better battery life and have less development
headache.
I'm trying to contact the gcm/gtalk team to find out if there's a non-root
way to turn off the service, but I'm not hopeful.
R
On Mon, Dec 17, 2012 at 10:13 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Can't get QTAGUID STATS INFO on samsung. On the other device also fails
retrieving that info. I'm going to try to get another device.
Meanwhile, I published the whole bugreport output, maybe you can see
something that I can't...
https://www.dropbox.com/sh/18o32mndge2rrpd/vAeETMVnh6
Cheers
On 17 December 2012 17:46, Goncalo Oliveira gonc...@minkan.net wrote:
Robert,
Kind of a wild guess but... GTalkService?
logcat
12-17 17:14:47.212 473 1312 E *GTalkService: connectionClosed: no
XMPPConnection - That's strange*!
12-17 17:14:47.220 213 223 E AlarmManagerService:
android_server_AlarmManagerService_set to type=2, 4627.14900
12-17 17:14:47.665 292 292 D STATUSBAR-NetworkController:
onServiceStateChanged state=0
12-17 17:14:47.673 292 292 W SignalStrength: getGsmLevel=3
12-17 17:14:47.673 292 292 W SignalStrength: getLevel=3
(SignalStrength: 99 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 gsm|lte 3)
12-17 17:14:47.673 292 292 D StatusBar.NetworkController:
getDataServiceState : NoSuchMethodException
12-17 17:14:47.673 213 988 D STATUSBAR-NotificationService:
cancelNotification - pkg:com.android.systemui, id:273, tag:null
12-17 17:14:47.689 3183 3183 D StatusChecker: onReceive :
android.intent.action.SERVICE_STATE
12-17 17:14:47.689 3183 3183 D StatusChecker: Service state changed : 0
12-17 17:14:47.689 292 292 D STATUSBAR-NetworkController:
onDataConnectionStateChanged: state=2 type=3
radio
12-17 17:15:49.618 371 371 D GSM : [GsmDCT] updateDataStallInfo:
OUT sent=12 mSentSinceLastRecv=29
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] onDataStallAlarm:
tag=24748 do recovery action=1
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] handleMessage msg={
what=270354 when=-3ms }
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] overall state is
CONNECTED
12-17 17:15:49.626 371 371 D GSM : [GsmDCT] doRecovery() cleanup
all connections
SERVICE com.google.android.gsf/.gtalkservice.service.GTalkService
12-17 17:15:08.158 473 473 D GTalkService: [ReconnectMgr]
setInternalNetworkState: type=0, state=CONNECTED
12-17 17:15:08.158 473 473 I GTalkService/c:
[AndroidEndpoint@1093684528] connect: acct=100, state=CONNECTING
12-17 17:15:08.168 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] doConnectDelegate: making main connection
12-17 17:15:08.168 473 1312 D Smack: [SSLXMPPConnection@1094231880]
create socket connection(mtalk.google.com, 5228)
12-17 17:15:52.215 473 1312 D GTalkService:
[AndroidEndpoint@1093684528] doConnect: caught XMPPError connecting to
mtalk.google.com:5228.: (502)
-- caused by: java.net.ConnectException: failed to connect to
mtalk.google.com/173.194.78.188 (port 5228): connect failed: ETIMEDOUT
(Connection timed out)
12-17 17:15:52.215 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] handleDoConnectError for 100, error=2,
xmppError=null
12-17 17:15:52.215 473 1312 D GTalkService/c:
[AndroidEndpoint@1093684528] closeConnection for 100, notify=true,
xmppConn=null
12-17 17:15:52.216 473 1312 E GTalkService: connectionClosed: no
XMPPConnection - That's strange!
12-17 17:15:52.216 473 1312 D GTalkService: [ReconnectMgr] ###
report Inet status: online=false, networkType=0
like I said, kind of a wild guess. I'll try to replicate here with
another device also (rooted), as in this one I can't get the QTAGUID STATS.
Cheers
On 17 December 2012 17:24, Robert Greenwalt rgreenw...@google.comwrote:
I'll try this here as well and see if I can repro the problem on a
rooted device.
On Mon, Dec 17, 2012 at 9:20 AM, Goncalo Oliveira gonc...@minkan.netwrote:
Fred,
Just to clarify, I haven't declined the heartbeat option. I just would
like to avoid low timestamps such as every 5 minute.
I'm trying to identify what's happening behind the scenes like Robert
suggested, as it seems that it's not just my app that throws this stall.
I'll post my
Re: [android-developers] Mobile network idle sockets disconnected
Hi, I also experienced this problem, and found the solution was to use a timer to send a character to the server every few seconds when idle. I was lucky that i was also writing the server code sp i could work around this. Im not sure if this solves the problem your having, but just thought id let you know of *a* solution. Im flagging this in case i learn something new :) regards, Fred On 14 December 2012 10:24, Goncalo Oliveira gonc...@minkan.net wrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Ubuntu Speech inputhttps://play.google.com/store/apps/details?id=com.nds.ubuntuspeechinputis now available on Google Play, along with Magnetic Door Alarm apphttps://play.google.com/store/apps/details?id=com.nds.magneticdooralarm . -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Hi Fred, Thanks for the feedback. I'm currently implementing something like that, by sending a heartbeat every 5 minutes (so far the safest interval on tested devices). But this is not an optimal solution, as the data transfer plan is a very tight one (particularly those including roaming). That's why our agreement with the network operator allows idle connections at least for 30 minutes. Sending a heartbeat every 30 minutes is way better than every 5, because even though the heartbeat is only one byte long, TCP overhead adds another 66. That's at least 67 bytes every 5 minutes, at least 8h a day. Cheers. On 14 December 2012 15:10, Fred Niggle fred.nig...@googlemail.com wrote: Hi, I also experienced this problem, and found the solution was to use a timer to send a character to the server every few seconds when idle. I was lucky that i was also writing the server code sp i could work around this. Im not sure if this solves the problem your having, but just thought id let you know of *a* solution. Im flagging this in case i learn something new :) regards, Fred On 14 December 2012 10:24, Goncalo Oliveira gonc...@minkan.net wrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Ubuntu Speech inputhttps://play.google.com/store/apps/details?id=com.nds.ubuntuspeechinputis now available on Google Play, along with Magnetic Door Alarm apphttps://play.google.com/store/apps/details?id=com.nds.magneticdooralarm . -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.com wrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.com wrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Mobile network idle sockets disconnected
Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.com wrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed
Re: [android-developers] Mobile network idle sockets disconnected
3319 is fine. It's just the tethering code noting an interface is going away. Can you get radio logs? This is the system log - there are several log buffers. A bugreport (adb bugreport mybug.txt) would get them all. Then you can match the connectivityservice dropout with what happened in the radio. I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue. I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future. On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.com wrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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
Re: [android-developers] Mobile network idle sockets disconnected
Got the radio logs... http://pastebin.com/754wJ2jd This seems to be it GSM : [GsmDCT] onReceive: action=com.android.internal.telephony.gprs-data-stall On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.com wrote: 3319 is fine. It's just the tethering code noting an interface is going away. Can you get radio logs? This is the system log - there are several log buffers. A bugreport (adb bugreport mybug.txt) would get them all. Then you can match the connectivityservice dropout with what happened in the radio. I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue. I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future. On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.comwrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more
Re: [android-developers] Mobile network idle sockets disconnected
Interesting. Maybe it is an android bug! What kind of traffic are you sending? tcp? udp? On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Got the radio logs... http://pastebin.com/754wJ2jd This seems to be it GSM : [GsmDCT] onReceive: action=com.android.internal.telephony.gprs-data-stall On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.com wrote: 3319 is fine. It's just the tethering code noting an interface is going away. Can you get radio logs? This is the system log - there are several log buffers. A bugreport (adb bugreport mybug.txt) would get them all. Then you can match the connectivityservice dropout with what happened in the radio. I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue. I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future. On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.comwrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.net wrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You received this message because you are subscribed to the Google Groups Android Developers
Re: [android-developers] Mobile network idle sockets disconnected
TCP On 14 December 2012 19:28, Robert Greenwalt rgreenw...@google.com wrote: Interesting. Maybe it is an android bug! What kind of traffic are you sending? tcp? udp? On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Got the radio logs... http://pastebin.com/754wJ2jd This seems to be it GSM : [GsmDCT] onReceive: action=com.android.internal.telephony.gprs-data-stall On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.comwrote: 3319 is fine. It's just the tethering code noting an interface is going away. Can you get radio logs? This is the system log - there are several log buffers. A bugreport (adb bugreport mybug.txt) would get them all. Then you can match the connectivityservice dropout with what happened in the radio. I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue. I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future. On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.comwrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.net wrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't occurring in an Unitech TB 100 with Android 3.2. Does anyone know where I can get more information and/or I can work around this? I would really like to avoid sending heartbeats every 6/7 minutes. Cheers -- You
Re: [android-developers] Mobile network idle sockets disconnected
Maybe it's some other service that is stalling? The SIM card uses a specific APN that only allows it to connect to our servers. Maybe GTalk service or fota? On 14 December 2012 19:32, Goncalo Oliveira gonc...@minkan.net wrote: TCP On 14 December 2012 19:28, Robert Greenwalt rgreenw...@google.com wrote: Interesting. Maybe it is an android bug! What kind of traffic are you sending? tcp? udp? On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Got the radio logs... http://pastebin.com/754wJ2jd This seems to be it GSM : [GsmDCT] onReceive: action=com.android.internal.telephony.gprs-data-stall On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.comwrote: 3319 is fine. It's just the tethering code noting an interface is going away. Can you get radio logs? This is the system log - there are several log buffers. A bugreport (adb bugreport mybug.txt) would get them all. Then you can match the connectivityservice dropout with what happened in the radio. I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue. I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future. On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.comwrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.net wrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.net wrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected - didn't work. Also tried using only a 2G network, as some said that changing from network type could impact on this - same outcome. After digging a bit more and by analyzing logcat, I watched that a CONNECTIVITY_CHANGE is sent after some idle time, disabling the data transfer availability (active network is mobile, no connectivity) and another one is sent enabling it again (active network is mobile, connectivity). This cuts off all live socket connections. Investigating a little bit more, I also observed that this behavior is not consistent through all Android versions, or maybe (even worse) through different hardware. Connectivity break is occurring in a Galaxy Tab 7 with Android 4.0.4.
Re: [android-developers] Mobile network idle sockets disconnected
The data stall detector is watching for outgoing packets with no corresponding return. If it sees this for X (6 minute default) it tries a bunch of things and one of those steps is to tear down and rebuild the connection. That's what you're seeing. I believe UDP packets may get ignored, thus my tcp/udp question. You can see some log lines in the radio log like updateDataStallInfo: OUT send=... that show what' What are you doing in your keepalive pings? Sending a char with no response, or echoing a response back? That could cause the problem because there'd be outgoing traffic but no incoming traffic. If there were NO outgoing the data stall detector shouldn't fire. If you change your keep-alive to send both ways you should be fine. This makes me wonder what your other test device is doing - the one that doesn't show this problem. Are you using rooted devices? They would allow you to use tcpdump and look at the network traffic.. On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt rgreenw...@google.comwrote: Interesting. Maybe it is an android bug! What kind of traffic are you sending? tcp? udp? On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Got the radio logs... http://pastebin.com/754wJ2jd This seems to be it GSM : [GsmDCT] onReceive: action=com.android.internal.telephony.gprs-data-stall On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.comwrote: 3319 is fine. It's just the tethering code noting an interface is going away. Can you get radio logs? This is the system log - there are several log buffers. A bugreport (adb bugreport mybug.txt) would get them all. Then you can match the connectivityservice dropout with what happened in the radio. I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue. I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future. On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.comwrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.netwrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.net wrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another kind of device, also communicating with GSM, and there are no drops, so problem isn't the SIM card. After a few searches in the web, I tried a few approaches to work around this, but until now, no success. I tried using a partial wake lock after connecting, releasing only when disconnected
Re: [android-developers] Mobile network idle sockets disconnected
oops.. I truncated a sentence.. updateDataStallInfo logs show what's going on when a stall is detected. In your log you can see that 21 packets have been sent since you last received a packet. On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt rgreenw...@google.comwrote: The data stall detector is watching for outgoing packets with no corresponding return. If it sees this for X (6 minute default) it tries a bunch of things and one of those steps is to tear down and rebuild the connection. That's what you're seeing. I believe UDP packets may get ignored, thus my tcp/udp question. You can see some log lines in the radio log like updateDataStallInfo: OUT send=... that show what' What are you doing in your keepalive pings? Sending a char with no response, or echoing a response back? That could cause the problem because there'd be outgoing traffic but no incoming traffic. If there were NO outgoing the data stall detector shouldn't fire. If you change your keep-alive to send both ways you should be fine. This makes me wonder what your other test device is doing - the one that doesn't show this problem. Are you using rooted devices? They would allow you to use tcpdump and look at the network traffic.. On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt rgreenw...@google.comwrote: Interesting. Maybe it is an android bug! What kind of traffic are you sending? tcp? udp? On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira gonc...@minkan.netwrote: Got the radio logs... http://pastebin.com/754wJ2jd This seems to be it GSM : [GsmDCT] onReceive: action=com.android.internal.telephony.gprs-data-stall On 14 December 2012 18:25, Robert Greenwalt rgreenw...@google.comwrote: 3319 is fine. It's just the tethering code noting an interface is going away. Can you get radio logs? This is the system log - there are several log buffers. A bugreport (adb bugreport mybug.txt) would get them all. Then you can match the connectivityservice dropout with what happened in the radio. I don't think you should open a bug: this is not an android issue, but rather it's a samsung issue. I have opened an internal issue to expand CTS to check for this - any device wanting to claim to be an android device would not be allowed to do such a thing in the future. On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira gonc...@minkan.netwrote: Robert, Thanks again for the feedback. I traced the logs from samsung with a simple app to reproduce this behavior. Same thing, 6/7 minutes and it drops. I posted the logs here: http://pastebin.com/FcPPbq3V On line 3323 you can see ConnectivityService disconnecting. What I can't understand is what's causing it. Line 3319 is suspicious as I don't have tethering on, but other than that I can't really determine what causes this. Should I open a bug for this? Cheers On 14 December 2012 16:50, Robert Greenwalt rgreenw...@google.comwrote: Is it possible something else on the device is occasionally sending data and reseting your window? I would look in the log for the timestamp of the ConnectivityChanged broadcast and then check the radio log and see what's going on. I suspect there is an unsolicited data call list notification coming from the radio showing that the data call has gone away. Perhaps just before that there may be something explaining why. You may have to contact samsung if you're sure that other devices have longer connection times on the same carrier. On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira gonc...@minkan.net wrote: Hi Robert, Thanks for the reply. If I send a packet every 5/6 minutes the connectivity is maintained yes. Only if connection is idle for longer than that. The weird thing is that it's not an exact timer, even though the average is very close. Sometimes it lasts 7 minutes, sometimes 8 or 9. I even saw this happening with a 4 minute interval, though very rarely. On the other device, I can most of the times maintain higher idle times. I'll try to look at the logs more carefully to see if there's something else. Is there anything in particular that I should look for? Cheers On 14 December 2012 16:16, Robert Greenwalt rgreenw...@google.comwrote: Android is not supposed to do this, though there is no guarantee of connectivity. It sounds like something samsung is doing, either accidentally or on purpose. If you send a packet every 6 minutes does that keep the device from pulsing connectivity? Can you take a bugreport - the radio log may have some indication of why it's happening. On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira gonc...@minkan.net wrote: Hi all, Seems that Android is dropping idle sockets when under a mobile network. Usually, no socket is kept alive for more than 7 minutes of inactivity. I am using a SIM card with a particular APN, that allows idle sockets for at least 30 minutes - this was tested using another
