Magisk vs KernelSU vs APatch for Screen Mirroring
Injection-based mirroring needs two things from your root setup: root access itself, and a Zygisk runtime — the piece that lets modules run inside app processes. All three mainstream root solutions can provide both. The difference is how much of it ships in the box.
The short version
| Root solution | Approach | Zygisk story | KoalaMirror |
|---|---|---|---|
| Magisk | Systemless, the long-time default | Zygisk built in — flip it on in settings | Works out of the box |
| KernelSU | Kernel-level root, popular on newer kernels | No built-in Zygisk — needs a standalone runtime | ReZygisk auto-provisioned on deploy |
| APatch | Kernel-patch based, the newer contender | No built-in Zygisk — same story | ReZygisk auto-provisioned on deploy |
Magisk: the path of least resistance
If you're on Magisk, you already have everything: enable Zygisk in the Magisk app, deploy KoalaMirror, reboot, done. This is the most-traveled road and the one most guides online assume.
KernelSU and APatch: equally first-class
Kernel-based root has real advantages on devices and kernels that support it — but neither KernelSU nor APatch bundles a Zygisk runtime. The usual fix is installing one yourself (ReZygisk being the actively maintained option). KoalaMirror does this for you: if no Zygisk runtime is detected at deploy time, it provisions ReZygisk as part of the same one-tap flow. No module hunting, no version matching.
Worth stepping back for a moment: root itself only opens the door — what it unlocks on Android Auto, and what it doesn't is the more useful question, and the method guide covers the non-root routes too.
Which Zygisk runtime? (and why it matters more than the root manager)
Picking a root manager is only half the decision. Magisk ships Zygisk itself. KernelSU and APatch don't, so you also end up picking a Zygisk runtime — and for screen mirroring specifically, that second choice matters more than the first.
Here's why. Putting a full Android desktop on a car screen needs two separate injections, not one: the module has to load inside system_server (which is what creates the extra display) and inside the Android Auto process (which is what puts your desktop onto it). A runtime can deliver one and quietly miss the other. When that happens Android Auto itself looks completely normal — it just never shows the mirror. So “the module is loaded” is not the same statement as “mirroring works,” and a status screen that only checks the first one will tell you everything is fine while nothing is.
| Zygisk runtime | Where it comes from | Status for mirroring |
|---|---|---|
| Zygisk (built into Magisk) | Magisk settings, one toggle | Verified. Nothing extra to install. |
| ReZygisk | Standalone module for KernelSU / APatch | Verified. This is the one KoalaMirror installs for you if you have none. |
| Zygisk Next | Standalone module for KernelSU / APatch | Verified on 1.4.5 and 1.5.0 (checked 2026-08-29). |
| NeoZygisk | Standalone module for KernelSU / APatch | Works from KoalaMirror 1.5.1 (verified on 2.4, 2026-08-30); see the note below. |
The NeoZygisk note, stated plainly: on NeoZygisk 2.4 we reproduced a crash that took down every Android Auto process. The cause was on our side, not theirs — our inline hook allocates a page that has to stay both writable and executable, and it was assuming that property held rather than re-asserting it. Under that runtime it doesn't hold. Fixed on 2026-08-30 and shipped in KoalaMirror 1.5.1 the next day; if you're on NeoZygisk and see no mirror, update KoalaMirror before anything else. This kind of thing is exactly why the table above carries dates instead of checkmarks.
So which one should you use?
- Already rooted? Stay where you are. All three are supported equally, and switching root solutions is rarely worth the churn just for mirroring.
- Rooting fresh? Magisk remains the simplest all-rounder; KernelSU or APatch make sense if your device community recommends them for your kernel.