The default bug view has changed. See this FAQ.

Do not stop listening to battery changes when in the background on Android

RESOLVED FIXED in mozilla11

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: John Hammink, Assigned: mounir)

Tracking

Trunk
mozilla11
ARM
Android
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
on a trial of three turns, when the .chargingTime returned 540 seconds (9 minutes);actual charging time to full battery was in all cases between 18-26 minutes.

I was getting similar discrepancy for .dischargingTime although I do not have exact values, I can try this also if necessary.
(Reporter)

Comment 1

5 years ago
Results for .dischargingTime for a single trial:

reported time 145 seconds (at 5% battery)
at 4% .dischargingTime updated to 1200 seconds
at 2% .dischargingTime updated to 786 seconds
at 1% .dischargingTime updated to 334 seconds

actual total time to fully discharge from 5%: 1795 seconds  (with screen on max brightness)

How accurate do we want this to be?
Yeah, I'd like to have something more accurate than this. The question is if we get enough info from the OS to calculate it.
(Assignee)

Comment 3

5 years ago
We have a two issues that make estimating hard:
 1. charging/discharging time curve are not straight. Right now, to estimate, we wait for a full charge (Dlevel), and we compare it the time it took (Dt), then we can use Dt/Dlevel * X to get the time (X depends on if we are charging (1.0 - level) or discharging (level)). We could probably add to this another parameter depending on the battery type (which we can get) that would make the estimate more accurate. FWIW, I thought charging was not a straight curve but I thought discharging actually was.
 2. We stop listening for battery events when the application is in background, which includes the phone screen being off. Which means when you open the app with 55% of battery and do some stuff like playing a game then reopen the app with 52.9% of battery, we are going to use Dt as the time spent between the app being open and reopen and Dlevel is going to be 3% because Android has a 1% precision in battery level which means 52.9% never exists, we only know about 52% or 53%. Because of this, we can have big mistakes when the app goes in background. If we continue to listen to battery events while the app is in background, that would fix this error but that could also make Firefox uses more battery.

I think we shouldn't care that much about 1. for the moment but we should think about 2. I don't know enough about embedding and Android to know if listening to battery events while in background is very bad but I think it might worth trying. Chris, what do you think?
Since scripts can continue to run while FF is in the background, it might make sense for us to keep listening for updates.  How often do those battery updates arrive?

For (1), we can take a look at how other libraries compute battery remaining-time.
(Assignee)

Comment 5

5 years ago
(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> Since scripts can continue to run while FF is in the background, it might
> make sense for us to keep listening for updates.  How often do those battery
> updates arrive?

Every 1%, so every few minutes. As I said, I think it might worth trying given that you seem to agree, I'm going to write a patch to fix that.
(Assignee)

Updated

5 years ago
Assignee: nobody → mounir
Blocks: 696038
Status: NEW → ASSIGNED
Summary: Battery API: Currently .chargingTime isn't actually returning accurate value → Do not stop listening to battery changes when in the background on Android
(Assignee)

Updated

5 years ago
Component: General → DOM
QA Contact: general → general
(Assignee)

Comment 6

5 years ago
(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> For (1), we can take a look at how other libraries compute battery
> remaining-time.

I've open bug 703689 for that.
(Assignee)

Comment 7

5 years ago
Created attachment 575574 [details] [diff] [review]
Patch v1
Attachment #575574 - Flags: review?(jones.chris.g)
(Assignee)

Updated

5 years ago
Whiteboard: [needs review]
Comment on attachment 575574 [details] [diff] [review]
Patch v1

Let's give this a shot ...
Attachment #575574 - Flags: review?(jones.chris.g) → review+
(Assignee)

Updated

5 years ago
Flags: in-testsuite?
Whiteboard: [needs review]
(Assignee)

Updated

5 years ago
Attachment #575574 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/ea8aa682c71f
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.