Both laptop and smartphones/tablet devices are battery-powered ones.
One could think they should have similar abilities for power-related crunching configurations.

But nope.
BOINC for laptops (actually, usual Winx64 one cause no special version):

- has ability to stop crunching if on battery.
- can't operate until battery x% empty.

So, it's not possible to implement crunching during short power cord unplugging (in case crunching on battery disallowed). Tasks will be suspended/resumed with corresponding overhead.

BOINC for smartphones:

- can operate until battery x% empty
-can't detect if power cord plugged (! this implemented in NativeBOINC of course, but that app incompatible with new devices)

So, if battery discharged enough but phone placed on charger, BOINC will not continue until battery will be charged until x%. That can take few hours of inefficient idling through the night.

Can we have BOINC options that will consistently implement power management of battery containing devices?

That is:
1) separate states for plugged/battery computations
2) separate state being on battery x% discharged.

That is, merge abilities of both BOINC versions, nothing really new required.

This will allow efficiently configure for operation in both mentioned scenarios.

---

Raistmer wrote:

Both laptop and smartphones/tablet devices are battery-powered ones.
One could think they should have similar abilities for power-related crunching configurations.

But nope.
BOINC for laptops (actually, usual Winx64 one cause no special version):

- has ability to stop crunching if on battery.
- can't operate until battery x% empty.

So, it's not possible to implement crunching during short power cord unplugging (in case crunching on battery disallowed). Tasks will be suspended/resumed with corresponding overhead.

This is the original implementation. The reasoning is that if a device goes on battery power you want to consume as much power as possible and suspend non-critical (BOINC) processes until power is restored.

Raistmer wrote:

BOINC for smartphones:

- can operate until battery x% empty
-can't detect if power cord plugged (! this implemented in NativeBOINC of course, but that app incompatible with new devices)

So, if battery discharged enough but phone placed on charger, BOINC will not continue until battery will be charged until x%. That can take few hours of inefficient idling through the night.

This is the implementation that was developed after the first BOINC for Android versions. BOINC on Android should be able to detect if the device is plugged in or not, if taht is not working anymore, that is clearly a bug in the software. I haven't seen complaints about this, feel free to open a github issue with a way to reproduce this. The feature that computation is stopped until the power level reached a certain threshold again stems from the fact that a lot of chargers are not designed to load the battery when the device is 100% busy. This lead to high temperature and strain on the battery. So this setting was implemented for Android only. The usefulness for non-Android is debatable as we would need to gather the battery power level which is more difficult on non-Android.

Raistmer wrote:

Both laptop and smartphones/tablet devices are battery-powered ones.
One could think they should have similar abilities for power-related crunching configurations.

But nope.
BOINC for laptops (actually, usual Winx64 one cause no special version):

- has ability to stop crunching if on battery.
- can't operate until battery x% empty.

So, it's not possible to implement crunching during short power cord unplugging (in case crunching on battery disallowed). Tasks will be suspended/resumed with corresponding overhead.

This is the original implementation. The reasoning is that if a device goes on battery power you want to consume as much power as possible and suspend non-critical (BOINC) processes until power is restored.

So this reasoning doesn't apply to smartphones/tablets?
As with many other things reasoning better not to apply to presumed user needs.
Just because reasoning not applicable to needs themselves.
For example I need better usage of my PC processing power with reasonable enough time of processing on battery. So, ability to set battery % to something low than 100% will much better suit my needs than current implementation. And very that fact, that battery % was implemented for other device type just illustrates this. It's not question of reasoning, it's the question of usability. And it can be improved.

BOINC for smartphones:

- can operate until battery x% empty
-can't detect if power cord plugged (! this implemented in NativeBOINC of course, but that app incompatible with new devices)

So, if battery discharged enough but phone placed on charger, BOINC will not continue until battery will be charged until x%. That can take few hours of inefficient idling through the night.

This is the implementation that was developed after the first BOINC for Android versions. BOINC on Android should be able to detect if the device is plugged in or not, if taht is not working anymore, that is clearly a bug in the software. I haven't seen complaints about this, feel free to open a github issue with a way to reproduce this.

I don't claim it doesn't sense charger, I state that it doesn't act correctly after detection (if it takes place). More precisely, not all needed correct actions provided.

