Create a drop-in stub app with the original Shizuku package name

[tim1540]

Requirements

• I have searched existing issues and this is not a duplicate.
• This is a core Shizuku request (not for a 3rd-party app).
• I have a specific use case that cannot be solved with current features.

Problem

​Certain third-party applications (e.g., ZArchiver, aBattery) hardcode checks for the official Shizuku package name (moe.shizuku.privilege.api) before making permission requests, which leads to errors when using Shevery.
​Installing the official Shizuku app alongside Shevery isn't possible because Shevery declares the same permission ID, causing installation conflicts.

Proposed Solution

Provide a lightweight drop-in companion app (stub) that uses the original Shizuku package name and application name, while proxying all requests and controls to the main Shevery service.

Additional Context

To clarify why installing official Shizuku alongside Shevery is impossible: Android rejects installation with;
"Package moe.shizuku.privileged.api attempting to redeclare permission group moe.shizuku.manager.permission-group.API already owned by com.hamondev.shevery" because both applications declare the same custom permission.
Because of this protection mechanism, users cannot keep official Shizuku installed just to satisfy package name checks in third-party apps. This further highlights the need for a Shevery-managed stub package.

Some parts of this issue was written by AI to help with technical details.

[github-actions]

🤖 AI Triage

This is a well-reasoned feature request for compatibility with third-party apps that hardcode the official Shizuku package name, which fits the project's scope of bridging system APIs.

Note: this is an automated AI bot (Gemini); its verdict isn't 100% accurate and can be wrong. The bot doesn't read or reply to further comments in this thread — if it got this wrong, ping a human maintainer.

[playagain96]

+1 for this idea, I think it would be super useful for apps that before even trying they check if Shizuku exists, resulting the app to reject shevery being able to do the same work

[dlainhart]

This should have been implemented from Day 1.

Some packages might look for package moe.shizuku.privileged.api and refuse to run if it exists, some may not run if it doesn't. thedjchi's fork has a workaround to obfuscate the package name to avoid apps from looking for moe.shizuku.privileged.api.

The original Shizuku did not have that capability. Shizuku was moe.shizuku.privileged.api. That was the Shizuku upon which the Shizuku ecosystem developed. It may not be "elegant", but like it or not, package moe.shizuku.privileged.api is part of the de facto Shizuku public API, and as such, Shevery's implementation of the Shizuku API is de facto incomplete.

This missing functionality breaks compatibility with more than just ZArchiver and aBattery.

All that is needed is a barebones stub package named moe.shizuku.privileged.api to replace the old Shizuku that must be uninstalled. It can be fleshed out later.

[kerneldroid]

Try this build: https://github.com/kerneldroid/shevery-fork/releases/tag/r32
And activate this:

[BraveFalconfromTinyCastle]

@kerneldroid
I tried this build with two apps that seem to require the legacy api to work. The Legacy Stub toggle didn't do the trick.

Macrodroid system log using previous builds:
Shizuku permission not granted
Using this Legacy Stub enabled build:
Shizuku service not initialised, attempting to initialise
AND
Error shizuku service is not INITIALISED

DarQ before legacy stump:
Asks to install shizuku
With legacy stub:

[kerneldroid]

@BraveFalconfromTinyCastle

Is the Shevery service actively running?

If it is running and the issue persists, please provide a text logcat captured from the moment the Shevery service starts through attempting to run DarQ / MacroDroid.

Logcat requirements:

• Format: Provide logs as text in Markdown code blocks (```log) or as an attached .txt/`.log` file. Do not upload screenshots of text logs.
• Tags to include: Shizuku, ShizukuServer, com.hamondev.shevery, moe.shizuku.privileged.api, DarQ, MacroDroid.

The Compatibility Stub is confirmed working on 2 of my devices. Proof:

Image 1	Image 2	Image 3

[BraveFalconfromTinyCastle]

@kerneldroid

08-12 06:20:42.243 W/nsconfig( 7659): com.arlosoft.macrodroid: New config does not match the previously set config.
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): unable to start service com.arlosoft.macrodroid/com.arlosoft.macrodroid.shizuku.UserService...
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): java.lang.reflect.InvocationTargetException
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	at java.lang.reflect.Method.invoke(Native Method)
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	at rikka.shizuku.wf3.a(SourceFile:193)
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	at moe.shizuku.starter.ServiceStarter.main(SourceFile:14)
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:407)
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.Object.equals(java.lang.Object)' on a null object reference
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	at android.app.LoadedApk.makeApplicationInner(LoadedApk.java:1536)
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	at android.app.LoadedApk.makeApplication(LoadedApk.java:1433)
08-12 06:20:42.244 W/ShizukuServiceStarter( 7659): 	... 5 more
08-12 06:20:42.245 I/com.arlosoft.macrodroid:shizuku( 7659): System.exit called, status: 1

[kerneldroid]

This is same problem as #84
Will fix it later