1.2.5

• minor improvements

⚠️ Installing the stealth build

The stealth APK has a different package name. Android treats it as a completely separate app — it can't update the standard one, and the standard one can't update it. That's the point, but it means a few things work differently.

Switching from standard to stealth:

1. Uninstall ShizuPosed first.
2. Install the stealth APK.
3. Grant Shizuku permission again — it's a new package, so the old grant doesn't carry over.
4. Re-add your modules. The stealth build has its own data directory.

Switching back from stealth to standard: same three steps in reverse.

If you install the stealth APK without uninstalling the standard one, you'll have two copies. They'll have different launcher names (standard shows "ShizuPosed", stealth shows "Sync Service") but the same icon. They don't share settings, modules, or Shizuku permissions, and one's service doesn't talk to the other's. Running both at once means you won't know which one is actually doing the hooking. Don't do this — pick one.

Don't try to update across builds. Installing a stealth APK over a standard one (or the reverse) fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE. That's the package-name check doing its job.

Modules don't transfer. Adding a module to the standard build doesn't add it to the stealth build. They're separate installs.

Which build to use

Use the standard build unless you have a specific reason not to. It updates normally, its name is what the README and XDA thread use, and it's what most people expect.

Pick the stealth build if:

• A target app you need to hook checks for com.shizuposed.manager by name.
• You want the launcher to show something other than "ShizuPosed".
• You're fine with updates being manual (uninstall, reinstall, re-grant).

Before installing

Clear the shell-side cache so the new build doesn't pick up state from the old one. In Termux with rish, or in a shell with Shizuku access:

rm -rf /data/user/0/com.android.shell/files/.syscall_cache

On devices where the shell files dir isn't writable, the fallback path is used instead:

rm -rf /data/local/tmp/shizuposed

Run whichever one matches your device. If you're not sure, run both — deleting a directory that doesn't exist is harmless.

Then install the stealth APK and open it. The first launch will redeploy the payload to the shell-side directory, which is a one-time cost of a few seconds.

Optional:

Reboot your phone

1.2.4

Fixed

Smart-foreground no longer re-enables ADB mid-session.

The old design saved the prior adb_enabled value on enter and restored it on exit. If the monitor mis-detected the exit — a dialog, an overlay, an activity pause without a resume — the restore ran while the app was still open, and ADB came back on a few seconds into the session. Banking apps saw it.

The restore is gone. ADB goes to 0 on enter and stays there until the user restarts Shizuku, which sets it back to 1 as part of starting the ADB server. No restore code, no flip-flop, no window where the app sees ADB return.

The trade-off: leaving a scoped app doesn't turn ADB back on. The user restarts Shizuku to get it back. With Shizuku-Next's "ADB without Developer options" switch this is transparent; on upstream Shizuku it's a manual step after each scoped session.

1.2.3

Fixed

Removing a module now actually uninstalls the APK.

The Remove action in the module detail sheet was only deregistering the module from ShizuPosed's list. The APK stayed installed, so the next module scan found it again and the module came back.

The fix runs pm uninstall through Shizuku, which removes the package without user interaction. The call is synchronous — the manager waits for it to finish before updating its state, so a refresh right after removal doesn't re-register a module that's mid-uninstall.

This also works for headless modules with no launcher activity. The old path used an ACTION_DELETE intent, which needs an activity to host the system dialog; headless modules had no such activity. pm uninstall doesn't care about activities.

The ACTION_DELETE fallback is still there for the case where Shizuku isn't authorized — the user gets the confirm dialog and the system removes the package.

1.2..2

Changed

All three native libraries now know the stealth package name at load time.

libxstealth.so, libxstealth_next.so, and libxstealth_bridge.so each had hardcoded name matches for ShizuPosed, libxstealth, and similar. Those matches cover the standard build. In the stealth build they never hit, so each library was filtering the wrong set of names.

Each library now accepts the running manager's package name at load time:

• libxstealth.so and libxstealth_next.so use it to recognize the framework's own threads as trusted. Without that, the framework's own syscalls were being blocked by the framework's own filters, which breaks hooking.
• libxstealth_bridge.so uses it to recognize paths that identify the manager. Without that, a target doing readlink("/proc/self/fd/N") on an fd it opened could see the manager's package name in a marker or config filename.

The package name is passed in by XStealthNative.load(), XStealthNativeNext.load(), and XStealthBridge.load() respectively. Nothing about the standard build's behavior changes.

Fixed

Blank screen after granting Shizuku.

The notification permission is now requested before the service starts. On Android 13+, startForeground fails if the notification channel isn't ready, and the failure kills the app process. That's what produced the "blank screen then back to home" symptom.

