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.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.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.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 >>> >>> >>> -- >>> 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
