[Feature]: Add LADB / Direct Wireless Debugging backend option

[Spectra47]

Checklist

• I have searched existing issues and discussions and this is not a duplicate.
• I am suggesting a new feature or enhancement for ShizuCallRecorder itself, NOT for Shizuku or another app.
• I have read the project README.md and CONTRIBUTING.md.
• I have read the application docs.

Is your feature request related to a problem? Please describe.

Running a central Shizuku manager service introduces a shared attack surface on non-rooted devices, as Shizuku acts as a centralized authority that can grant elevated ADB shell permissions to multiple applications.

For privacy-hardened setup threat models, relying on a shared Shizuku bridge requires keeping Shizuku running globally, exposing the system to potential cross-app permission abuse if another app requests/exploits Shizuku access. Currently, the app strictly relies on Shizuku, forcing users into this shared model.

Describe the solution you'd like

I'm thinking of an alternative, standalone backend option (such as "Direct Local ADB / LibADB Daemon Mode") that allows the app to establish its own local ADB pairing/shell session directly via Wireless Debugging without requiring the central Shizuku app.

Key Benefits & Use Case:

1. Threat Surface Reduction: Allows users to grant ADB shell permissions strictly and exclusively to the app without running a multi-app Shizuku bridge manager.
2. User Sovereignty: Gives ud complete choice over their execution layer (Shizuku, direct LADB daemon, or Root/su).
3. Inspiration from existing FOSS projects: Firewall projects like ShizuWall (by AhmetCanArslan) implement a "Triple Backend" architecture (Shizuku, Root, and direct LibADB/LADB daemon) where the app pairs directly with local Wireless Debugging to execute system/shell commands independently.

Describe alternatives you've considered

• Current Approach (Central Shizuku): Works great for general users, but leaves the central Shizuku service active and shared across any app that requests it.
• Root (su): Ideal for rooted users, but not applicable for stock/non-rooted devices.

Additional context / Mockups

Apps like ShizuWall serve as a great reference for this architectural choice. In their settings under "Backend & Working Mode", they allow users to toggle between:

1. Shizuku
2. Direct LADB / LibADB (Wireless Debugging pairing)
3. Root (su)

Adding a direct LADB/daemon backend option to this app would make it the most security-hardened, zero-trust call recorder available for non-rooted Android!✨🤍🤍

[kitsumed]

Root support will never be a thing (for now) as tools like BCR already exists, so it's not worth the hassle of supporting root.

I do agree with the general idea that ShizuCallRecorder supporting LADB or at least managing its own ADB connection would be nice, but this is not the priority right now and it would require a big rework, not sure of how big exactly. On the other side, it would allow ShizuCallRecorder to enforce safer default behaviors. But it would mean that the app would need even more permissions like WRITE_SECURE_SETTINGS, etc.... Basically a bigger maintenance burden.

On the bad side, we would probably get flooded by issues and requests from users who can't manage to get the connection working (just look at the official Shizuku spammed by bots or even thedjchi Shizuku fork).

[Spectra47]

Root support will never be a thing (for now) as tools like BCR already exists, so it's not worth the hassle of supporting root.

I do agree with the general idea that ShizuCallRecorder supporting LADB or at least managing its own ADB connection would be nice, but this is not the priority right now and it would require a big rework, not sure of how big exactly. On the other side, it would allow ShizuCallRecorder to enforce safer default behaviors. But it would mean that the app would need even more permissions like WRITE_SECURE_SETTINGS, etc.... Basically a bigger maintenance burden.

On the bad side, we would probably get flooded by issues and requests from users who can't manage to get the connection working (just look at the official Shizuku spammed by bots or even thedjchi Shizuku fork).

I got u on the bots/spam thing😂 & Thanks for the thorough explanation @kitsumed! That makes total sense—I didn't account for the fact that scrcpy-server relies on app_process native Binder bindings via Shizuku rather than simple CLI command execution like ShizuWall. Appreciate you taking the time to detail the architecture!