What this is: the first release of MaxManager — a control panel for rooted Android phones.
Works on: Android 10 or newer · Magisk, KernelSU or KernelSU Next
Download:MaxManager-v1.0-module.zip— flash it in your root manager. Its checksums are the second file.
Since this is 1.0, everything below is new. There is no earlier version to compare against.
In one minute
MaxManager helps you make a rooted phone smoother, cooler, or longer-lasting — and it only offers
you settings your phone can actually do.
That sounds obvious, but it is the whole point. Most tuning apps give you hundreds of switches, and
half of them do nothing on your phone. MaxManager looks at your phone first, so:
- A setting your phone does not support simply is not shown. No dead switches.
- Every change is checked. If the phone did not accept it, you are told — not shown a green tick.
- When the app does not know a number, it says so. It never shows
0to look tidy. - Nothing runs until you turn it on. No hidden automation, and nothing is sent anywhere — ever.
What is inside 1.0 — the whole list
| # | Area | In one line |
|---|---|---|
| 1 | Profiles | Five one-tap behaviours you can apply, tune, save and share — and switch from Quick Settings |
| 2 | Nine control areas | CPU, GPU, memory, display, responsiveness, thermal, power, storage & compiler, network |
| 3 | One app at a time | Give one app its own profile, refresh rate, resolution, thermal ceiling and governors |
| 4 | Charging & battery health | Charge ceiling, current limits, bypass charging, doze, battery health |
| 5 | The on-screen panel | FPS, frame time, CPU, RAM, power, battery heat and renderer over any game — four looks |
| 6 | What is running now | Process list with CPU and RAM per app, force-stop, SIGKILL, a floating panel |
| 7 | Logs & diagnostics | Live logs with search, route health for every control, a device blueprint, a report you choose to send |
| 8 | The tools shelf | Property editor, activity launcher, root file manager, permissions, backups, freezing, plugins, module health |
| 9 | Look and language | Themes, a colour scheme, 84 languages, real right-to-left support |
| 10 | Max Atlas | Finds what your phone supports — and proves what it does not have |
| 11 | Max AI | Off by default: changes one thing, measures whether it helped, remembers |
| 12 | The safeties | One write path, read-back verification, undo, and a list it never touches |
Where to start
You do not need all 53 screens. These five cover what most people want:
| If you are… | Open this | And you get |
|---|---|---|
| Just want a better phone | Profiles (home screen or Quick Settings) | Cooler and calmer, in one tap |
| Playing games | Apps → your game → Gaming | Its own settings; nothing else on the phone changes |
| Curious about the numbers | FPS panel and Home | Live readings over your game and inside the app |
| Charging overnight | Control → Power → charging | Less battery wear over time |
| Into the details | Control (the nine areas) and Control → Tools | Everything else |
Everything else is there when you want it — nothing is missing, it is just not shouting at you.
Profiles — one tap, and what a profile really is
A profile is a named set of behaviour you can apply, tune, save and share:
- Power — cool and frugal.
- Balanced — the everyday baseline.
- Gaming — the GPU held in its upper range for steadier frame pacing.
- Performance — full capability, held as far as the hardware allows.
- Custom — yours.
Two things make profiles more than bookmarks:
- They are shareable, and the source travels with the number. On export, each value carries where it
came from — a shipped default, a value you changed yourself, or a measurement claimed by whoever
exported the file. On import the app says exactly what it accepted and what it refused, and a profile
made on another chipset says so out loud: a value measured over there is not a measurement over here. - They are reachable from Quick Settings. One tile switches the profile without opening the app, and
a second tile drives bypass charging.
The nine control areas — everything you can change
Nine areas, each in its own hub. The line in italics is the app’s own one-line description of that area.
CPU — cores, governor, vendor boost and kernel preferences
- Turn individual cores on or off.
- Pin scheduling groups to clusters, and set a floor and a ceiling per cluster.
- Choose governors.
- Edit kernel preferences, and the vendor boost controls.
GPU — GPU frequencies and graphics-specific vendor parameters
- Frequency presets and manual bounds.
- The GPU governor.
- Shader-core power policy.
- The vendor boost pipeline.
- A documented thermal-throttle bypass.
Memory — compression, VM behaviour and swappiness
- Size ZRAM or turn it off.
- Pick the compression engine.
- Tune swappiness and reclaim.
The engine reads memory stall pressure, not fill percentage: a nearly-full-but-idle phone and a phone
that is actually stalling need opposite responses, and the app tells them apart.
Display — refresh rate, colour and canvas scale
- Refresh rate.
- Colour channels, saturation, gamut and HDR response.
- Brightness curves and night light.
- Animation scales and screen timeout.
- Render resolution (its own screen).
Responsiveness — touch, frame pacing and scheduling latency
- Touch sampling rate and smoothing.
- Double-tap to wake.
- FPS GO / GED parameters.
- Frame-aware scheduling.
Thermal — temperatures, throttling and thermal parameters
- Live zone temperatures.
- Thermal policy, and what your device is throttling right now.
The safety limits themselves are never written — that is the one rule this project does not bend.
Power — charging, bypass, sleep and battery health
- Charge current limits.
- A charge ceiling to slow battery wear.
- Bypass charging, plus a separate check screen that confirms bypass is really working.
- Aggressive doze and the standby whitelist.
- Battery health.
Storage & compiler — compilation mode and storage health
- Re-run ART compilation with a filter you choose.
- Reset compiled state.
- Storage health.
Network — traffic scheduling and link state
- TCP congestion algorithm.
- Fast-open, SACK and ECN.
- SYN cookies and socket reuse.
- I/O scheduler tunables and link state.
Anything your device does not expose in one of these areas is simply not listed. No dead switches.
One app at a time — per-app control
Open Apps, pick an app, and give it its own treatment without touching the rest of the system:
- performance profile (Power / Balanced / Gaming / Performance / Custom)
- refresh rate
- render resolution
- thermal ceiling
- CPU governor and GPU governor — only the ones your kernel reports, and only governors supported
by all CPU policies - foreground priority lock
- I/O priority boost
- a per-app reset that puts just that app back
Every app shows its effective state in plain words: per-app control is off · using the global
profile · app override active. While a game with its own profile is in front, Max AI switches to
monitoring only and stops changing things.
There is also a screen for debloat and freeze, and “why didn’t it work?” for a per-app setting:
what it wanted, what the hardware is holding, and where to look next.
The panel over your game
A floating readout you can drag anywhere over any game. It does not cover your whole screen, and it does
not steal frames.
What it can show — you choose; only the fields you want appear:
- Frames per second, from the chosen source, with a fallback reading method when the first one
cannot be read. - Frame time in milliseconds — the number that tells you whether a game feels smooth. 60 and 55
frames per second look close in a counter and are far apart in the hand (16.7 ms against 18.2 ms), and
that difference is exactly what the eye catches when the picture stutters. - CPU load and memory use.
- Power draw and battery heat.
- The renderer of the app in front — a real Vulkan / OpenGL label, not a guess.
- A live graph of the readings over the last few seconds.
Four looks, for four different kinds of player:
| Look | What it is like |
|---|---|
| Strip | A thin single-line bar along the top or bottom edge |
| Pane | A small multi-line box, the classic “overlay in the corner” |
| Ring | A circular gauge with the headline number in the middle |
| Badge | The desktop-style look: one big number, its unit on the text baseline, frame time underneath |
And three more things:
- A recorder that saves a real CSV session, so you can look at it afterwards in a spreadsheet.
- Line or stacked layout — stacked reads naturally in Arabic and other right-to-left languages — plus a
preview inside the app that behaves exactly like the real panel, so you set it up before you are in a
game. - Two buttons on the panel itself. Hide folds it into a small touch capsule; the readings keep
running and one tap brings it back — a capsule, not a full disappear, so the way back is something you
know rather than something you hunt for in the notification shade. The folded state is a moment, not a
saved setting: the panel never comes back hidden and leaves you thinking it stopped working. Close
stops the overlay and removes its notification, and leaves nothing running. Both buttons are 48 dp —
they have no alternative, so they are sized for a thumb — and carry no text, because a word translated
into 84 languages would squeeze the number itself.
What is running right now — the process monitor
- Per-process CPU and RAM, with a name, a range filter (all process classes, not just “apps”)
and a sort choice. - A search field, and a counter that says how many rows you are looking at.
- Force-stop a process, and SIGKILL for one that refuses to die politely.
- A floating panel version of the same list, for when you are inside another app.
- Heavy processes are marked, so the biggest consumer is visible without reading every number.
- Long-press copies a package name, for when you need to paste it somewhere.
- When the reader cannot read, it says so. An unreadable list is never shown as “no processes” — that
would be a lie: the processes are there, the app just could not see them.
Watching, measuring, diagnosing
- Max Live — the live picture: current readings, what automation is allowed to do right now and
why, what it would do next, and whether that can be undone. - Home — device state, the app in front, the running profile, temperatures and storage at a glance.
- Log viewer — live system logs with filtering and search, plus a shareable report whose glossary
is written into the log file itself, so whoever reads it does not have to be told what each line means. - Diagnostics — a live diagnostic centre, route health per control (is this control working on
this device, and how do we know), and a reproducible device blueprint: version, ROM, kernel, and the
interfaces that answered. - Support report — assembled locally on your phone, minimised, and it leaves the device only when
you send it. Nothing here phones home on its own. - “Why didn’t it work?” — for a per-app setting: what it wanted, what the hardware is holding, and
where to look next.
The tools shelf
Under Control → Tools — tools you open on purpose, not preferences to browse. The riskier ones are
labelled as advanced.
| Tool | What it does |
|---|---|
| Property editor | Reads and writes Android properties. It keeps a journal of every change — with the old value next to the new one — lets you filter to what you changed, and can put an old value back in one tap. When a value is 0/1 or true/false it gives you a switch instead of a text box; and it writes back the exact form the phone used, because getprop and Settings spell the same value differently and “normalising” one would corrupt a perfectly good key |
| Activity launcher | Opens any activity on the device, including ones your launcher hides |
| File manager | A root file browser: browse, inspect, copy, move and delete with the permissions you actually have |
| Permissions & AppOps | What an app declares, what the platform allows, and a documented reference to check against |
| Max Backup | Back up an app, verify the backup, and restore it |
| Debloat & freeze | Freeze or remove pre-installed apps you do not want running |
| Plugins | The third-party contract: which add-ons are installed, what was accepted, what was refused, and why |
| Module health | Is the module installed correctly, and are its pieces alive |
| Privilege | Confirms the app really has the privileged access it needs |
| Config backup | Export and import the app’s own settings |
| Diagnostics | The diagnostic centre described above |
Advanced tools that write outside MaxManager’s own settings are marked on purpose — not to lock you out,
but so a list of switches is never mistaken for a casual one.
Look and language
- Dark and light themes, plus a theme palette and a colour scheme to pick from.
- 84 languages, measured rather than claimed: 84 locale folders, 3,584 translated keys, 96.8% average
coverage. - Right-to-left done properly — Arabic, Farsi, Hebrew and Urdu mirror the layout, the reading order
and the icons, instead of being English thrown backwards. - Layouts are built for the long word, not the short one: a translated label three times the length of
the English is a normal Tuesday here, not an edge case.
Max Atlas — the reason anything works on your phone
Two phones of the same model can expose different kernel interfaces; two kernels can name the same
interface in different units and let you write it or not. Max Atlas asks every interface whether it is
here, what it is called, what unit it speaks, whether it can be written — and remembers the answer.
- Controls that cannot work are not shown.
- Every control is labelled for what it is: works and verified here · a route exists but is unproven
here · readable only · present but this build cannot drive it · proved absent · never touch (a safety
rule) · or unknown. - Absence is proved, not assumed. A read that failed is not an absence; only a listing that genuinely
lacks a name counts as “not here”. - It gets better on your device. What worked, what failed, and how long either fact stays true are
remembered — the second run is not the same experiment as the first.
Discovery runs under an explicit budget, and when a bound stops a scan the report says a limit stopped
it — never “the device had nothing to say”. A real run on a phone can be recorded and replayed through
the same read interface, so “it needs a device” stops being a permanent excuse.
Max AI — one measured change at a time
Max AI watches how the device is actually behaving — speed, heat, battery, memory pressure, which app is
in front — and when the readings say something should change, it changes one thing, then measures
whether that helped. It is a loop, not a preset:
- Notice — it reads this device. You notice nothing: it is watching, not acting.
- Decide — against your objective (speed, balance, battery) it picks the smallest change that could
close the gap. One control moves, not eight. - Ask — a safety layer with absolute priority says yes or no before anything is written. A protected
interface is never touched, engine on or off. - Verify — the value is read back, then the result is measured after a response window. A change that
did not hold is not counted as a win. - Remember — the outcome is recorded as a complete, measured episode. It trusts what has been right,
and stops trusting what has been wrong.
Why it is not a preset: a preset applies the same numbers to every device and never finds out whether
it helped. Max AI only speaks the vocabulary Max Atlas found on your phone, its wins are measured rather
than predicted, and it knows when to stop. Each cycle is kept as a record you can open: what it saw, what
it wanted, what it changed, what happened next, what it learned.
It is off until you turn it on, and the profile you choose stays a manual baseline — never an
instruction to the engine.
What it will never do
- Write a thermal safety limit. On any device, in any mode.
- Write a protected interface — refused by the safety layer even when the automation is on.
- Claim a change it did not measure.
- Invent a reading, or show
0where it has no answer. - Hide a failure. A write that did not take is reported, with a rollback attempted.
- Send anything anywhere on its own. There is no telemetry.
- Touch a knob through a second path. There is exactly one write path, an ownership ledger so two writers
cannot race for the same control, read-back verification, and a re-check later for silent drift.
That last one is the structural promise: whatever you change — by hand or by the engine — goes through
the same path, is read back, and is re-checked afterwards.
Why it never slows your phone down
The heavy work is not in the app — it runs in five small programs written in Rust, shipped for both
64-bit and 32-bit phones (ten executables in the package):
sys.maxmanager-service (the device service) · sys.maxmanager-rianixiathermalcore (thermal daemon) ·
sys.maxmanager-utilityconf · sys.maxmanager-profilesettings · sys.maxmanager-preloadbin
- Hardware reads and writes happen there, not in the screens. The interface never touches the kernel:
it asks, and the native layer executes and verifies. A gate in CI fails any change that breaks that rule. - The thermal decision is made in the Rust core, on its own cycle — a screen never waits for it.
- One shared reader, not one per screen, so nothing is measured twice.
- The engines are off until you turn them on, and the daemon is event-driven rather than spinning: no
polling loops, no idle background service, no log writing to itself.
The intended result is an app that behaves as if it were not there: open it when you need it, and nothing
underneath steals frames from your game.
And the honest part: we promise no performance numbers and no benchmark deltas. A number measured on
one phone is not a claim about yours — what we claim is the structure above, which you can inspect.
Install in three steps
- Flash
MaxManager-v1.0-module.zipin Magisk or KernelSU. - Reboot.
- Open MaxManager and follow the first screen — it explains what your phone supports.
It is a systemless module: nothing in /system is changed permanently, and removing it puts
everything back. If the module ever fails to boot properly twice in a row, it turns itself off and says
so, so you never end up with a phone that will not start because of it.
Two promises we do not break
- We do not guess. A value the app could not read is shown as unknown, never as a plausible zero.
Yes, you will sometimes see “unknown” — that is honesty, not a broken feature. - We do not touch what must not be touched. Thermal safety limits are never written, on any phone,
and a protected list of interfaces is refused even when the automation is on.
If something looks wrong
- “It says unknown.” That is a fact about your phone, not a bug you have to fix first. It is the app
telling you it could not measure that one thing. - “A change did not apply.” The app said so on purpose, and it tried to roll back. If it keeps
happening, tell us which phone and ROM you have. - “I cannot find a setting.” It is probably not supported on your device — that is the app hiding a
switch that would do nothing. - Ask here: @ROBINHOOD_GROUP_RODIN — bugs, ideas and builds.
Mention your device, your ROM and your root manager.
Appendix
For engineers: what is verified, and the numbers
| Item | Value |
|---|---|
| Package | the app installed as a privileged system app, with its permission file, the module scripts, and ten native executables (five programs × 64-bit and 32-bit) |
| This package | built and tested by CI at commit c39bbfa (build 92 · versionCode 92); the package's own digest is the first line of MaxManager-checksums.txt |
| Native layer | 5 Rust programs · 41 Rust files · 9,572 lines |
| App | 426 Kotlin files · 115,300 lines |
| Screens | 53 screens across nine control domains, plus the tools shelf |
| Tests | 1,775 Kotlin tests · 77 Rust tests, run on the host without a device |
| Contract gates | 17 gate scripts, 37 invocations on every push, before the build — plus a second layer verifying JNI symbols inside the real .so files |
| Architecture decisions | 54 documented decisions, binding on the code |
| Languages | 84 locales · 3,585 keys · 96.8% average coverage |
The limit, stated the way this project states it: anything that depends on real hardware — touch,
boot, SELinux, the module install, thermal response — is verified on a device, and where a run cannot be
made the repository says “not verified in this environment” instead of “passes”. That is a rule here,
not a hedge.
For ROM developers
The integration kit is released to ROM maintainers on written request — Soong build files, an init
service, a sepolicy domain and a privileged-permission allowlist, plus the same module packaged for
KernelSU Next.
You get: a privileged control app, the five native binaries, and a module that installs and removes
itself without permanently touching /system.
You need: a platform-signed, privileged build of the app; the daemon at
/system/bin/sys.maxmanager-service; the init service; and the sepolicy rules. Three names must agree
exactly — the binary path, the init service and the SELinux label.
Permission first. MaxManager is proprietary software. The kit is here so maintainers can
evaluate and integrate it with the copyright holder’s written permission.
Verify your download
| Asset | Size |
|---|---|
MaxManager-v1.0-module.zip |
15.3 MB |
MaxManager-checksums.txt |
28 lines — the package digest plus 27 for its contents |
# 1) the file you downloaded
sha256sum -c --ignore-missing MaxManager-checksums.txt
# 2) what is inside it, after unpacking
unzip -q MaxManager-v1.0-module.zip -d maxmanager && cd maxmanager
sha256sum -c --ignore-missing ../MaxManager-checksums.txtThe same package is built by CI on every push, with the developer bundle and checksums attached as
workflow artifacts.
Credits, licence and support
MaxManager is not written alone. These are the works it thanks — every notice their licences require stays
in THIRD_PARTY_NOTICES.md, which remains the binding list.
| Project | Copyright | Licence |
|---|---|---|
| AZenith | (C) 2025-2026 Zexshia | Apache-2.0 |
| Encore Tweaks | (C) 2024-2025 Rem01Gaming | Apache-2.0 |
| Rianixia-ThermalCore | (C) 2025-2026 ryanistr | Apache-2.0 |
| VMTouch | (c) 2009-2023 Doug Hoyte and contributors | BSD-3-Clause |
Licence: proprietary. Copyright (C) 2026 Nader Magdy. All rights reserved — no right is granted to
use, copy, modify or distribute without the copyright holder’s prior written permission. A public
repository is not the same thing as an open-source project.
Support: @ROBINHOOD_GROUP_RODIN