[Request] Make the Shizuku installer work with renamed Shizuku forks (Shevery / stealth) without the original-package stub

Open
  • Is something wrong?
#1,439 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
android, kotlin
Domain
authentication, mobile

Research direction

Start by locating Droid-ify's Shizuku availability check and the code that handles the “Open Shizuku” action; the issue does not name source files or tests. Read how those paths currently identify the manager, then assess binder and permission checks and dynamic manager discovery. Done means a renamed compatible manager works without the original-package stub, while the existing Shizuku flow still behaves correctly.

Written by the indexing model from the issue text.

Description

enhancement
Guidelines
  • I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
  • I'm not requesting app support for a specific repo — that's up to repo maintainers
  • I understand this might not get built (Droid-ify is maintained by a single person)
Problem

I use Droid-ify every day with the Shizuku installer, running Shevery (a Shizuku fork). Shevery renames its own package so that banking / UPI apps can't detect Shizuku.

  • Without Shevery's compatibility stub (a fake package named moe.shizuku.privileged.api), Droid-ify shows that Shizuku isn't running and offers "switch to default" or "open Shizuku". "Open Shizuku" does nothing, because there is no app with the original Shizuku package name on the phone. Shevery itself is running fine under its renamed package.
  • With the stub installed, the Shizuku installer works fine. But my UPI apps (Navi, Airtel Thanks, Paytm) detect the stub, refuse to open, show a security warning and tell me to uninstall the Shizuku package (screenshot attached).

So I have to choose between Droid-ify's Shizuku installer and being able to use UPI. UPI is my main way to pay, so in practice I'm forced back to the Session installer and its manual confirmations.

This looks like Droid-ify decides whether Shizuku is available / which app to open based on the original package name, not on the binder and permission.

Proposed solution

It would be great if the Shizuku installer worked with renamed Shizuku-compatible managers, with no package named moe.shizuku.privileged.api on the device.

I haven't read the code, so these are suggestions only:

  1. Don't decide "Shizuku not available" from a package-name lookup. Rely on binder availability and the granted permission (e.g. Shizuku.pingBinder() and Shizuku.checkSelfPermission()).
  2. For the "Open Shizuku" action, find the manager dynamically. Forks keep the permission moe.shizuku.manager.permission.API_V23 and only one package can define it, so PackageManager.getPermissionInfo(...) returns the installed manager's package name. Another Shizuku client uses this to support the thedjchi stealth package: https://github.com/kuomartin/MoonClicker/pull/230
  3. Optional: a setting such as "Don't require the Shizuku app package to be present".

Background on why the stub exists:

Extras
  • Droid-ify version: 0.7.8
  • Phone: Samsung Galaxy M36 5G, Android 17 / One UI 9.0
  • Shevery version: 14.6.2
  • UPI apps that block it: Navi, Airtel Thanks, Paytm
  • Screenshots: (1) UPI app security warning with the stub installed
Image
  • (2) Droid-ify "Shizuku not running" dialog without the stub
Image
  • Possibly related (different cause: Droid-ify resets to Session when Shizuku isn't running at startup): #601, #748, #905, #1068
Dominant language
Kotlin
Stars
7.7k
Forks
233
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Droid-ify/client

All issues in Droid-ify/client

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.