Screen_off policy overrides low_power policy (

[vitovt]

High-performance cores (cpu6/cpu7) re-enabled after screen unlock in Low Power mode

App/Module: XtremeBS (Xtreme Battery Saver)
Version: 2.1.3
Device: MTK Dimensity 7025 CPU, Android 15
Root environment: Magisk

Configuration:

low_power={
  keep_on_charge=true
  handle_cores=cpu0 cpu1 cpu2
  disable_cores=cpu3 cpu4 cpu5 cpu6 cpu7
  handle_apps=nice
  handle_gms=false
  handle_proc=false
  low_ram=false
  doze=false
  kill_wifi=false
}
screen_off={
  handle_cores=cpu0 cpu1 cpu2 cpu3 cpu4 cpu5
  disable_cores=cpu6 cpu7
  handle_apps=nice
}

Steps to reproduce:

1. Enable Low Power mode.
2. Verify that cpu3–cpu7 are disabled as expected.
3. Turn screen off → cores behave as configured (cpu6/7 disabled, cpu3–5 disabled).
4. Unlock the screen.

Expected behavior:
Low Power restrictions should remain active after screen unlock (cpu3–cpu7 stay offline).

Actual behavior:
On screen unlock, the screen_off event undo action resets CPU configuration and re-enables cpu6 and cpu7, even though Low Power mode is still active.

Logs:

• Low Power applied → cores disabled correctly.

08-25-2025 11:58:56 [VERBOSE] Low Power event was triggered
08-25-2025 11:58:56 [DEBUG] Parsing the config for low_power event
08-25-2025 11:58:57 [INFO] Performing actions for low_power event
08-25-2025 11:58:57 [DEBUG] Disabling cpu3
08-25-2025 11:58:57 [DEBUG] Disabling cpu4
08-25-2025 11:58:57 [DEBUG] Disabling cpu5
08-25-2025 11:58:57 [DEBUG] Disabling cpu6
08-25-2025 11:58:57 [DEBUG] Disabling cpu7
08-25-2025 11:58:57 [DEBUG] Setting powersave on cpu0
08-25-2025 11:58:57 [DEBUG] Setting powersave on cpu1
08-25-2025 11:58:57 [DEBUG] Setting powersave on cpu2
08-25-2025 11:58:57 [INFO] Actions for low_power completed

cpu0: powersave
cpu1: powersave
cpu2: powersave
cpu3: offline
cpu4: offline
cpu5: offline
cpu6: offline
cpu7: offline
Low RAM: 
WiFi: enabled
Doze: inactive

• Screen off → cores disabled as expected.

08-25-2025 12:00:01 [VERBOSE] Screen change was detected
08-25-2025 12:00:01 [DEBUG] Parsing the config for screen_off event
08-25-2025 12:00:02 [INFO] Performing actions for screen_off event
08-25-2025 12:00:02 [DEBUG] Disabling cpu6
08-25-2025 12:00:02 [DEBUG] Disabling cpu7
08-25-2025 12:00:02 [DEBUG] Setting powersave on cpu0
08-25-2025 12:00:03 [DEBUG] Setting powersave on cpu1
08-25-2025 12:00:03 [DEBUG] Setting powersave on cpu2
08-25-2025 12:00:03 [DEBUG] Setting powersave on cpu3
08-25-2025 12:00:03 [DEBUG] Setting powersave on cpu4
08-25-2025 12:00:03 [DEBUG] Setting powersave on cpu5
08-25-2025 12:00:05 [INFO] Actions for screen_off completed

cpu0: powersave
cpu1: powersave
cpu2: powersave
cpu3: offline
cpu4: offline
cpu5: offline
cpu6: offline
cpu7: offline
Low RAM: 
WiFi: enabled
Doze: inactive

• Screen unlock → “Undoing actions for screen_off” restores cpu6/7 online.

08-25-2025 12:00:53 [VERBOSE] Screen change was detected
08-25-2025 12:00:53 [DEBUG] Parsing the config for screen_off event
08-25-2025 12:00:54 [INFO] Undoing actions for screen_off
08-25-2025 12:00:54 [DEBUG] Enabling cpu6
08-25-2025 12:00:54 [DEBUG] Enabling cpu7
08-25-2025 12:00:54 [DEBUG] Resetting cpu0
08-25-2025 12:00:54 [DEBUG] Resetting cpu1
08-25-2025 12:00:54 [DEBUG] Resetting cpu2
08-25-2025 12:00:54 [DEBUG] Resetting cpu3
08-25-2025 12:00:54 [DEBUG] Resetting cpu4
08-25-2025 12:00:54 [DEBUG] Resetting cpu5
08-25-2025 12:00:55 [INFO] Actions for screen_off undo

cpu0: online
cpu1: online
cpu2: online
cpu3: offline
cpu4: offline
cpu5: offline
cpu6: online
cpu7: online
Low RAM: 
WiFi: enabled
Doze: inactive

Notes:
It looks like the screen_off event undo overrides the low_power event settings.

High-performance cores (cpu6/cpu7) are re-enabled after screen unlock in Low Power mode
Question: Is this intended behavior, or should Low Power settings persist regardless of screen unlock?

[DethByte64]

This is working as intended.

[vitovt]

Then how to implement scheme, when in Low Power mode High Power cores are always disabled ?

Because it is a bit unlogical, when in Low Power mode High Power CPUs activated.
Sorry maybe for a dumb question, but I really cannot find out how to implement it (

[DethByte64]

You are looking for a custom event which can be defined by writing something like this in your config:

my_costom_event={
disable_cores=auto
}

And you would trigger that using XBSctl via a tasker task or similar.

Maybe i should write a priority system to handle this edge case but i am quite busy nowadays. You are welcome to PR if you like.

[vitovt]

I have a beta version that would fix this issue, if you would like to test it. Its stable and has the prediction in it too. Will you test it?

Yes, I'd like to test it. Super!

…

Message ID: ***@***.*** com>

[DethByte64]

I have a beta version that would fix this issue, if you would like to test
it. Its stable and has the prediction in it too. Will you test it?
Yes, I'd like to test it.
Super!
…

Hold up, i just tested it on a burner and the events actions werent being reverted. Soon though. Lucky i found out before you did, it ended up crashing my device a couple times. This feature will make it to the next release. Along with battery prediction which works flawlessly.

[vitovt]

Hold up, i just tested it on a burner and the events actions werent being reverted. Soon though. Lucky i found out before you did, it ended up crashing my device a couple times. This feature will make it to the next release. Along with battery prediction which works flawlessly.

Ok. Thank you very much for your work!

…

Message ID: ***@***.*** com>

[vitovt]

IMHO the logic should work in this way:
There are four main modes (states):

• NORMAL – default mode after boot.
• LOW_POWER – active when system Battery Saver is on.
• CHARGING – active when device is connected to power.
• PERFORMANCE – manual mode, activated by a custom event, presense of .powerperformance file on sd card, etx. Can be used Tasker, or similar app.

Each mode can also have a screen on/off sub-state.
When the screen turns on again, the profile should go back to the current active mode.

Screen on/off can be designed in two ways:

• as a separate event,
• or as a sub-state inside each profile.

Example:

[profiles.NORMAL.screen.on]
[profiles.NORMAL.screen.off]
[profiles.LOW_POWER.screen.on]
[profiles.LOW_POWER.screen.off]
...

Additional notes:

• Profiles can support inheritance (e.g. inherits = NORMAL) so only differences need to be written. This reduces duplication.
• Best practice is to calculate a diff between the current state and the desired state, and then apply only the needed changes. But because reading current state may not work on all hardware, another option is to reset all parameters and then re-apply the desired profile. This gives some overhead but is safe.
• If a profile tries to disable all cores in one cluster, always keep at least one little CPU online.
• Add default application whitelist, which prevents unresponsible states on most phones

[DethByte64]

The result is stable, so long as your config is stable.
My testing shows that it works as intended. No new config options were added, it just fixes this github issue.
The results should show that when you have conflicting config options, they are respected. (Watch logs and status page to confirm this)

Also added was a queue to handle multiple incoming event triggers. Now, instead of just dropping them, incoming events are either removed (conflicting action for event in queue. eg. enable + disable), skipped(duplicate action for event in queue. eg. enable + enable), or added(not in queue) depending on what is in the queue already. This runs in a seperate thread.

And of course, battery prediction with a graph for viewing historical data. It requires 2 battery level changes before it will start giving predictions or plotting the graph for accuracy.

Let me know how it runs for you. If it works as expected for 24h, it will be released as v2.2.0. Ill be testing along with you.

XtremeBS-v2.2.0-beta.zip

[vitovt]

First of all, thank you very much for your work 🙏.
I've tested the new beta in low_power mode only for now.

My current config

version=2
delay=3
log_file=/sdcard/XtremeBS.log
log_level=3

low_power={
  notify=true
  keep_on_charge=true
  handle_cores=cpu0 cpu1 cpu2
  disable_cores=cpu3 cpu4 cpu5 cpu6 cpu7
  handle_apps=nice
  allowlist=/data/local/tmp/XtremeBS/apps.allow
  denylist=/data/local/tmp/XtremeBS/apps.deny
  handle_gms=false
  handle_proc=false
  proc_file=/data/local/tmp/XtremeBS/proc.list
  low_ram=false
  doze=false
  kill_wifi=false
}

charging={
}

screen_off={
  handle_cores=cpu0 cpu1 cpu2 cpu3 cpu4 cpu5
  disable_cores=cpu6 cpu7
  handle_apps=nice
  doze=light
}

manual={
}

boot={
  handle_gms=nice
  handle_cores=auto
}

Observations

• When screen is off, everything looks fine.

• When screen is on, sometimes cpu6 and cpu7 are enabled again. After some delay, low_power runs again and disables them.

• I see quite a long delay between “screen change detected” and actions applied (sometimes ~40 sec).

• Sometimes the sequence is:

  • low_power applies,
  • screen_off applies,
  • screen_off undo runs,
  • boot runs again,
  • low_power applies again.
    This makes cores go online and offline again.

• If I leave screen off, then after events finish there are no new changes in log for at least 15 minutes (stable).

• If I leave screen on, the system is also stable for ~10 minutes without changes.

Impression

• The module is working correctly in general.
• The main problem I see is the delay before actions are applied after screen change.
• For daily use this delay is not critical (maybe even good, to avoid too many switches).
• But for debugging and testing, it is not very clear what happens and when.

p.s. here is the log after screen ON in power_save mode:

08-29-2025 08:11:39 [VERBOSE] Screen change was detected
===(here is long enough delay)===
08-29-2025 08:12:17 [DEBUG] Disabling cpu3
08-29-2025 08:12:17 [DEBUG] Disabling cpu4
08-29-2025 08:12:17 [DEBUG] Disabling cpu5
08-29-2025 08:12:17 [DEBUG] Disabling cpu6
08-29-2025 08:12:17 [DEBUG] Disabling cpu7
08-29-2025 08:12:18 [DEBUG] Setting powersave on cpu0
08-29-2025 08:12:18 [DEBUG] Setting powersave on cpu1
08-29-2025 08:12:18 [DEBUG] Setting powersave on cpu2
08-29-2025 08:12:20 [INFO] Actions for low_power completed
08-29-2025 08:12:20 [DEBUG] Parsing the config for screen_off event
08-29-2025 08:12:21 [INFO] Performing actions for screen_off event
08-29-2025 08:12:21 [DEBUG] Enabling light Doze mode
08-29-2025 08:12:22 [DEBUG] Disabling cpu6
08-29-2025 08:12:22 [DEBUG] Disabling cpu7
08-29-2025 08:12:22 [DEBUG] Setting powersave on cpu0
08-29-2025 08:12:22 [DEBUG] Setting powersave on cpu1
08-29-2025 08:12:22 [DEBUG] Setting powersave on cpu2
08-29-2025 08:12:23 [DEBUG] Setting powersave on cpu3
08-29-2025 08:12:23 [DEBUG] Setting powersave on cpu4
08-29-2025 08:12:23 [DEBUG] Setting powersave on cpu5
08-29-2025 08:12:25 [INFO] Actions for screen_off completed
08-29-2025 08:12:25 [VERBOSE] Processing queue entry: screen_off,0
08-29-2025 08:12:25 [DEBUG] Parsing the config for screen_off event
08-29-2025 08:12:26 [INFO] Undoing actions for screen_off
08-29-2025 08:12:26 [DEBUG] Enabling cpu6
08-29-2025 08:12:26 [DEBUG] Enabling cpu7
08-29-2025 08:12:27 [DEBUG] Resetting cpu0
08-29-2025 08:12:27 [DEBUG] Resetting cpu1
08-29-2025 08:12:27 [DEBUG] Resetting cpu2
08-29-2025 08:12:27 [DEBUG] Resetting cpu3
08-29-2025 08:12:27 [DEBUG] Resetting cpu4
08-29-2025 08:12:27 [DEBUG] Resetting cpu5
08-29-2025 08:12:27 [DEBUG] Disabling Doze mode
08-29-2025 08:12:27 [INFO] Actions for screen_off undone
08-29-2025 08:12:27 [DEBUG] Parsing the config for boot event
08-29-2025 08:12:28 [INFO] Performing actions for boot event
08-29-2025 08:12:28 [DEBUG] Renicing GMS
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu0
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu1
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu2
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu3
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu4
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu5
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu6
08-29-2025 08:12:28 [DEBUG] Setting powersave on cpu7
08-29-2025 08:12:29 [INFO] Actions for boot completed
08-29-2025 08:12:29 [DEBUG] Parsing the config for low_power event
08-29-2025 08:12:30 [INFO] Performing actions for low_power event

#and as a result:
cpu0: powersave
cpu1: powersave
cpu2: powersave
cpu3: offline
cpu4: offline
cpu5: offline
cpu6: powersave
cpu7: powersave
Low RAM: 
WiFi: enabled
Doze: inactive

#In another words cpu6 and 7 are again active. But just in a few seconds (Screen is still active):

08-29-2025 08:12:51 [DEBUG] Disabling cpu3
08-29-2025 08:12:51 [DEBUG] Disabling cpu4
08-29-2025 08:12:51 [DEBUG] Disabling cpu5
08-29-2025 08:12:51 [DEBUG] Disabling cpu6
08-29-2025 08:12:51 [DEBUG] Disabling cpu7
08-29-2025 08:12:52 [DEBUG] Setting powersave on cpu0
08-29-2025 08:12:52 [DEBUG] Setting powersave on cpu1
08-29-2025 08:12:52 [DEBUG] Setting powersave on cpu2
08-29-2025 08:12:53 [INFO] Actions for low_power completed
08-29-2025 08:12:54 [VERBOSE] Processing queue entry: screen_off,1
08-29-2025 08:12:54 [DEBUG] Parsing the config for screen_off event
08-29-2025 08:12:55 [INFO] Performing actions for screen_off event
08-29-2025 08:12:55 [DEBUG] Enabling light Doze mode
08-29-2025 08:12:55 [DEBUG] Disabling cpu6
08-29-2025 08:12:55 [DEBUG] Disabling cpu7
08-29-2025 08:12:56 [DEBUG] Setting powersave on cpu0
08-29-2025 08:12:56 [DEBUG] Setting powersave on cpu1
08-29-2025 08:12:56 [DEBUG] Setting powersave on cpu2
08-29-2025 08:12:56 [DEBUG] Setting powersave on cpu3
08-29-2025 08:12:56 [DEBUG] Setting powersave on cpu4
08-29-2025 08:12:57 [DEBUG] Setting powersave on cpu5
08-29-2025 08:12:58 [INFO] Actions for screen_off completed
08-29-2025 08:12:58 [DEBUG] Parsing the config for boot event
08-29-2025 08:12:59 [INFO] Performing actions for boot event
08-29-2025 08:12:59 [DEBUG] Renicing GMS
08-29-2025 08:12:59 [DEBUG] Setting powersave on cpu0
08-29-2025 08:13:00 [DEBUG] Setting powersave on cpu1
08-29-2025 08:13:00 [DEBUG] Setting powersave on cpu2
08-29-2025 08:13:00 [DEBUG] Setting powersave on cpu3
08-29-2025 08:13:00 [DEBUG] Setting powersave on cpu4
08-29-2025 08:13:00 [DEBUG] Setting powersave on cpu5
08-29-2025 08:13:00 [DEBUG] Setting powersave on cpu6
08-29-2025 08:13:00 [DEBUG] Setting powersave on cpu7
08-29-2025 08:13:02 [INFO] Actions for boot completed
08-29-2025 08:13:02 [DEBUG] Parsing the config for low_power event
08-29-2025 08:13:06 [INFO] Performing actions for low_power event

#and
cpu0: powersave
cpu1: powersave
cpu2: powersave
cpu3: offline
cpu4: offline
cpu5: offline
cpu6: offline
cpu7: offline
Low RAM: 
WiFi: enabled
Doze: inactive

[vitovt]

And another test. I try to start custom performance event manually.

WP55:/data/local/tmp/XtremeBS # XBSctl start performance

this part of config:

performance={
handle_cores=false
disable_cores=false
handle_gms=false
doze=false
low_ram=false
}

08-29-2025 10:19:29 [INFO] The start command was received. Attempting to start performance
08-29-2025 10:19:30 [VERBOSE] Processing queue entry: performance,1
08-29-2025 10:19:30 [DEBUG] Parsing the config for performance event
08-29-2025 10:19:30 [INFO] Performing actions for performance event
08-29-2025 10:19:31 [INFO] Actions for performance completed
08-29-2025 10:19:31 [DEBUG] Parsing the config for boot event
08-29-2025 10:19:31 [INFO] Performing actions for boot event
08-29-2025 10:19:31 [DEBUG] Renicing GMS
08-29-2025 10:19:32 [DEBUG] Enabling light Doze mode
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu0
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu1
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu2
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu3
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu4
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu5
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu6
08-29-2025 10:19:32 [DEBUG] Setting powersave on cpu7
08-29-2025 10:19:33 [INFO] Actions for boot completed
08-29-2025 10:19:33 [DEBUG] Parsing the config for performance event
08-29-2025 10:19:33 [INFO] Performing actions for performance event
08-29-2025 10:19:34 [INFO] Actions for performance completed

Expected behaviour: all cpus are online and doze disabled.

Real behaviour:

cpu0: powersave
cpu1: powersave
cpu2: powersave
cpu3: powersave
cpu4: powersave
cpu5: powersave
cpu6: powersave
cpu7: powersave
Low RAM: 
WiFi: enabled
Doze: light

As I understood: false does nothing and that's why performance event can't override default boot behaviour.
Than how can I run custom performance mode overriding default energysaving settings ?
It looks like I need something like none instead of false in settings.

By the way, I didn't understand how to disable custom event then ? Running XBSctl start boot seems didn't cancel, but I'm not sure ...

[vitovt]

Delay when disabling low_power

I also see a long delay when disabling low_power.
It took about 2.5 minutes from the moment I pressed the button to disable low_power until the actions were really done.

Maybe the reason is that some CPUs are disabled and the phone becomes slower.
This is acceptable for daily use, but it would be good to mention this delay in the documentation.

Log

08-29-2025 10:13:04 [INFO] Performing actions for low_power event
08-29-2025 10:14:52 [DEBUG] Renicing GMS
08-29-2025 10:14:53 [DEBUG] Enabling deep Doze mode
08-29-2025 10:14:53 [DEBUG] Disabling cpu3
08-29-2025 10:14:53 [DEBUG] Disabling cpu4
08-29-2025 10:14:53 [DEBUG] Disabling cpu5
08-29-2025 10:14:54 [DEBUG] Disabling cpu6
08-29-2025 10:14:54 [DEBUG] Disabling cpu7
08-29-2025 10:14:54 [DEBUG] Setting powersave on cpu0
08-29-2025 10:14:54 [DEBUG] Setting powersave on cpu1
08-29-2025 10:14:55 [DEBUG] Setting powersave on cpu2
08-29-2025 10:14:57 [INFO] Actions for low_power completed
08-29-2025 10:14:58 [VERBOSE] Processing queue entry: low_power,0
08-29-2025 10:14:58 [DEBUG] Parsing the config for low_power event
08-29-2025 10:15:03 [INFO] Undoing actions for low_power
08-29-2025 10:15:03 [DEBUG] Enabling cpu3
08-29-2025 10:15:03 [DEBUG] Enabling cpu4
08-29-2025 10:15:03 [DEBUG] Enabling cpu5
08-29-2025 10:15:03 [DEBUG] Enabling cpu6
08-29-2025 10:15:03 [DEBUG] Enabling cpu7
08-29-2025 10:15:03 [DEBUG] Resetting cpu0
08-29-2025 10:15:03 [DEBUG] Resetting cpu1
08-29-2025 10:15:03 [DEBUG] Resetting cpu2
08-29-2025 10:15:03 [DEBUG] Disabling Doze mode
08-29-2025 10:15:22 [DEBUG] Resetting the nice level for GMS
08-29-2025 10:15:23 [INFO] Actions for low_power undone
08-29-2025 10:15:23 [DEBUG] Parsing the config for boot event
08-29-2025 10:15:24 [INFO] Performing actions for boot event
08-29-2025 10:15:24 [DEBUG] Renicing GMS
08-29-2025 10:15:24 [DEBUG] Enabling light Doze mode
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu0
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu1
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu2
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu3
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu4
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu5
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu6
08-29-2025 10:15:24 [DEBUG] Setting powersave on cpu7
08-29-2025 10:15:25 [INFO] Actions for boot completed

[DethByte64]

I too have noticed the delays, it seems to be caused by the queue processor, file locks, how much cpu power is available at the time, what your delay is set to, and the core components.

While it may be stable with lighter configs, it will lock a CPU up if it has a heavy config which hampers almost all cpu power. If the event that applied this was boot, low_power or screen_off, not even a hard reboot would save anyone from this, as it would see the triggers for it on startup and immediately apply the events config on boot. safemode would be required and possibly an uninstall via adb. (This was an actual event that occurred on my daily driver - not fun)

As I understood: false does nothing and that's why performance event can't override default boot behaviour.
Than how can I run custom performance mode overriding default energysaving settings ?
It looks like I need something like none instead of false in settings.

XtremeBS is a battery saving module, not a performance module. To implement a "none" option for event actions would require another major version bump, almost a full rewrite, and automatic config migration to not break users existing flows. To get around this, you could use safemode.

By the way, I didn't understand how to disable custom event then ? Running XBSctl start boot seems didn't cancel, but I'm not sure ...

XBSctl stop <event> would do this

I think im going to have to rewrite the config mangling again to be more robust in its handling. This should solve the delay issues and cpu lock ups.

I wouldnt call this beta stable enough for a release.

[vitovt]

Thank you very much for your work 🙏. I really appreciate the time and effort you put into this project.

Please do not take my bug report as a complaint. It is only testing and feedback from a new user who tries to understand the module and get the functions that look obvious at first sight. I only wanted to share my experience so it may help improve the module.

In the current state the module is already very good for me. It reduced my phone’s power usage several times, and on my Mediatek device it works very stable. For daily use it is more than enough, and I am happy with the results.