Two related fixes: ShizukuHelper.autoStartServiceIfPossible() now actually posts the service start on the main thread (the previous version wrapped it in a lambda that was never invoked), and MainActivity no longer tears itself down on grant.

ActivityThread reflection is shape-based.

handleBindApplication, getPackageInfoNoCheck, LoadedApk.getResources, and the AppBindData fields are now found by argument-type and field-type matching, not by a fixed list of signatures. If a method or field is missing on a future Android version, the framework logs every method and field the class actually declares — so the failure is diagnosable from launch.log alone.

Smart-foreground no longer re-enables debugging while the watched app is loading.

The first exit after entering a watched app waits 10 seconds instead of 4, covering slow splash handoffs. The service's foreground check now uses the same 4-second freshness window as the monitor, so the restore only fires after the app has genuinely left the foreground.

Update checks.

The Settings tab has a Check for updates button. It bypasses the 12-hour throttle and posts a notification only when a newer release exists. Automatic checks on launch are unchanged.

XposedHook.dex and native libraries refresh on update.

Both are compared by content against the APK, not by name or size. A rebuild with a small source change no longer leaves a stale file on the shell side.

app_process spawn no longer blocks the shell.

Wrapped in a subshell with stdout redirected to /dev/null. Without this, the manager's shell call blocked for the lifetime of the target process, and am start fired 20+ seconds late.

Which APK to install

Both APKs ship in this release. Same code, same signature, different package name.

app-standard-release.apk — package com.shizuposed.manager. Use this unless you have a specific reason not to.

app-stealth-release.apk — package of the form <letter>.<letters>.<letters>. Use this if a target app checks for the standard package name, or if you want a different launcher label.

The two builds cannot update each other. If you're switching between them, uninstall one before installing the other, and clear the shell-side cache first:

rm -rf /data/user/0/com.android.shell/files/.syscall_cache

Or on devices where that path isn't writable:

rm -rf /data/local/tmp/shizuposed

The stealth build's scrambled name closes name-based checks. It does not close behavior-based ones — an app that detects the hook by inspecting its own method entry points still detects it, regardless of which build you're running.

1.2.1

• Improve the stealth package name masking to match Magisk.

⚠️ Installing the stealth build

The stealth APK has a different package name. Android treats it as a completely separate app — it can't update the standard one, and the standard one can't update it. That's the point, but it means a few things work differently.

Switching from standard to stealth:

1. Uninstall ShizuPosed first.
2. Install the stealth APK.
3. Grant Shizuku permission again — it's a new package, so the old grant doesn't carry over.
4. Re-add your modules. The stealth build has its own data directory.

Switching back from stealth to standard: same three steps in reverse.

If you install the stealth APK without uninstalling the standard one, you'll have two copies. They'll have different launcher names (standard shows "ShizuPosed", stealth shows "Sync Service") but the same icon. They don't share settings, modules, or Shizuku permissions, and one's service doesn't talk to the other's. Running both at once means you won't know which one is actually doing the hooking. Don't do this — pick one.

Don't try to update across builds. Installing a stealth APK over a standard one (or the reverse) fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE. That's the package-name check doing its job.

Modules don't transfer. Adding a module to the standard build doesn't add it to the stealth build. They're separate installs.

Which build to use

Use the standard build unless you have a specific reason not to. It updates normally, its name is what the README and XDA thread use, and it's what most people expect.

Pick the stealth build if:

• A target app you need to hook checks for com.shizuposed.manager by name.
• You want the launcher to show something other than "ShizuPosed".
• You're fine with updates being manual (uninstall, reinstall, re-grant).

Before installing

Clear the shell-side cache so the new build doesn't pick up state from the old one. In Termux with rish, or in a shell with Shizuku access:

rm -rf /data/user/0/com.android.shell/files/.syscall_cache

On devices where the shell files dir isn't writable, the fallback path is used instead:

rm -rf /data/local/tmp/shizuposed

Run whichever one matches your device. If you're not sure, run both — deleting a directory that doesn't exist is harmless.

Then install the stealth APK and open it. The first launch will redeploy the payload to the shell-side directory, which is a one-time cost of a few seconds.

1.2.0

Changed

The name is still derived from a per-machine seed, so it stays stable across rebuilds on the same machine. -PstealthSeed=<anything> still produces a different name. To see what yours will be:

gradle printStealthId

The next engine now respects the trusted-package prefix. libxstealth_next.so was using a hardcoded "ShizuPosed" / "Xposed" match to decide whether the current thread belongs to the framework. In the stealth build that match never hit, so the framework's own syscalls were being blocked by its own filters. The prefix is now passed in at load time, same as libxstealth.so.

