English · العربية
Install the module · See the screens · Read the docs
This repository is MaxManager's public face — the documentation, the screenshots and the downloads. The application and its native layer are private source: nothing here builds, and the command lines quoted in these pages run inside that repository.
| Platform | Android 10 or newer (API 29) · arm64-v8a and armeabi-v7a |
| Root | Magisk · KernelSU · KernelSU Next — or Shizuku for part of it |
| Screens | 53 across nine control domains, plus a tools shelf |
| Languages | 84 locales plus English, right-to-left enforced by a gate |
| Licence | Proprietary — the copyright holder's written permission is required |
Contents — the seventeen sections of this page, in reading order
| Section | The one question it answers | |
|---|---|---|
| 1 | In ten seconds | What is this, and who is it for? |
| 2 | What it looks like | The screens, and the design document behind them |
| 3 | Why it is built this way | The three layers and the one write path |
| 4 | Max Atlas | Why anything works on your phone |
| 5 | Max AI | What changes, and how it is measured |
| 6 | What you can control | The nine domains, per-app control, profiles |
| 7 | Watching, measuring, diagnosing | Live readings, overlays, logs, diagnostics |
| 8 | Languages | 84 locales, and RTL as a gate |
| 9 | Requirements | Will it work on my phone? |
| 10 | Install | How to get it running |
| 11 | For ROM developers | The AOSP integration kit |
| 12 | What it will not do | The rules that cannot be switched off |
| 13 | Documentation | Every page under docs/ |
| 14 | FAQ | The questions that keep coming back |
| 15 | Support | Where a bug report goes |
| 16 | Licence | Proprietary, stated plainly |
| 17 | Credits | Who wrote the parts this project did not |
MaxManager is a performance and power control panel for rooted Android — one that only shows you controls that actually exist on your device.
Rooting hands you hundreds of kernel interfaces and no map. Most tuning apps answer that with a wall of switches: half of them do nothing on your hardware, none of them tell you what they changed, and when something breaks you find out later. MaxManager is built the other way round.
- A control your kernel does not expose is not on the screen. Not greyed out — absent.
- Every change is confirmed, not assumed. The value is read back after it is written, and a change that did not hold is reported as a failure with a rollback attempted.
- When it does not know, it says
status_unknown. Never a plausible zero. - Nothing runs behind your back. The engines are off until you turn them on, and every write goes through one audited path.
Two doors in, depending on who you are:
| I want to use it | I build ROMs |
|---|---|
| What it looks like · What you can control · Install | For ROM developers — the integration kit, on request |
| 53 screens across nine control domains, plus a tools shelf | Soong files, an init service, a sepolicy domain, a privileged-permission allowlist |
| Requirements: Android 10+, root (or Shizuku for part of it) | Permission-first: proprietary software, written permission required |
Home and Max AI · 6 frames
 Start |
 Home |
 Max AI |
 Max AI plan |
 Live control |
 Loop results |
Per-app control · 6 frames
 Apps |
 Per-app |
 Per-app display |
 Per-app gaming |
 Per-app power |
 Per-app tuning |
Control hubs · 8 frames
 Control |
 Control lanes |
 Control tools |
 More tools |
 Control (2) |
 Display |
 Responsiveness |
 Power |
CPU and GPU · 5 frames
 CPU cores |
 Core limits |
 Tweaks |
 GPU profiles |
 GPU live |
Memory and display · 2 frames
 ZRAM |
 Resolution |
Battery and charging · 4 frames
 Charging |
 Bypass check |
 Doze |
 Sleep policy |
Settings and tools · 11 frames
 Settings |
 Palette |
 Logs |
 Backup |
 Backup plan |
 Backup apps |
 Permissions |
 App permissions |
 Permissions (2) |
 Activities |
 Property editor |
Network, storage and HUD · 6 frames
 Network |
 Scheduler |
 Storage |
 FPS overlay |
 HUD metrics |
 HUD source |
