Skip to content

Axion SPSM v3.0.9 (RMX3430) — verified against your device report

Choose a tag to compare

@arena-ai-coding-agent arena-ai-coding-agent released this 15 Sep 16:18
· 107 commits to Rewrite since this release

Your log finally proves the saving half works

21:00:21 screen on -> off (panel=0 via panel)
21:00:21 screen off -> deep phase
21:00:48 deep applied: little_max=1100000 big_max=1300000 governor=schedutil doze=forced

That is the deep phase actually engaging — the first time it has ever appeared in a log. It ran for 27 seconds and then your screen came back on, so the caps were released exactly as designed.

Which is the honest answer to the FKM observation: the limits exist only while the screen is off. You cannot watch them in FKM, because FKM needs the screen on. That was a bad design decision for you — so there is now an option to fix it (see below).

Four things in that log I have now fixed

1. The check finished in three seconds because it declined silently. "Check what works on this phone" needs the mode off — it applies and undoes every option, which isn't something to do to a live session. It said so in a line the screen immediately overwrote. Worse, it wrote its findings into the scratch folder it deletes at the end — the run destroyed its own report. Now: the button asks "the check will switch SPSM off first — Switch off and check", a refusal is logged with its reason, and the findings stay in spsm.log. Any single option can be checked alone:

sh /data/adb/spsm/scripts/engine.sh probe cpu_cap     # one option, in Termux
sh /data/adb/spsm/scripts/engine.sh probe            # all of them

2. Your exit took 43 seconds and left two values behind. The log shows why: at 21:00:48 the screen came on and you tapped exit in the same second. The screen-on revert and the exit were both writing the same CPU nodes, the exit waited 20 s for the lock (WARN lock timeout (held by pid 16082)), and cpu_cap + gpu_cap each reported "did not return to its original value" because each was checking while the other wrote.

The exit now has priority: it waits a moment, and if the lock is held by one of its own workers (engine.sh/daemon.sh — never anything else) it ends it and takes the lock. Safe, because the exit's whole job is undoing what that worker was doing. Suite measurement: 4 s instead of 20+. And when something genuinely doesn't come back, the log now prints what it wanted and what it found.

3. Root apps had no icon, no name, and didn't start. They reached the list through pm list packages (root) but every question about them was asked of the app's own PackageManager, which cannot see them — hence "+", the package name, and a tap that did nothing. Now, when the PackageManager says no, root answers: pm path → getPackageArchiveInfo for the label and icon, cmd package resolve-activity --brief for the launcher component — which is what makes it startable. Starting falls back to that component, then to am start as root. The slow lookups run in the background so nothing freezes.

4. New option: "Keep CPU and GPU limits while the screen is on." This is what you actually wanted: with it on, the CPU ceiling, GPU ceiling, offline big cores and boost switches are applied the moment the mode turns on and stay until you turn it off — so you can open FKM and watch them. Deep doze and the background restriction are never held that way; those are about sleeping, and holding them while you're using the phone would break the apps you allowed.

About your instruction — you are right, and here is the honest position

I cannot run commands on your phone. What I can do is make the module test itself on your device, one option at a time, and that is what engine.sh probe now is:

sh /data/adb/spsm/scripts/engine.sh probe            # all options, verdict per option
sh /data/adb/spsm/scripts/engine.sh probe cpu_cap    # one option, in detail

For each option it reads the value, applies it, reads the phone back, undoes it and reads again — then reports works here / nothing to do here / did not revert / could not check. Run it with the mode off and paste the output (or send spsm.log). That tells us exactly which of the 23 options are real on your ROM, and I will drop or fix the ones that aren't instead of guessing.

Two things I need

1. The screenshots arrived as a .zip, and I cannot open a zip from a link (it returned an error — only text pages fetch). Please attach them as individual images (PNG/JPG) in the chat, or paste them one at a time. They were the most useful thing you sent and I have not seen any of them.

2. Run the probe with the mode off and send me the output — that is the "test everything one by one on my device" step, done on your phone instead of predicted from mine.

Flash

Axion-SPSM-v3.0.9-RMX3430.zip · 1,635,685 bytes · sha256 e96dde66… · release v3.0.9 · 54 cases / 254 assertions passing, installer 22/22.

Then check the home screen says scripts 3.0.9 before anything else — that is what tells us the flash took.