Fixed

Blank screen after granting Shizuku. The notification permission is now requested before the service starts. On Android 13+, startForeground fails if the notification channel isn't ready, and the failure kills the app process — which is what looked like a silent return to the home screen.

ShizukuHelper was never actually starting the service after a grant. The previous version wrapped the call in a lambda that was never posted. It now posts the call on the main thread correctly, so the grant path starts the service as intended.

MainActivity no longer tears itself down on grant. The grant handler refreshes the UI and nothing else. It does not finish, recreate, or restart the activity.

ActivityThread reflection is shape-based. handleBindApplication, getPackageInfoNoCheck, LoadedApk.getResources, and the AppBindData fields are now found by argument-type and field-type matching, not by a fixed list of signatures. A failure on a future Android version logs every method and field the class actually has, so the fix is diagnosable from launch.log alone.

Which build to get

Same as before: the standard build unless you specifically need the stealth one. The standard build is the one the README, XDA thread, and release notes refer to.

If you do want the stealth build, read the install section below carefully — it's a separate app, not an update.

---

⚠️ Installing the stealth build

The stealth APK has a different package name. Android treats it as a completely separate app — it can't update the standard one, and the standard one can't update it. That's the point, but it means a few things work differently.

Switching from standard to stealth:

1. Uninstall ShizuPosed first.
2. Install the stealth APK.
3. Grant Shizuku permission again — it's a new package, so the old grant doesn't carry over.
4. Re-add your modules. The stealth build has its own data directory.

Switching back from stealth to standard: same three steps in reverse.

If you install the stealth APK without uninstalling the standard one, you'll have two copies. They'll have different launcher names (standard shows "ShizuPosed", stealth shows "Sync Service") but the same icon. They don't share settings, modules, or Shizuku permissions, and one's service doesn't talk to the other's. Running both at once means you won't know which one is actually doing the hooking. Don't do this — pick one.

Don't try to update across builds. Installing a stealth APK over a standard one (or the reverse) fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE. That's the package-name check doing its job.

Modules don't transfer. Adding a module to the standard build doesn't add it to the stealth build. They're separate installs.

Which build to use

Use the standard build unless you have a specific reason not to. It updates normally, its name is what the README and XDA thread use, and it's what most people expect.

Pick the stealth build if:

• A target app you need to hook checks for com.shizuposed.manager by name.
• You want the launcher to show something other than "ShizuPosed".
• You're fine with updates being manual (uninstall, reinstall, re-grant).

Before installing

Clear the shell-side cache so the new build doesn't pick up state from the old one. In Termux with rish, or in a shell with Shizuku access:

rm -rf /data/user/0/com.android.shell/files/.syscall_cache

On devices where the shell files dir isn't writable, the fallback path is used instead:

rm -rf /data/local/tmp/shizuposed

Run whichever one matches your device. If you're not sure, run both — deleting a directory that doesn't exist is harmless.

Then install the stealth APK and open it. The first launch will redeploy the payload to the shell-side directory, which is a one-time cost of a few seconds.

1.1.9

• Bug Fixes

⚠️ Important — installing the stealth build

The stealth APK has a different package name from the standard one. Android treats them as two separate apps. That has consequences:

If you have the standard build installed and want the stealth build:

