Via GP
@pocmo to run some preliminary tests
Probably related: #1333
More reports via GPS
"Draining battery on 7.1.1 stock, Xperia xz as Stamina recognized it."
This could also be related to #1492 – we would stop using the disk cache, so we would use the network more often and thus be using more battery than requesting the data from disk.
Setting this P2, and revisit again once the P1 items have been fixed to see if issues have been resolved (#1492 and #1613)
"App destroys batteries if the Focus notification is present. If I forget to fully close the browser, i.e. there isn't a notification, Focus is the top battery user. Shows "in use" longer than my screen is on."
I wonder if the webView isn't being paused while the app is backgrounded. Only some users might be affected by this because it depends on the page the user has open in the background.
More via GPS
"Browser itself is fantastic. Lightweight, private, everything you would want. However it uses an incredible amount of cpu power even when it's not in use, making it almost unusable your phone goes from 100% to 60% in an hour, even when the screen is off."
We landed a patch that might reduce the battery/CPU usage in the background. This should be released in 4.1.
Keep it in triage -- see if the recent update solved the issue?
GPS: "How does app eating 1gb of cellular data in the _background_ align with the purpose of privacy, Mozilla?"
GPS: "On Android 7.0, Focus uses so much battery in the background that I
couldn't even get through a day on a phone that usually makes it through 2."
To help debug this issue, could we collect battery stats as part of telemetry? We could compare session time in focus to change in battery life to find out what variables, on average, have a significant affect on battery usage, e.g.:
Though this may not help considering people say it uses battery in the background.
@npark-mozilla to investigate if we can use some battery tooling tools to look into it further.
I think one tool we can use is http://www.gsamlabs.com/ . This would have to be a manual testing, with a well-defined set of procedures for accuracy. Might need to get softvision involved as well. Let me know in advance if you want this test added, as it'll need some preparations.
I was also told similar efforts were made with Firefox for Android in the past, but little was done with the findings. The optimization effort would be needed to justify the testing since it does take up a good portion of manual testing resources.
Another one
"It was great at first, but then my phone started to be warm and it sucked
27% of my battery in a day (according to the android battery manager) and I
did not even use it that day. Also I would appreciate the possibility to
close the app once I click the trash icon."
One thing I noticed (this could be unrelated btw) is that the Focus instance started with custom tabs stays active unless the user explicitly kills it in the recent apps list. I wonder whether this might have something to do with battery life as well.
I switched to a new phone, Nokia 7 Plus with Android 8.1, and now I constantly see a notification saying "Android System - Firefox Klar is using battery" when pages are opened in Firefox Focus but the app is in the background. While it only wastes a few percent of battery when not used f.e. overnight, I don't see a reason for my browser doing stuff while I'm not using it. Is there a way to just stop the browser when in background?
I forgot to mention that the OS doesn't think the app ever is in background, battery usage statistic at the moment tells:
While in active use: Used for 1d 17h 40m
While in background: Active for 0m
But I was using the app a maximum of two or three hours since last charging my phone.
@flansch do you even see that when all tabs are cleared?
@pocmo No, the 'using battery' notification isn't shown when I first erase the browsing history and then send Firefox Focus to the background.
But: The first thing I did after installing the app was to disable app notifications from the Android system settings (because I have no need to erase my browsing history). I re-enabled them now and the 'using battery' notification is gone, instead the 'erase browsing history' notification is shown.
At the moment I can't tell if the app continues to be active in the background, I will have an eye on this for the next days.
For what it is worth, I am also seeing that Android thinks that Focus never goes into the background, and I have done nothing fancy with notification settings.

I'm experiencing heavy battery drain on my LG G6 recently (maybe since updating to Android 8.0?).
Today's example: I think I accidentally opened the app in the morning, but otherwise I haven't used it at all. Result:


Let me know if I can assist in any way diagnosing this.
As long as a session is open, Focus will not go to the background. This is because it's running a foreground service. However, it also should not be consuming a significant amount of battery. These issues are orthogonal. The app should not be consuming a significant amount of battery simply because it's running a foreground service and showing a notification saying it's using battery. I'm investigating this to see if anything is happening while the app isn't being used. I'm not aware of anything that should be consuming battery in this state.
@colintheshots something is definitely happening, as basically every single time I back out of the app I do that after pressing the "clear all" button: I'm assuming that means no session should be open anymore.
I filed GeckoView bug 1482185 to investigate why GeckoView does not stop background tab rendering or timers.
As Chris Peterson points out, I managed to verify that although we tell GeckoView we're paused, CNN.com still invalidates views while we're paused. I also confirmed that audio stops, so GeckoView knows we're paused and it's in their court to stop View updates.
The Webview issue is different and would most likely require a workaround from the Focus team if we're continuing to support Webview. It's likely Google depends upon the app actually going into the background, which we do not do because we're running a foreground service.
This is blocked on GeckoView. We might be able to implement a workaround on Webview at some risk.
There is some battery investigation going on here:
Bug 1473997 find a way to measure the battery usage of geckoview