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 <[email protected]>wrote: > What if I don't have root access? Is there anything else I can do? > > > On 17 December 2012 16:08, Robert Greenwalt <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]>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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> <[email protected]>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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>> [email protected]> 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 >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> For more options, visit this group at >>>>>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google >>>>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> For more options, visit this group at >>>>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Gonçalo Oliveira >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google >>>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>> [email protected] >>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>> [email protected] >>>>>>>>>>>> For more options, visit this group at >>>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google >>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>> To post to this group, send email to >>>>>>>>>>> [email protected] >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> [email protected] >>>>>>>>>>> For more options, visit this group at >>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Gonçalo Oliveira >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>> To post to this group, send email to >>>>>>>>>> [email protected] >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> [email protected] >>>>>>>>>> For more options, visit this group at >>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Android Developers" group. >>>>>>>>> To post to this group, send email to >>>>>>>>> [email protected] >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> [email protected] >>>>>>>>> For more options, visit this group at >>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Gonçalo Oliveira >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Android Developers" group. >>>>>>>> To post to this group, send email to >>>>>>>> [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected] >>>>>>>> For more options, visit this group at >>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Android Developers" group. >>>>> To post to this group, send email to >>>>> [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/android-developers?hl=en >>>>> >>>> >>>> >>>> >>>> -- >>>> Gonçalo Oliveira >>>> >>> >>> >>> >>> -- >>> Gonçalo Oliveira >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/android-developers?hl=en >>> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> > > > > -- > Gonçalo Oliveira > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
