Last Comment Bug 702858 - Do not stop listening to battery changes when in the background on Android
: Do not stop listening to battery changes when in the background on Android
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: ARM Android
: -- normal (vote)
: mozilla11
Assigned To: Mounir Lamouri (:mounir)
:
Mentors:
Depends on:
Blocks: 696038
  Show dependency treegraph
 
Reported: 2011-11-15 18:18 PST by John Hammink
Modified: 2012-02-01 13:57 PST (History)
3 users (show)
mounir: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1 (3.93 KB, patch)
2011-11-18 14:53 PST, Mounir Lamouri (:mounir)
cjones.bugs: review+
mounir: checkin+
Details | Diff | Review

Description John Hammink 2011-11-15 18:18:44 PST
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.
Comment 1 John Hammink 2011-11-17 16:12:40 PST
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?
Comment 2 Jonas Sicking (:sicking) PTO Until July 5th 2011-11-17 16:51:08 PST
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.
Comment 3 Mounir Lamouri (:mounir) 2011-11-18 00:48:05 PST
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?
Comment 4 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-11-18 11:37:35 PST
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.
Comment 5 Mounir Lamouri (:mounir) 2011-11-18 11:52:15 PST
(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.
Comment 6 Mounir Lamouri (:mounir) 2011-11-18 11:59:50 PST
(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.
Comment 7 Mounir Lamouri (:mounir) 2011-11-18 14:53:35 PST
Created attachment 575574 [details] [diff] [review]
Patch v1
Comment 8 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-11-21 23:21:50 PST
Comment on attachment 575574 [details] [diff] [review]
Patch v1

Let's give this a shot ...
Comment 9 Ed Morley [:emorley] 2011-11-22 09:07:45 PST
https://hg.mozilla.org/mozilla-central/rev/ea8aa682c71f

Note You need to log in before you can comment on or make changes to this bug.