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

Aperta
#1,439 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, kotlin

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
Kotlin
Stelle
7.7k
Fork
233
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Droid-ify/client

Tutte le issue di Droid-ify/client

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.