NyaZygisk WebUI Guide: What Each Feature Does and How to Use It

Header: version and reload#

The small text under the title is NyaZygisk version · root solution and version. The circular arrow at the top right is Reload. It re-reads all status and reloads the app list, then shows “Reloaded” at the bottom.

Status card: is Zygisk actually working?#

The big card at the top gives a verdict with a color and icon, and lists three components below it:

Each component’s status falls into one of three groups:

• Good (green): Running, Injected, Tracing
• Bad (red): Stopped, Exited, Crashed, Not injected
• Other (gray): Unknown

The verdict on the big card follows this rule, which is the frontend’s overallTone logic:

Device & environment#

This card lists:

• Root: detects APatch / FolkPatch / KernelSU / Magisk and shows the version when it can get one. It checks the apd, fpd, and magiskd processes and the /data/adb/ksu directory. SukiSU and similar show up as KernelSU or SukiSU.
• System: only shown when a vendor ROM is detected. ColorOS / OxygenOS, HyperOS, MIUI, and One UI are recognized, with versions taken from each vendor’s system properties. On AOSP-like systems this tile is hidden.
• Kernel, Android SDK, ABI: read directly from the data the daemon reports.

When filing an issue, attaching a screenshot of this card is the quickest way to share your environment.

Active modules#

Lists the Zygisk and ZN modules that are currently enabled. The number at the top right is the total. Each module shows its name, version, description, author, and badges:

• Zygisk: a module using the Magisk Zygisk API (for example LSPosed)
• ZN: a module using the Zygisk Next API. If its target is not zygote, a “Target: xxx” line is added
• Companion: the module uses a companion process

The list merges two sources:

1. A scan of /data/adb/modules/*, skipping directories with a disable or remove marker and keeping only those that contain zygisk/<abi>.so or zn_modules.txt. Its module.prop is read for the details.
2. The module list reported by the daemon, which adds the type (Zygisk / ZN), target, and companion information.

So if a module is missing here, first check whether it is disabled, or whether it is a Zygisk module at all (no zygisk/ directory and no zn_modules.txt). Conversely, a module you just enabled but have not rebooted for may already be in the list without actually being loaded; go by the state after a reboot.

Settings#

Anonymous memory: “Hide module mappings after specialization”. Off by default.

When on, after an app process has been specialized, NyaZygisk turns the module-created entries in /proc/self/maps (private mappings whose path contains jit-cache-zygisk, zygisk-module, or zn-module) into anonymous mappings, and removes write permission from rwx mappings. The goal is that an app scanning its maps does not see names that identify the modules.

• Useful when: an app scans maps for Zygisk traces and you have confirmed you need this.
• Leave it off when: you have no such need. It changes the process’s memory attributes, and users have reported problems after turning it on, such as the system UI failing to start or the status showing Monitor: NO. If you see anything like that, turn it off first to check whether it is the cause.
• The change is saved immediately and applies to app processes started afterwards. Apps that are already running need a restart.

Custom linker: “Load modules without the system linker (experimental)”. Off by default.

Normally modules are loaded by the system dynamic linker (android_dlopen_ext), which records them in its solist. With this switch on, NyaZygisk instead uses its own built-in ELF loader to map the module into memory and apply its relocations, so the module never enters the system linker’s records. Combined with anonymous memory it can map straight into anonymous pages, leaving no memfd name behind.

• Useful when: you want fewer module traces in the system linker and accept the risk of an experimental feature.
• Leave it off when: you just want a normal setup. It is experimental, which is why it is not enabled by default. If loading fails or a module is unsupported, NyaZygisk falls back to the system linker automatically; but if you see crashes or misbehaving modules after turning it on, turn it off before reporting.
• It also applies to app processes started afterwards. To see which loader loaded a module, use the debug build and look for modloader: lines in the log.
• Since v2.5-r2 a missing key means off. Earlier versions treated a missing key as on, so if you still want it after updating, turn it on again in the WebUI.

Language: EN / 繁中 / 简中. It takes effect immediately and is remembered in the WebUI’s own local storage; it does not affect the module itself.

How to use it#

1. Switch to the App exclusion tab at the bottom (the number on the tab is the count of currently excluded apps).
2. Find the app:
   • the search box matches name or package name;
   • the “All N / Excluded N” filter lets you show only excluded apps.
3. Turn on the switch at the right of the app. Every toggle is saved immediately, with a “Saved” toast.
4. Restart that app (swipe it out of recents completely, then open it). The exclusion only takes effect the next time the app starts; processes that are already running are not affected. Entries not yet in effect show a “Pending restart” badge.

Excluded entries are sorted first, the rest by name. Rows do not jump around when you toggle, so ticking several in a row will not hit the wrong one.

“Unmount for excluded apps”#

The switch at the top of the tab (Unmount for excluded apps) is on by default.

• On: besides not loading modules, an excluded app also has root and module mounts removed from its mount namespace, like the DenyList.
• Off: modules are simply not loaded; mount traces are left alone.

In other words, with this switch on, excluding an app means “modules cannot get in, and the app cannot see the mounts either”. If you already handle the app with your root manager’s “Umount modules” option (APatch / KernelSU) or Magisk’s DenyList, this switch runs alongside them without conflict.

Limitations#

The hint at the top of the page already says some of this; here it is in full:

• Only user-installed apps are listed (pm list packages -3). System apps do not appear and cannot be excluded. This is deliberate: system_server and system UIDs are never affected, so you cannot break the system with it.
• Apps sharing a UID switch together. If several packages share one UID, excluding one excludes all of them, and the list shows “Shares its UID with N other package(s); they switch together”.
• Apps sharing a UID with a system package cannot be excluded. Their switch is grayed out with the note “Shares a UID with a system package; cannot be excluded”. The daemon only excludes a UID when every package on it is on the list, and system packages are not allowed on the list.
• Uninstalled packages are cleaned out automatically, so there are no invisible leftover entries.
• Showing app names needs the manager to provide a package info interface (KernelSU-style WebUIs do). Without it only package names are shown, and functionality is unaffected.