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
