v1.0.15 binder fix confirmed working, but still failing on Samsung One UI 2.5 (Android 10) — uid 2000 permission rejection

[TheDreDay1000]

v1.0.15 binder fix confirmed working, but still failing on Samsung One UI 2.5 (Android 10) — uid 2000 permission rejection

Device: Samsung Galaxy S9+ / One UI 2.5 / Android 10
Affected apps: AppOps, MT Manager (and likely others)

---

Status after v1.0.15

The binder delivery fix in this release is correct — ProviderDiscovery now finds *.shizuku providers and sendShizukuBinderToAllClients() runs on startup. The binder is reaching apps that were previously skipped entirely. Good fix.

However, apps still cannot use the Shizuku compat layer on Samsung One UI. The failure now happens at the next layer: when apps try to actually invoke Shizuku API methods after receiving the binder.

---

Root cause (Samsung-specific)

The release notes mention ColorOS/OxygenOS for the uid 2000 does not have android.permission.xxx error. Samsung One UI hits the exact same wall, but through Knox's permission enforcement layer rather than ColorOS's.

When ShizukuServiceIntercept executes privileged calls as uid 2000, Samsung Knox checks uid 2000 against its own permission allowlist for operations like:

• android.permission.GET_APP_OPS_STATS
• android.permission.OBSERVE_APP_USAGE
• android.permission.INTERACT_ACROSS_USERS

Knox rejects these even for uid 2000. Real Shizuku bypasses this because its server process calls adoptShellPermissionIdentity() at the Java framework level before these checks run, establishing a different execution identity. Stellar's ShizukuServiceIntercept is a shim that doesn't replicate that identity setup, so Knox sees a raw uid 2000 call and blocks it.

---

What would fix this

The fix needs to be inside ShizukuServiceIntercept — specifically, it needs to mirror what Shizuku's actual server does when handling API calls from client apps on OEM-customized ROMs:

1. Before executing any privileged operation on behalf of a client, call ShellUtils.exec("pm grant ... android.permission.xxx") or equivalent to self-grant required permissions to the calling app where OEM restrictions would block it
2. Or: detect OEM (Samsung/ColorOS/OxygenOS) at runtime and apply a different execution path that pre-elevates the necessary permissions before the Knox/OEM layer sees the call

The binder delivery is now solved. This is the remaining blocker for OEM devices.

---

Happy to provide logcat output from the S9+ if that helps narrow down the exact permission(s) being rejected.

[TheDreDay1000]

@lovelmxa @roro2239

Follow-up: v1.0.15 still failing on Samsung Galaxy S9+ / One UI 2.5 / Android 10

Tested on device: Samsung Galaxy S9+ (SM-G965U), One UI 2.5, Android 10

---

What the logcat confirms

Binder delivery is now working correctly:

sendBinder: 发送 Shizuku Binder 到应用: bin.mt.plus
已向用户 0 中的应用 bin.mt.plus 发送 Shizuku binder
ShizukuServiceIntercept: bindApplication 成功: uid=12949, pid=18089, granted=true

However, MT Manager's process dies shortly after connecting when it attempts to perform any privileged file operation:

ActivityManager: Killing bin.mt.plus/u0a2949: remove task
WIN DEATH: Window{ddcaa4 u0 bin.mt.plus/bin.mt.plus.MainLightIcon}

The Samsung SELinux policy is actively enforcing at the kernel level throughout — every AVC denial in the log is tagged SEPF_SM-G965U_10_0030 audit_filtered, which is Samsung's own hardened SELinux policy layer on top of AOSP.

---

The problem layer

The binder handshake succeeds. The failure happens when MT Manager actually invokes a privileged operation through ShizukuServiceIntercept. On Samsung One UI, ShizukuServiceIntercept executing as uid 2000 hits Samsung's hardened SELinux policy (SEPF_SM-G965U_10_0030) which blocks operations that would succeed on stock Android or even ColorOS/OxygenOS.

This is the same class of issue mentioned in the v1.0.15 release notes for ColorOS/OxygenOS (uid 2000 does not have android.permission.xxx) but the enforcement mechanism on Samsung is SELinux policy rather than a Java-level permission check.

---

What would help narrow this down further

If there's a way to expose Stellar's internal server-side logs (similar to how Shizuku shows its log in the app UI), that would allow Samsung users to capture the exact failure point without needing a PC or complex logcat setup. The failure is happening inside ShizukuServiceIntercept after bindApplication and before the operation completes, but the exact call that fails isn't visible from the client side.

Device and OS: SM-G965U / One UI 2.5 / Android 10 / SELinux policy SEPF_SM-G965U_10_0030