Have you ever wondered what happens when you minimize the browser on your phone? Does the website stop loading? What happens if the website has a periodic ping, for analytics, or ads, or another process? On a mobile phone, this could lead to excess data usage — which on a metered connection can be costly.
On a mobile device using the cellular network the radio does not turn off right away due to the Radio Resource Control state machine (read the Wikipedia article or watch this video I made a few years ago when I was at AT&T). If a website keeps pinging a server, the radio is unable to turn off, and this can lead to excess battery drain.
So, what do I see when I test websites? I tethered my Nokia 2018 (Android 9.0) to my computer, and watched the page loading process using the Chrome inspector on my Mac. I recorded the screen of my Mac to follow along later. After about 15–30 seconds, the page was loaded, and I pressed the ‘home’ button on the device, making the page “inactive” according to devTools. Content continues to be requested and delivered to the device.
As I was not interacting with my phone, the phone screen turns off one minute later. Content still continues to be delivered to the device.
Five minutes from the time the browser was made inactive, the downloads are stopped. Whether that is a timer in Chrome, the Android OS, or perhaps even a Nokia configuration, I am unsure. However, I am able to reproduce this timing for four different websites, each with a different recurring ping/download:
Example 1: Website querying a Google sheet
This website loads, and then every second, queries a Google Spreadsheet for information:
One minute in, there have been 213 requests (the browser has been minimized for 30 seconds)
at time = 5 minutes, and additional 247 requests (700KB) have been made:
Example 2: Cart “Are we There Yet”
This application uses a 3rd party plugin for its cart. And it keeps track of what is in the cart by querying every second or so.
The cart has already been pinging when the browser is minimized at t=30s:
And at time =6 minutes (444 requests and 900 KB later):
For 5 minutes, the same cart information is transmitted over and over.
Example 3: Nope, Still can’t find it:
This example is a bit nuts, but the framework that builds this page really wants a file that is not present. For 5 minutes the browser is continuously requesting a file that just isn’t there:
In this case, there are 103 404 requests (the framework appears to add a fallback delay to each failed request). While the data usage is insignificant, but the battery usage will be the same as the other examples.
Example 4: Chatbot
This is one of my pet peeves. I’m not a huge fan of chat bots on the web. But, they seem to be really popular:
What do these do? As you might imagine, this chatbot pings the server regularly to let the server know if the there is an agent available, and if a chat has started. There is a second ping that gives the time between pings (and sets a delay for the next ping):
As far as I can tell, this ping delay is not implemented — the pings do not actually slow down. The number of pings is also not any different if there is no agent available.
Over 5 minutes, there are 130 requests made, using only 100 KB of data. With an average of a connection every 2.3 seconds, it is unlikely that the cellular radio ever turns off.
Packet Capture:
A comment on Twitter confirmed a suspicion: what if the devtools connection is somehow interfering and allowing the browser to continue its communication.
I ran a test with a local pcap capture app on my phone, and I still see packets transferring for 5 minutes after minimising the browser. This is the 404 website, about 4 minutes after I minimised the browser:
Battery Historian:
In another attempt to see why the radio stays on on for 5 additional minutes, I believe that Battery Historian provides the best explanation. IN this study, I loaded the chat website in Chrome, and once Chrome is backgrounded, the screen allowed to fall asleep. Approximately 5 minutes after the browser is closed, the Android Doze framework (yellow line) kicks in:
At the bottom of the chart, the Mobile Radio Active line stays nearly constantly on until the Doze framework kicks in, as also seen devTools and the Packet Capture.
To compare the how the mobile network is used otherwise, here is a background Battery Historian trace (screen off):
There is some mobile radio usage, but far less than right after the browser is closed.
Disabling Doze:
It is possible to disable the Doze framework for an individual application (with the warning that battery drain may increase. I disabled Doze for Chrome, and re-ran Battery Historian after visiting the chatbot page, and the radio still stays on for 5 minutes, even though Doze does not kick in. The radio does not stay on longer than 5 minutes — indicating that perhaps there is also a timer in Chrome similar to Doze.
Conclusion:
Websites (or 3rd party content) that continually pings a server will not allow the cellular radio to turn off, and can lead to battery drain. In this post, I have shown 4 different scenarios where my Android device continues to download content for 5 minutes after the page has been minimized on the phone. Based on Battery Historian data, the 5 minute timer is not the Doze framework inside Android (as it occurs with or without Doze enabled).
This makes it appear as if the browser has a 5 minute timer for data transfer, even after the page is minimized. For a mobile device, this seems like a long time — allowing for significant battery and data consumption even after the page is finished loading.
Originally published at dougsillars.com on March 22, 2019.
Top comments (1)
Really interesting!