48 of 48 frames captured · 0 optional extras. A frame not captured yet is absent from the grid above rather than broken; the screenshots folder holds all of them.
Every frame here is a real capture from a device, taken to the contract in
docs/screenshots/: 1162×2480 PNG, under 400 KiB each, one status-bar
choice across all frames, dark theme throughout, with -light and -ar variants. The grid is
generated from the frames that exist — tools/screenshot_gallery.py emits an <img> only for a PNG
that is really there, so a frame that has not been captured is absent rather than broken, and a frame
dropped in under the contract's name appears the next time the generator runs.
The diagrams on this page — the write path, the Max Atlas cycle, the Max AI loop, the nine domains — are drawn from the app's own behaviour, strings and tokens rather than from screenshots, and every claim about a screen here is written from the interface's own words.
The interface is drawn by rules rather than by taste, and those rules are written down value by value
in DESIGN.md — with a gate (tools/design_doc.py) that fails the build when the
document and the code disagree.
Three layers, and they do not overlap:
- Max Atlas decides how a thing can work on this device — which interfaces exist, which routes reach them, and what actually succeeded last time.
- The control plane is the only path that writes: one arbiter, an ownership ledger so two writers cannot race for the same knob, read-back verification, and a rollback when a write does not hold.
- Max AI decides what should change and when — the smallest change that could close the gap, measured afterwards. Off until you turn it on.
One rule covers all three: a change is written through one path, verified by reading it back, and re-checked later for silent drift. If it did not take, you are told — with a rollback attempted — instead of being shown a green tick.
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 each interface whether it is here, what it is called, what unit it speaks, whether it can be written — and remembers the answer.
What you feel from that:
- Controls that cannot work are not shown. No dead switches.
- 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.
How this is proven without making your phone the test bench
Discovery runs under an explicit budget (operations, entries, bytes, time), 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 device can be recorded as a fixture, and that fixture replays through the same read interface, so "it needs a device" is not a permanent excuse for untested logic. Knowledge comes from a reviewed catalogue we stand behind; a community-sourced vocabulary may suggest a route but never grants one.
Full page: docs/max-atlas.md.
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: temperature, load, battery, memory, the active app. 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 — when you open a game with its own profile, Max AI steps aside and keeps watching safety only.
What it will never do: write a protected interface · claim a change it did not measure · invent a reading · hide a failure. Every cycle is kept as a record you can open: what it saw, what it wanted, what it changed, what the device did afterwards, and what it learned.
It is off until you turn it on. Manual control is the default state, and the profile you choose stays a manual baseline — never an instruction to the engine.
For sceptics: how a decision is kept honest
A decision is only counted when it was executed through the single write path and verified. The engine keeps an ownership ledger so no two writers race for the same knob, a trust model so a source that has been wrong is no longer believed equally, and a journal of complete episodes rather than a summary of intentions. If the user undoes a change by hand, that is recorded as a measured rejection — not as noise.
Full page: docs/max-ai.md.
Nine areas, each in its own hub. The line under each name is the app's own one-line description of the area, quoted from the interface.
CPU — Cores, governor, vendor boost and kernel preferences. Turn individual cores on or off,
pin scheduling groups to clusters, set a floor and ceiling per cluster, choose governors, edit kernel
preferences.
GPU — GPU frequencies and graphics-specific vendor parameters. Frequency presets and manual
bounds, GPU governor, shader-core power policy, the vendor boost pipeline, and 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 device and a stalling device need opposite responses.
Display — Refresh rate, colour and canvas scale. Refresh rate, colour channels, saturation,
gamut and HDR response, brightness curves, night light, animation scales, screen timeout.
Responsiveness — Touch, frame pacing and scheduling latency. Touch sampling 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 the device is throttling right now.
Power — Charging, bypass, sleep and battery health. Charge current limits, a charge ceiling to
slow battery wear, bypass charging, aggressive doze, standby whitelist, battery health.
Storage & compiler — Compilation mode and storage health. Re-run ART compilation with a chosen
filter, reset compiled state, storage health.
Network — Traffic scheduling and link state. TCP congestion algorithm, fast-open/SACK/ECN, SYN
cookies, socket reuse, I/O scheduler tunables, link state.
Anything your device does not expose in one of these areas simply is not listed.
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 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.
Every app shows its effective state in plain words — per-app control is off · using the global profile · app override active — and while a game with its own profile is in front, Max AI switches to monitoring only.
A profile is a named set of behaviour you can apply, tune, save and share: Power (cool and frugal), Balanced (the everyday baseline), Gaming (GPU held in the upper range for steadier frame pacing), Performance (full capability, held 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, or a measurement claimed by whoever exported it. On import the app says exactly what it accepted and refused, and a profile from another chipset says so: a value measured over there is not a measurement over here.
- They are reachable from Quick Settings. A tile switches the profile without opening the app, and a second tile drives bypass charging.
Max Live — the live picture: current readings, what automation is allowed to do now and why, what
it would do next, and whether it can be undone.
Home — device state, the active app, the running profile, temperatures and storage at a glance.- FPS overlay — a draggable on-screen readout of FPS, CPU and RAM over any game, with a fallback
reading method and a Vulkan/OpenGL label when that is how the app renders.
- Process monitor — per-process CPU and RAM, force-stop, SIGKILL, and a floating overlay.
Log viewer — live logcat with filtering and search, plus a shareable report whose glossary is
written into the log file itself.- Diagnostics — a live diagnostic centre, per-control route health, a reproducible device blueprint,
and a support report you choose to send.
"Why didn't it work?" — for a per-app setting: what it wanted, what the hardware is holding, and
where to look next.
Nothing here phones home. The support report is assembled locally, minimised, and leaves the device only when you send it.
- 84 locales plus English; the picker follows the system language without a restart.
- Light and dark, with a themable key colour and a custom palette screen.
- RTL is enforced by a gate, not by hope — Arabic, Farsi, Hebrew and Urdu ship.
| Android | 10 or newer (API 29), built against API 37 |
| Root | Magisk, KernelSU or KernelSU Next — the module is the supported path. Shizuku gives ADB-level access without root, and several tools work with it |
| Architecture | arm64-v8a, armeabi-v7a |
| Chipsets | Dedicated strategies for Snapdragon · MediaTek · Exynos · Tensor · Unisoc. Everything else works through what your kernel exposes |
| Out of scope | No performance promises, and no benchmark deltas: a number measured on one device is not a claim about yours |
The real answer to "will it work on my phone?" is the capability map inside the app on your own device. Details: docs/compatibility.md.
MaxManager ships as a systemless module — nothing in /system is modified permanently, and
uninstalling puts everything back.
- Download
MaxManager-v1.0-module.zipfrom Releases and flash it in Magisk or KernelSU (or a compatible root manager). - Reboot.
- Open MaxManager and walk through Setup, which explains what your device exposes.
The same release carries MaxManager-checksums.txt — one digest for the package and one for
each of its contents — so you can verify the download before flashing it; the two commands are in
docs/releases/v1.0.md. If the
module fails to reach a stable boot twice in a row, it disables itself and says so in its own
description.
The integration kit is not published here — the source is private. It 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.
What you get: a privileged control app, five native binaries (the device service, chipset profiles,
the thermal daemon, a utility configurator and a game preloader), and a module that installs and
removes itself without touching /system permanently.
What you need: a platform-signed, privileged build of the app; the daemon on
/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 — and the diagram above shows them.
Permission first. MaxManager is proprietary software. The kit is here so maintainers can evaluate and integrate it with the copyright holder's written permission —
LICENSEgrants no right otherwise. Ask first via Support.
Start here: docs/rom-integration.md — three integration paths, the checklist, and two mismatches we found in the kit and reported rather than papered over.
The parts of the app you cannot turn off, and would not want to:
- No screen writes to the kernel. Every mutation goes through one arbiter with an ownership ledger and a journal — so "who changed this, when, and what happened next" is answerable.
- No fabricated readings. An unknown value is shown as
status_unknown, never as a plausible0. - No success that was not verified. Read-back after every write; drift is re-checked later.
- Thermal trip points are never written, on any device. That is a rule, not a limitation.
- A reviewed never-touch list guards the interfaces that must not be written, matched by fragment on purpose so vendor variants cannot slip through.
- No telemetry, no accounts, no silent uploads.
And where the honesty has an edge: nothing in this repository claims hardware behaviour it has not
measured. docs/verification.md lists what is proven here, what runs on any
machine without a device, and what needs a phone — written as "not verified in this environment"
rather than as a pass. That sentence is a rule in this project, not a hedge.
This page is the tour. The answers you reach for afterwards live in docs/:
| Page | One line |
|---|---|
| features.md | Every capability, what it is for, and where it is in the app |
| max-ai.md | The decision engine: objective, safety, measurement, journal, learning |
| max-atlas.md | The adaptation engine, stage by stage |
| rom-integration.md | Integration paths, the AOSP kit, SELinux, verification |
| compatibility.md | Android versions, ABIs, root managers, chipsets — and what is out of scope |
| profiles.md | Chipset strategies and the module's native executables |
| thermal.md | The thermal daemon: zone fusion, policy, prediction, learning |
| architecture.md | How the app, the daemons and the kernel interfaces fit together |
| releases/v1.0.md | The v1.0 release notes, and how to verify the download |
| verification.md | How every claim here is measured — and what cannot be measured |
| faq.md | The questions that keep coming back |
| THIRD_PARTY_NOTICES.md | The third-party components, with their notices |
Does it need root?
Yes, for the full control plane: it is a Magisk/KernelSU module, and the app reaches the kernel through one audited root bridge. Shizuku (ADB-level, no root) is detected too and unlocks several read-and-write tools.
Is Max AI on by default?
No. Manual control is the default state; nothing self-enables. When you do turn it on, the safety layer keeps absolute priority.
What happens if something goes wrong?
Values are read back after being written, a mismatch is surfaced with a rollback attempted, a drift guard re-checks later, and the installer disables itself if it fails to boot twice in a row.
Why does an unknown value show as status_unknown instead of 0?
Because 0 is a claim. The app says unknown when it does not know, rather than showing a
plausible-looking zero.
Does it send my data anywhere?
No telemetry and no silent upload. The diagnostic report is built locally, minimised, and leaves your device only if you hand the file over yourself.
How do I remove it completely?
Uninstall the module in your root manager. Nothing in /system was permanently modified.
Why is the licence proprietary?
The project's own choice, stated in LICENSE. A public repository is not the same thing as
an open-source project. Third-party components keep their own licences and are catalogued in
THIRD_PARTY_NOTICES.md.
- Telegram: @ROBINHOOD_GROUP_RODIN — bug reports, ideas, builds.
- Issues: please include the device, the ROM, the root manager and what the app showed. If it said
status_unknown, say so — that is a fact about your device, not a bug you have to fix first.
Proprietary. Copyright (C) 2026 Nader Magdy. All rights reserved. See LICENSE for
the full terms — no right is granted to use, copy, modify or distribute without the copyright holder's
prior written permission.
Third-party components included in this repository, or built against it, keep their own licences
(Apache-2.0 for archdaemon/ and thermalcore/, BSD-3-Clause for the embedded vmtouch, and others);
their notices are in THIRD_PARTY_NOTICES.md.
MaxManager is not written alone. These are the works it thanks — and 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 |
Missing from this list? If a work of yours ends up used here and is not named above, message me privately — or find me in the group — and I will add it.