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.
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.
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.
(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.
(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.
Created attachment 575574 [details] [diff] [review] Patch v1
Comment on attachment 575574 [details] [diff] [review] Patch v1 Let's give this a shot ...