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.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 > 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. > > In your app, you will need to call > CM.startUsingNetworkFeature(TYPE_MOBILE, "enableMMS"). This will turn off > every 10 minutes (by default - may be different on different phones) so you > need to call it repeatedly forever perhaps every 9.5 minutes. Then you > need to call requestRouteToHost(TYPE_MOBILE_MMS, int addr) for every IP > addr you're accessing. Then you should be able to access the servers > normally. > > R > > > On Mon, Jan 28, 2013 at 8:34 AM, Goncalo Oliveira <gonc...@minkan.net>wrote: > >> 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 traffic, and I can see the usage >> growing up with Android OS. >> >> The APN idea seems to be a good workaround. Breaking the brower or other >> apps isn't really a problem for us, as this is something very specific. Can >> you tell me where can I find more information on how to do this? >> >> Cheers >> >> >> On 28 January 2013 16:14, Robert Greenwalt <rgreenw...@google.com> wrote: >> >>> 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 >>> attempts? Can you capture this traffic? >>> >>> You could potentially use a different APN type. Instead of using a >>> default type you could put it on type IMS or type MMS. This will involve a >>> bit more work for you, but if you don't a a default connection the other >>> apps shouldn't use any data. This would also mean things like the browser >>> won't work. >>> >>> >>> >>> On Mon, Jan 28, 2013 at 3:58 AM, Goncalo Oliveira <gonc...@minkan.net>wrote: >>> >>>> 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, and with the app >>>> everything is working fine. However, I have another consequence. Because >>>> the APN restricts access to anything outside "our safe little world", the >>>> system is consuming a whole load of data. Android OS consumed 3 mb in three >>>> days, Google Services 416 k. In the data settings I was able to restrict >>>> Google Services (as well as software updates and others) from using data >>>> but I can't do the same for Android OS. This is killing us completely >>>> because we have a very restrictive data plans. >>>> >>>> Any ideas on how I can disable data transfer for everything except my >>>> application? >>>> >>>> Thanks >>>> >>>> >>>> On 21 December 2012 15:55, Goncalo Oliveira <gonc...@minkan.net> wrote: >>>> >>>>> 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 Greenwalt <rgreenw...@google.com>wrote: >>>>> >>>>>> 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 you have very limited data plans on special purpose >>>>>> phones, you may wish for all those apps to be broken - they can use >>>>>> quite a >>>>>> bit of data. >>>>>> >>>>>> I don't know what GCM's steady-state data rate is for a device. I >>>>>> believe it does a carrier keep-alive ping every 20-30 minutes. It also >>>>>> checks for updates whenever the screen comes on. Other than that I think >>>>>> it is dependent on user or network-originating app traffic. >>>>>> >>>>>> R >>>>>> >>>>>> >>>>>> On Fri, Dec 21, 2012 at 2:23 AM, Goncalo Oliveira <gonc...@minkan.net >>>>>> > wrote: >>>>>> >>>>>>> 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 >>>>>>> few >>>>>>> bytes, that might be a bad idea to enable it. Also, by enabling GCM >>>>>>> connection, what am I allowing the users to do? Can they use gtalk or >>>>>>> something else? >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> >>>>>>> On 21 December 2012 00:17, Robert Greenwalt >>>>>>> <rgreenw...@google.com>wrote: >>>>>>> >>>>>>>> >>>>>>>> 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 could potentially hijack the dns resolution: have your dns >>>>>>>> server report an address you control for mtalk.google.com, then >>>>>>>> allow connections to your own server, but no real functionallity. With >>>>>>>> some reverse engineering you may be able to get to a quiet connection >>>>>>>> that >>>>>>>> doesn't trigger these data-stall triggers. >>>>>>>> >>>>>>>> The easiest solution is to adjust your keep-alive ping to < 6 >>>>>>>> minutes. That will effect the battery, but less than allowing the >>>>>>>> resets >>>>>>>> to happen. >>>>>>>> >>>>>>>> I have created internal issues to examine this issue, but even if >>>>>>>> we fixed it today internally you wouldn't see it for a long while. The >>>>>>>> first issue is to find what traffic is causing this connection reset. >>>>>>>> The >>>>>>>> second is to re-eval counting udp packets (I am assuming that's causing >>>>>>>> part of this problem). >>>>>>>> >>>>>>>> I'm sorry you have hit this issue. >>>>>>>> >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 20, 2012 at 4:30 AM, Goncalo Oliveira < >>>>>>>> gonc...@minkan.net> wrote: >>>>>>>> >>>>>>>>> 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, 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 unsubscribe from this group, send email to >>>> android-developers+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>> >>> -- >>> -- >>> 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 unsubscribe from this group, send email to >>> android-developers+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> >> >> -- >> 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 unsubscribe from this group and stop receiving emails from it, send an >> email to android-developers+unsubscr...@googlegroups.com. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- -- 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 unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
