+++ This bug was initially created as a clone of Bug #1163245 +++ This bug is a follow up to bug 1116368 and bug 1163245. In those we implemented basic support for Battery API's battery.dischargingTime and battery.chargingTime estimations. Unfortunately, our current implementation is very limiting which affects UX. Because it calculates the charge/discharge rate based on time/level ratio it: a) takes two percent change to get the estimations. In case of many devices that's *a lot* of time. Assuming an average phone holds a little above 24h of usage, that means that it discharges at the rate of 1% per 15 minutes. So the first datapoint we get is after 30 minutes... b) the estimations only extrapolate based on the last percent change. This results in a very volatile data, because the whole estimation bases on this one <15min window. It can be 20 hours, and then one percent later 6 hours because some tasks has been performed, and then back to 19 hours. It would be nice to use some statistical functions to collect the data and maybe wage them so that more recent data points are more influential, but overall estimate based on last 10%-20%, not last 1%. This is important for us to provide better user experience for mobile users. We need to manage their expectations better and help them informed choices about their phone remaining battery time or charge time.

Hema, is it possible your team would have resources to take a look at this or do you know who might be able to work on that?

Folks in my team are on Spark and Architecture validation projects currently which includes dhylands who could possibly help here. Adding jhylands to see if could take up instead. Perhaps someone from Shawn's team could also look into it since Danny Liang (no longer here) from his team took on the basic support. Ni'ing both.

Although I could certainly have a go at it, it would not be very time efficient - this is C++ code, and I have very close to zero coding experience in C++. Doing this would also put off the power automation testing, which I think is too important at this stage.