1. Uninstall ShizuPosed (the standard one) first.
2. Install the stealth APK.
3. Open the app. Grant Shizuku permission again (it's a new package).
4. Re-add your modules. The stealth build has its own data.

If you have the stealth build installed and want to go back to the standard build:

1. Uninstall the stealth build first.
2. Install the standard APK.
3. Same as above — Shizuku permission and modules need to be set up again.

If you install the stealth APK without uninstalling the standard one: both will be installed. They will have different launcher labels (the standard shows "ShizuPosed", the stealth shows "Sync Service") but the same icon. They will not share settings, modules, or Shizuku permissions. The foreground service from one will not talk to the other. Running both at once will cause confusion about which one is doing the hooking — don't.

Don't try to update the standard build with a stealth APK, or vice versa. Android will refuse the install with INSTALL_FAILED_UPDATE_INCOMPATIBLE. That's the package-name mismatch doing its job.

Modules you've added to the standard build will not appear in the stealth build. They're separate installs with separate data directories. Adding a module to one doesn't add it to the other.

Which build to use

Use the standard build unless you have a specific reason not to. It has a memorable name, its updates are simpler, and the XDA thread, GitHub releases page, and this README all refer to it by the standard package name.

Use the stealth build if:

• A target app you need to hook has a name-based check for com.shizuposed.manager.
• You want the app's launcher icon to show a different name than ShizuPosed.
• You're willing to accept that updates and reinstalls are manual.

Optional (run this in termux rish or adb shell) before installing stealth build:

rm -rf /data/user/0/com.android.shell/files/.syscall_cache or rm -rf /data/local/tmp/ShizuPosed

1.1.8

Added

Stealth build.

A second APK is now produced alongside the standard one, with a scrambled package name of the form com.<random>.<random>. Same code, same signature, different identity.

The purpose is to close name-based detection. A target app that checks for com.shizuposed.manager — whether through PackageManager, a pm list packages shellout, or a /proc scan — finds nothing. The status provider authority is scrambled the same way, so a check for com.shizuposed.manager.status also finds nothing.

The scrambled name is derived from a per-machine seed, so:

• The same machine produces the same name every build, so updates work.
• Different machines produce different names.
• -PstealthSeed=<anything> produces a different name for a specific build.

To see what this build will produce on your machine:

gradle printStealthId

The stealth APK ships as app-stealth-release.apk. The standard APK ships as app-standard-release.apk. Both are in the same GitHub release.

Changed

PackageCheck and RunningProcessCheck now read the actual manager package name at install time.

Both classes used to hardcode com.shizuposed.manager as the name to hide. In the stealth build that name doesn't exist, so the check would have hidden the wrong package and let the real one through. They now read it from XStealthConfig, which XStealthStatusWriter populates from the running manager's getPackageName().

The same applies to ThreadNameScrub on the native side: libxstealth.so now accepts a runtime trusted-package prefix via nativeSetTrustedPackage, called from XStealthNative.load(). Without that, the stealth build's own threads would be treated as untrusted, and the framework would scrub its own reads.

⚠️ Important — installing the stealth build

The stealth APK has a different package name from the standard one. Android treats them as two separate apps. That has consequences:

If you have the standard build installed and want the stealth build:

1. Uninstall ShizuPosed (the standard one) first.
2. Install the stealth APK.
3. Open the app. Grant Shizuku permission again (it's a new package).
4. Re-add your modules. The stealth build has its own data.

If you have the stealth build installed and want to go back to the standard build:

1. Uninstall the stealth build first.
2. Install the standard APK.
3. Same as above — Shizuku permission and modules need to be set up again.

If you install the stealth APK without uninstalling the standard one: both will be installed. They will have different launcher labels (the standard shows "ShizuPosed", the stealth shows "Sync Service") but the same icon. They will not share settings, modules, or Shizuku permissions. The foreground service from one will not talk to the other. Running both at once will cause confusion about which one is doing the hooking — don't.

Don't try to update the standard build with a stealth APK, or vice versa. Android will refuse the install with INSTALL_FAILED_UPDATE_INCOMPATIBLE. That's the package-name mismatch doing its job.

Modules you've added to the standard build will not appear in the stealth build. They're separate installs with separate data directories. Adding a module to one doesn't add it to the other.

Which build to use

Use the standard build unless you have a specific reason not to. It has a memorable name, its updates are simpler, and the XDA thread, GitHub releases page, and this README all refer to it by the standard package name.

Use the stealth build if:

• A target app you need to hook has a name-based check for com.shizuposed.manager.
• You want the app's launcher icon to show a different name than ShizuPosed.
• You're willing to accept that updates and reinstalls are manual.

The stealth build does not close behavior-based checks. An app that has a working hook-detection mechanism — checking whether its own methods' entry points have been patched, or running its own runtime-integrity SDK — will still detect the framework regardless of the package name. Those checks are structural and no non-root framework beats them.

1.1.7

• Check for Updates

1.1.6

Fixed

Smart-foreground no longer re-enables USB debugging while you're still in the app.

The monitor was treating a watched app as "left" too early when the app had a slow startup. Apps which take 5–8 seconds after opening before their main activity emits a resume event, and during that gap the monitor's normal 4-second exit window expired. That fired the restore, USB and wireless debugging came back on, and then the app finished loading and the disable went back into effect. A brief but real window where debugging was on.

Two changes fix this. The first exit after entering a watched app now waits 10 seconds instead of 4, which covers the splash handoff. Subsequent exits keep the normal 4-second dwell, so leaving the app is still detected promptly.

The service's foreground check now actually works.

The guard that's supposed to stop the restore while a watched app is foreground was reading the last event in a 5-second window without checking whether that event was recent. A watched app whose last event was a resume stayed "last event was resume" long after the user left it, so the check gave wrong answers in both directions. It now uses the same 4-second freshness window the monitor does, so the two agree on what "foreground" means.

Together, the two fixes mean the restore only runs after a watched app has genuinely been out of the foreground for at least 4 seconds.