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.
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
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
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
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
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,
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
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
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.
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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?)
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
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
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
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
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
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
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
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).
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
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
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
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
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
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
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:
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...
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
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
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
48 matches
Mail list logo
