<i>With some Android applications polling for new data every three to five minutes (even when not in use), [...]</i><p>This is actually the providers' own fault. If you want to keep a connection to a "push service" like gmail, imap, voip or jabber, you usually do so by maintaining an idle TCP connection, where the server can push notifications to you.<p>However, thanks to the IP address shortage, almost all 3G providers deploy NAT and only give private addresses to their users. That means that their gateways are maintaining connection tracking tables, which usually have a certain timeout after which idle connections are kicked out.<p>So as a developer, you are forced to regularly send keep-alive messages to prevent getting dropped. And because there is no documentation on the timeout, and it is better to be safe than sorry, most developers go somewhere below 5 minutes.
NTT DoCoMo are used to owning the whole end-to-end stack. They are one of the few, if not the only, operator that very thoroughly specifies both the network side and the terminal side of their network. They have a large R&D department that is very competent and actively engaged in standardization and development of new technologies. For instance, they were one of the drivers behind LTE from the very start.<p>For them, it must be hard to no longer own the terminals on their network fully. I suppose they had to start offering Android terminals since their own smartphones were not competitive compared to the Iphone and Android.<p>But without any control of the terminals' behavior it's very hard to tune and operate a cellular network. It's not so easy to increase capacity, since there's only so much spectrum available for use and the modern wireless technologies can't get much more efficient. Especially in crowded locations like downtown Tokyo the base stations are already about as close as you can have them. It's not something you can just throw money at to solve.<p>So it's a tough problem. From the handset makers' and app developers' side it's easier to not restrict data usage since they are not the ones paying the price.
<i>Some</i> of the blame here lies on programmers, not that I'm supporting NTT's approach. I lead a team of app developers for my day job, and one client once sent us some code from a previous development house to troubleshoot.<p>The thing was polling for new data <i>every 15 seconds</i>. What was particularly surprising was the developer who had written it had quite a good reputation, and was highly though of - on the desktop. And perhaps that's the problem - that people are coming to mobile, writing apps and not considering that what's OK on the desktop is not going to fly on mobile.<p>(...before someone chimes in here: polling every 15 seconds on a mobile device is unacceptable if you're on a cellular network. Firstly you'll kill the battery, as iOS and Android power down the radios when not transmitting, and secondly you'll eat up bandwidth)
The real problem here is that cell phone networks were originally (and to a large extent still are) designed with assumptions that clients will play nice. Even the carriers' contracts with other vendors are structured this way.<p>As an example, on certain carriers I've worked with, the carrier paid per-request for a network assisted location lookup. Access to the location service was enforced with "secret" IP address and port pairs per allowed application. This "secret" information was compiled into every approved app and was trivially enumerable by brute force or discoverable via decompilation. If I had created a malicious app that used the same port as the carriers' branded navigation software, I could incur trivially incur costs in the $xxx/hour range. Their only recourse would have been to disable that port, and with it, navigation for <i>all</i> their customers (until they could issue an update, which would again be vulnerable to the same attack). They could also kick my phone off the network, but if a worm was every released they'd be screwed.<p>Mobile networks weren't and still aren't built for general use. Like the internet at large, as time goes on they'll have to improve as false assumptions they've made are accidentally or maliciously violated.<p>If (relatively) few phones with undesirable behavior can take you down, you're doing it wrong.
souldn't be impossible to do. i use opera mini on android, ios and symbian and it's remote compression reduces data so that i can browse the web all day and get nowhere near my 50mb daily limit.<p>it would be possible for google to create a service/api that does something similar for other apps.