Dhizuku-api

[railanbarbosaaquino]

I'm writing to you as an enthusiastic user of your Shizuku fork, especially appreciating the auto-start functionality via WRITE_SECURE_SETTINGS after a reboot – that's a fantastic improvement over the original Shizuku, eliminating the need for constant ADB re-connections!
The Current Limitation
While your current implementation is a huge step forward, I've noticed (and experienced firsthand) that Shizuku still requires Developer Options (and USB Debugging) to be enabled for it to function. This presents a few challenges for users:

• Security Concerns: Keeping Developer Options active can be a security risk.
• App Compatibility Issues: Many apps (e.g., banking, streaming, some games) detect Developer Options being on and refuse to run, forcing users to constantly toggle them.
• User Experience: It's simply less convenient and less "clean" for a persistent background service.
  A Proposed Solution: Integrating Dhizuku-API
  I'd like to propose a potentially groundbreaking enhancement: integrating the Dhizuku-API into your Shizuku fork.
  My idea is not for Shizuku to become a Device Owner itself, but rather for it to request elevated permissions directly from Dhizuku, which would already be configured as the Device Owner.
  Here's how I envision it:
• Dhizuku as the Permission Provider: The user would set up Dhizuku as the Device Owner once. Dhizuku then persistently holds the high-level system permissions.
• Shizuku as a Dhizuku Client: Your Shizuku fork would be modified to include the Dhizuku-API. Instead of relying on ADB commands or USB Debugging for initial elevation, Shizuku would simply request the necessary permissions from the active Dhizuku service.
• Persistent Operation: Once Dhizuku grants these permissions, Shizuku could then run its service with elevated privileges, without needing Developer Options to be enabled.
  Why This Would Be Game-Changing
  This approach would bring significant benefits:
• No Developer Options Requirement: Shizuku and all apps relying on it would function seamlessly even with Developer Options turned off, resolving the compatibility and security concerns.
• Enhanced User Convenience: A more streamlined setup and a "set-and-forget" experience.
• Increased Robustness: Operating under Dhizuku's Device Owner delegation offers a more stable and system-level privilege context than relying on ADB.
  I believe this integration would make your Shizuku fork the definitive solution for many users looking for advanced system functionalities without the compromises of constant Developer Options toggling or full root.
  What are your thoughts on the viability of implementing the Dhizuku-API for this purpose? I'm very eager to hear your perspective.
  Thank you for your incredible work on this project!

[pixincreate]

hey railan! its glad to learn that you find this fork of shizuku useful! thanks you for trying it out!

coming to the issue, i feel that there is a bit of misunderstanding about how dhizuku works. let me clarify a few things that might help explain why implementing this particular change is not feasible at the moment.

dhizuku is a device owner app on android. this role grants it high-level system privileges. meaning, it is designed to manage device-level settings and policies and not mid (adb) or low (root) level system privileges. and it don't have a mechanism to grant or delegate elevated privileges to other non-device owner apps in the way you're proposing.

android's security architecture itself does not allow this. please check this thread for more info.