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 <[email protected]>wrote: > 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 <[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 >> > > > > -- > 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
