Open an installed manager directly, and survive an unshare without --propagation

[hhhbwc]

What

Two robustness fixes in the Magisk module scripts, both for environments that are not a conventional phone. Each keeps today's behaviour as the first choice and only falls back when the environment cannot support it.

zygisk/module/action.sh — prefer the installed manager

The action button currently only knows the injection path: hand the intent to ${INJECTED_PACKAGE_NAME} and let the Zygisk-injected manager answer it. That needs the shell process to host a 2D activity and to receive the injected manager dex. Neither is guaranteed everywhere: some systems never let the shell host an activity at all, and dynamic code loading restrictions can block the dex (#805 fixed one such case on GrapheneOS). Where the injection path cannot work, the action button is a dead end — even though manager.apk ships inside the module and #809 added a standalone install for exactly this situation.

When the manager has been installed as a regular package, launch its activity directly instead. If it has not, the injection path runs unchanged.

zygisk/module/service.sh — start the daemon where unshare is poorer

unshare --propagation slave -m is GNU util-linux syntax. Android ships toybox, and toybox builds that implement only a subset of util-linux reject the flag outright:

$ unshare --propagation slave -m true
unshare: Unknown option propagation

The daemon then never starts, and nothing says so: service.sh has no error path, and the failure only shows up as every Xposed module silently doing nothing. Probe the flag with a throwaway true and fall back to unshare -m, then to running the daemon without a namespace. The full invocation still runs first wherever it is supported.

Testing

Verified on a PICO 4 (Android 10) VR headset, where unshare --propagation is rejected and the shell cannot host the manager:

• unshare --propagation slave -m true exits 1 with Unknown option propagation; unshare -m true exits 0. Killed vectord, ran the new service.sh, and the daemon came back (VectorDaemon: Successfully injected Vector IPC binder for applications).
• With manager.apk installed from the module, the action opens org.matrix.vector.manager/.ui.MainActivity directly (force-stopped the manager, ran the action, the process returned). Without the package installed, the injection path still runs.

Notes

• On devices where the user has installed the standalone manager, the action button now opens the standalone app rather than the parasitic copy. They are the same build and Redraw the monochrome icon and the header ambiences, and compare the installed manager #849 already compares the installed manager's version, but say the word if the parasitic copy should keep priority.
• This does not by itself get a first-time user in on a device where the injection path is dead: pm install of the bundled manager.apk is still a manual step there, and Give the manager ways in again, and name builds by where they came from #809's first-launch prompt lives inside the manager, so it cannot be reached either. A customize.sh offer at flash time would close that gap, but it is a bigger change than this PR should carry.

[kinghe2023]

Thanks — this matches a failure we hit on a device that is not a conventional phone either, and the diagnosis was exactly as you describe.

Environment: Samsung Galaxy S25 (SM-S931U1), Android 16 / One UI 8, KernelSU v3.2.5 in LKM late-load mode (bootloader locked, root is loaded after boot, so the service stage runs long after boot has completed).

Reproduced on the unmodified script:

$ /system/bin/unshare --propagation slave -m true
unshare: Unknown option 'propagation' (see "unshare --help")
$ echo $?
1

vectord simply never existed, and nothing anywhere said why — the same silent failure you describe.

One suggestion for the fallback chain: before degrading to unshare -m, it is worth probing the busybox that ships with the root solution. On this device KernelSU bundles BusyBox v1.36.1.1 (topjohnwu) and its unshare does implement --propagation:

$ /data/adb/ksu/bin/busybox unshare --propagation slave -m true; echo $?
0

and it really applies it — the namespace becomes a slave of the parent's, instead of a namespace without propagation semantics:

$ /data/adb/ksu/bin/busybox unshare -m sh -c 'grep -c master: /proc/self/mountinfo'
0
$ /data/adb/ksu/bin/busybox unshare --propagation slave -m sh -c 'grep -c master: /proc/self/mountinfo'
76

(Unknown options are still rejected, so the probe stays meaningful: busybox unshare --totally-bogus-option -m true exits 1, and --propagation banana fails with unrecognized: --propagation=banana.)

What we ship — note $MAGISKTMP is not necessarily set when the service stage runs at late-load, so the paths are probed rather than assumed:

find_busybox() {
  for bb in /data/adb/ksu/bin/busybox /data/adb/magisk/busybox /data/adb/ap/bin/busybox; do
    [ -x "$bb" ] && { echo "$bb"; return; }
  done
}

BB="$(find_busybox)"
if [ -n "$BB" ] && "$BB" unshare --propagation slave -m true >/dev/null 2>&1; then
  "$BB" unshare --propagation slave -m "$MODDIR/daemon" --system-server-max-retry=3 "$@" &
elif unshare --propagation slave -m true >/dev/null 2>&1; then
  unshare --propagation slave -m "$MODDIR/daemon" --system-server-max-retry=3 "$@" &
elif unshare -m true >/dev/null 2>&1; then
  unshare -m "$MODDIR/daemon" --system-server-max-retry=3 "$@" &
else
  "$MODDIR/daemon" --system-server-max-retry=3 "$@" &
fi

Two more things from the same debugging session, both consequences of the same "fails without saying so" property:

1. Record which branch was taken. We append one line to a file (/data/local/tmp/vector-service-trace.log on our side); anything greppable beats nothing, given the failure mode is invisible by construction.
2. Refuse to start a second daemon. The daemon's own tryLock does not hold across mount namespaces (No injection after a KernelSU emulated soft reboot spawns a duplicate daemon #878), so anything that re-runs service.sh while a daemon is alive gives you two processes fighting over the same proxy service name. Anchored, because other processes have the string in their cmdline:

if pgrep -f '^vectord' >/dev/null 2>&1; then exit 0; fi

Thanks for the --propagation probe in particular — that alone would have saved us a long night.