I have an idea of adding two new items to the System Details view:
This would allow everyone to monitor the battery drain while using the device (e.g. on more power hungry cores/emulators) and also help users decide whether or not a full charge is needed before taking the handheld out on trips etc.
Very interesting concept, I do like the idea!
The main challenge is that we don’t currently have a guaranteed “last full charge” timestamp exposed by the battery subsystem on all devices (I don’t think?). That means we would either need to read it from the kernel (if available), or start recording our own timestamp whenever a charger state transition occurs (plug, unplug, full etc.).
Suspend complicates things slightly as well. If the device is charging while suspended, the charge state can change without the UI running. To handle this properly, we would need a lightweight background watcher (eurgh) that logs charge events to disk rather than relying on the System Details screen being open.
We would also need to define what “active since last charge” means:
An alternative approach could be simpler? Instead of tracking timestamps, we could log battery percentage at unplug and show “battery used since last unplug” along with current uptime. That would still give users a practical indicator of drain without needing full event tracking. Unless of course that is what you actually meant haha!
I mean it’s definitely possible we just need to define the behaviour clearly first.
I was thinking about the timestamp approach, similar to how phones display that info, but I totally get the difficulty of actually making it happen on a handheld.
I would assume active time would include time in suspension, since we want to get battery drain info regardless of which state the device is in, but as you said, that’s easier said than done.
The alternative solution seems like a good middle ground (at least for the time being), even if the percentage indication is not reliable on those devices.
The more I think of it, the more I believe there’s a straight-forward solution somewhere there. We could update some variables on-demand on a couple of occasions. Also, I might be missing some stuff so bear with me.
Let’s say we store timestamps (temporarily) named last_measurement_timestamp,last_charged_timestamp and time_on_battery (which stores total seconds the device was active or in suspend mode).
When we just started the OS after fresh install, last_charged_timestamp is null, this would result in the UI showing just a - next to the Last Charged and Time on Battery entries in System Details. When last_charged_timestamp has a value, it’s displayed in the UI and Time on Battery gets populated by formatted time_on_battery value.
When starting the device, only one variable gets set:
last_measurement_timestamp = current_timestamp
When opening the System Details, those variables get updated internally like so:
time_on_battery = time_on_battery + current_timestamp - last_measurement_timestamp
last_measurement_timestamp = current_timestamp
When shutting down the device:
time_on_battery = time_on_battery + current_timestamp - last_measurement_timestamp
After you start charging the device, only the moment when you unplug it should get caught. This way it shouldn’t matter if it’s in suspend mode or not.
last_charged_timestamp = current_timestamp
Like I said, I might be missing some crucial details, but that seems like a simple way to get it done.