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 <[email protected]>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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]>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 >>>>> <[email protected]>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 <[email protected]>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 < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Robert, >>>>>>>> >>>>>>>> Any updates on this? >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> On 18 December 2012 10:06, Goncalo Oliveira <[email protected]>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 >>>>>>>> [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 unsubscribe from this group, send email to >>> [email protected]. >>> 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 [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 unsubscribe from this group, send email to >> [email protected]. >> 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 [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 unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > 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 [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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