The feature that computation is stopped until the power level reached a certain threshold again stems from the fact that a lot of chargers are not designed to load the battery when the device is 100% busy. This lead to high temperature and strain on the battery. So this setting was implemented for Android only. The usefulness for non-Android is debatable as we would need to gather the battery power level which is more difficult on non-Android.

Again, why attempt to think instead of others and restrict possibilities of tuning?
Well, some chargers can sustain increased load well, some batteries don't produce so much heat. Make reasonably conservative defaults, but provide ability of tuning to non-default configs.
I'm using NativeBOINC for few years already on my android devices and intensively using ability to crunch being on charge. It works and device temperature more than OK as well as the ability to charge. So this reasoning fails as general case. There is example that doesn't fit in it.

I understand that implementation of more sophisticated battery handling on non-Android platform will require some extension. But taking into account how many apps report battery level under Windows (at least) hardly it's much complex than calling API function.
And all logic how to handle particular % is already presents.

---

I didn't say the original reasoning is still applicable, I just wanted to give some background on how the battery related settings diverged. I also think that it may be better to combine those two settings in the future. Another problem is that Android doesn't honor the web preferences but always uses local preferences. This could lead to cases where people change web preferences that only apply to non-Android devices but they think those settings also apply to Android devices. This would mean more warning messages when changing preferences and who really reads warning messages nowadays?

Back to the combined settings. How would such settings look like? You need to have settings that allow to set thresholds for the desired hysteresis behavior and you want a setting that disables the hysteresis behavior (which is potentially dangerous).

• Suspend when computer is on battery yes/no
  
• Suspend computation if battery level is below value
  
• Suspend computation above battery temperature of value
  
• Start computation again if battery level is above value
  
• Start computation again if battery temperature is below value
  

If the first one is set to yes it would override every other setting. If it is set to no the other settings would be in effect. Therefore a better naming seems appropriate (always, thresholds).

The other settings control the hysteresis behavior we need on Android and can be configured to other behaviors. This would solve the currently hardcoded limit on battery power you are complaining about.

The question still is if we can extract the battery level and temperature for all platforms (not just Windows and Android) in a reliable and future proof way. Until that is not solved all of the above settings would need a warning label like: "Only applies to Windows v7.8+ and Android v7.6+" which is not ideal. If we are improving the settings we should do it for all platforms.

I did a cursory search for a Windows API call to retrieve battery level. I found an API call that retrieves a SYSTEM_POWER_STATUS structure which only contains a flag that reports battery level as High, Low, Critical no percentages.

On Linux it seems to be way easier than I expected. There is a tool (upower, needs to be investigated if this is widely available) that can even retrieve the battery level of my wireless keyboard and mouse and newer kernels provide this info in /sys/class/power_supply/. Further info: How to check battery status using terminal?

Sounds good, thanks for diving into that topic.

Here is interesing info regarding battery & Win8+:
http://www.howtogeek.com/217010/how-to-generate-a-battery-health-report-on-windows-8-or-windows-10/
More complex than just APUI call though. PArsing of html file would required.

---

And here is API-retrievable Windows structure:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa373232(v=vs.85).aspx

typedef struct _SYSTEM_POWER_STATUS {
  BYTE  ACLineStatus;
  BYTE  BatteryFlag;
  BYTE  BatteryLifePercent;
  BYTE  SystemStatusFlag;
  DWORD BatteryLifeTime;
  DWORD BatteryFullLifeTime;
} SYSTEM_POWER_STATUS, *LPSYSTEM_POWER_STATUS;

BatteryLifePercent
The percentage of full battery charge remaining. This member can be a value in the range 0 to 100, or 255 if status is unknown.

Sounds good enough, no?

---

Any chance to get these improvements in next BOINC releases?

---

Any chance to get these improvements in next BOINC releases?

Short answer: no. Longer answer: it is right now unclear when the next release is going to be or what it will contain

I created an issue to track progress of this but it is up to you (as the one who wants to have it implemented) to find someone who is willing to spend time on this. BOINC is a community project now and has no dedicated developers anymore. So any request for a change or a new functionality is done in the spare time of volunteers which set their own priorities. If you want to bump priority you need to convince people that it is worth there while to do this or do it yourself and create a pull request.

Thanks.

---