(In reply to Hema Koka [:hema] from comment #2) > Folks in my team are on Spark and Architecture validation projects currently > which includes dhylands who could possibly help here. Adding jhylands to see > if could take up instead. > > Perhaps someone from Shawn's team could also look into it since Danny Liang > (no longer here) from his team took on the basic support. > > Ni'ing both. Hi Hema, I am sorry that my team does not have a person who know power since Danny left us last month:( Per my understanding, the charging/discharging current are not real time data we can get from user space. Besides, power current is not with linear distribution. For example, we know deice only has 5% power left, and we let user know the device may remain power on for 10 min, but device may be shut down within few seconds due to heavy current request (ex: Video playing etc...). There are too many variables that will impact the precision of remaining time. It is not a good UX to let user know in-correct data from my perspective. If anything is wrong, please kindly let me know. Thanks!!

(In reply to shawn ku [:sku] from comment #4) > Per my understanding, the charging/discharging current are not real time > data we can get from user space. > Besides, power current is not with linear distribution. > For example, we know deice only has 5% power left, and we let user know the > device may remain power on for 10 min, but device may be shut down within > few seconds due to heavy current request (ex: Video playing etc...). True, but that's a risk that is part of every estimation. I believe that users of all systems that deal with battery are aware that estimations base on the historical usage and will be affected if the user changes the way they use it. So, just the fact that the estimation has been usually based on time when the screen was off, and now the user is looking at the screen, affects the battery drain. > There are too many variables that will impact the precision of remaining > time. > It is not a good UX to let user know in-correct data from my perspective. All systems estimate battery time. It's imperfect, but it's useful. The problem we are facing right now is that our estimation is very simplistic and based on just delta_time/1%. What I'm trying to get is estimation from longer period ( last 10% or more, possibly weighted to bring more value to more recent drainage), but faster (use current like Android does, instead of just level changes). If I understand you correctly, you say that because the estimation will never be precise, we should not try. I believe we can work with UX on managing user expectations about the reliability of the data, but we should aim for getting the estimations that come from the WebAPI as valuable for the developers and users as possible. Does it make sense?

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #5) > (In reply to shawn ku [:sku] from comment #4) > > Per my understanding, the charging/discharging current are not real time > > data we can get from user space. > > Besides, power current is not with linear distribution. > > For example, we know deice only has 5% power left, and we let user know the > > device may remain power on for 10 min, but device may be shut down within > > few seconds due to heavy current request (ex: Video playing etc...). > > True, but that's a risk that is part of every estimation. I believe that > users of all systems that deal with battery are aware that estimations base > on the historical usage and will be affected if the user changes the way > they use it. > > So, just the fact that the estimation has been usually based on time when > the screen was off, and now the user is looking at the screen, affects the > battery drain. > > > There are too many variables that will impact the precision of remaining > > time. > > It is not a good UX to let user know in-correct data from my perspective. > > All systems estimate battery time. It's imperfect, but it's useful. The > problem we are facing right now is that our estimation is very simplistic > and based on just delta_time/1%. What I'm trying to get is estimation from > longer period ( last 10% or more, possibly weighted to bring more value to > more recent drainage), but faster (use current like Android does, instead of > just level changes). > > If I understand you correctly, you say that because the estimation will > never be precise, we should not try. > > I believe we can work with UX on managing user expectations about the > reliability of the data, but we should aim for getting the estimations that > come from the WebAPI as valuable for the developers and users as possible. > > Does it make sense? Percentage (%) indication on UI somewhere should be good enough if we really need that on FxOS. That's also what iOS/Andoid provide to user currently. Besides, there is no real time data from kernel's perspective. If we can get data from kernel via HAL interface, there is still no precise data though. I might be wrong. If there is any idea/suggestion, please kindly let me know.

(In reply to shawn ku [:sku] from comment #6) > Percentage (%) indication on UI somewhere should be good enough if we really > need that on FxOS. > That's also what iOS/Andoid provide to user currently. Actually, both iOS and Android provide time estimations for both, charging time left and discharging time left. Android shows charging time estimation on the lockscreen and discharging time estimation in the Battery menu available after clicking on the Battery icon in the notification bar. > Besides, there is no real time data from kernel's perspective. > If we can get data from kernel via HAL interface, there is still no precise > data though. My knowledge of the code is very limited, so apologies if my arguments make no sense. There seem to be an ongoing work in Chromium project to improve the WebAPI estimation algorithms: - https://code.google.com/p/chromium/issues/detail?id=401553 - https://chromium.googlesource.com/chromium/src.git/+/13e397e55501bee3903bfe46edfd56f2442c1f11%5E!/#F0 The API's they are using are, if I'm not mistaken, all coming from Android BatteryManager: - http://developer.android.com/reference/android/os/BatteryManager.html And it operates on microampers, microamper-hours and nanowatt-hours. > I might be wrong. If there is any idea/suggestion, please kindly let me know. Would it be possible for us to use those API's or similar ones to reach out to those statistics and improve our ability to get quicker and more reliable estimations?

Tim, what should happen with this bug now?

Find someone to improve the math in Gonk as pointed out here? https://bugzilla.mozilla.org/show_bug.cgi?id=1178599#c8 That said, it would be better if we could get some opinion from the author and the reviewer of bug 1116368 -- what we are seeing might be entirely hardware-specific and shouldn't be workarounded in Gonk either. Noted that per https://bugzilla.mozilla.org/show_bug.cgi?id=1116368#c10 we are using almost the identical math in Fx Android too.

Danny, Dave, any opinion on this? Anything possible/worth investigating from this bug or bug 1116368 comment 18 in your opinion?

I think that doing a good job of this will probably require some fairly significant research and modelling to come up with a model which works well. I'd expect that we need some type of persistent storage to store the charging/discharging data from which to build the projections. I don't think that "real time" data is actually all that useful. That only tells you how much battery is being used at this instant. I would expect that knowing how much battery is used in a typical "hour" (or some other appropriate time period) would be much more useful. I think that in order to do a good job of this it needs somebody to champion it, and right now, that person can't be me.

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #11) > Danny, Dave, any opinion on this? > > Anything possible/worth investigating from this bug or bug 1116368 comment > 18 in your opinion? I have long time didn't access bugzilla, sorry for late reply. For bug 1116368 comment 18, I already have some comments for it, see bug 1116368 comment c22. The main problem is the battery level from battery driver could be wrong, there are two special cases I met before: 1. Device shutdown at 30% battery level. The root cause is bad battery, so it update the wrong battery level mapping. 2. Battery drain then shutdown quickly at 12% battery level. The root cause is also wrong update from driver, after calibration, battery level goes to 0% so that it drain 12% battery in 2 minutes. Above two cases are hard to avoid by prediction. So, maybe we should not tell the precise remaining time to user, but just rough value, like "battery life will be less than an hour, it depends on user activities." for better user experience. For battery discharging time, I think we can port it from Android, I can help on this if it's still open.

> For battery discharging time, I think we can port it from Android, I can help on this if it's still open. So, I landed battery discharging time in bug 1163245, but it's a clone of battery charging time that you wrote. I believe that it's substantially different from Android's implementation which uses battery capacity and voltage, instead of just time and percentage. Am I wrong here?

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #14) > > For battery discharging time, I think we can port it from Android, I can help on this if it's still open. > > So, I landed battery discharging time in bug 1163245, but it's a clone of > battery charging time that you wrote. I believe that it's substantially > different from Android's implementation which uses battery capacity and > voltage, instead of just time and percentage. Am I wrong here? The algorithm in https://goo.gl/6xkdP4 which you mentioned in comment 7 is what I want to implement before, but the main problem is almost Android devices (Flame, Nexus-5, Nexus-6) didn't export system attribute of full battery capacity (mAh), so we cannot estimate remaining time by capacity and average. I guess the implementation of https://goo.gl/6xkdP4 is not on public Android, at less I didn't find it on http://androidxref.com/ I think all we have done (bug 1163245 and bug 1116368) are similar as Android now.

Danny, could this possibly improve with a move to lollipop? I saw a bunch of APIs in sdk 21 : http://developer.android.com/reference/android/os/BatteryManager.html At the very least I thought we might be able to get an adb shell dumpsys batterystats or adb shell dumpstate to report out the battery status on a lower level.

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #16) > Danny, could this possibly improve with a move to lollipop? > > I saw a bunch of APIs in sdk 21 : > http://developer.android.com/reference/android/os/BatteryManager.html > At the very least I thought we might be able to get an adb shell dumpsys > batterystats or adb shell dumpstate to report out the battery status on a > lower level. There are two useful APIs to improve charging/discharging algorithm, BATTERY_PROPERTY_CAPACITY and BATTERY_PROPERTY_CURRENT_NOW, we can use them in algorithm, https://goo.gl/6xkdP4. As I mentioned on comment15, the main problem is we don't have no system attribute for battery capacity. If no this attribute support, another way is to maintain a power table included battery capacity, such as https://source.android.com/devices/tech/power/values.html. Then we can get what we need and improve the algorithm of charging/discharging time.

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #16) > Danny, could this possibly improve with a move to lollipop? > > I saw a bunch of APIs in sdk 21 : > http://developer.android.com/reference/android/os/BatteryManager.html > At the very least I thought we might be able to get an adb shell dumpsys > batterystats or adb shell dumpstate to report out the battery status on a > lower level. This program has been closed.