3rd party app integrations with ADB shell

[e-t-l]

Hey, are you accepting feature requests? One thing that would really elevate this app is the ability for 3rd-party apps to send it ADB commands to execute. There are 2 main ways to accomplish this, I think:

1. Tasker integration

Tasker provides a simple module that developers can be add to an app in order to receive Tasker-style commands: https://tasker.joaoapps.com/plugins-intro.html

2. Intents

An even easier (and more widely compatible) method is simply to register an intent listener, so that other apps can send ShizuTools a private intent to execute its data string via ADB.

In either case, to avoid this being a security risk, there could also be a place in ShizuTools to save a "verification string", essentially a password. This is a random string the user can set, change, or delete. The user then adds the string as an "Extra" value in each intent, or as an additional I'm out string in a Tasker message, which tells ShizuTools that the incoming command is legitimate and safe to execute in ADB. Only intents/messages that include the correct string get executed; all others are ignored.

[legendsayantan]

Shizuku already has APIs for other apps to use its functionality to execute ADB commands.. so I kind of don't see what new could be achieved by ShizuTools having the same?

[e-t-l]

The Shizuku API has to be hard-coded into an app, or a terminal emulator is needed to use Rish. Comparatively, lots of apps can create arbitrary intents (e.g. automation apps like Tasker, Macrodroid, Shortcut Maker... none of which are otherwise compatible with Shizuku). There are also a number of ADB shell apps (e.g. LADB, aShell) some of which don't use Shizuku at all, and none of them offer any way to automate ADB commands or allow 3rd-party apps to send them ADB commands to execute.

Ideally, should more app devs include the Shizuku API? Yes. But until they do, opening up ADB access via intents would fill a niche that other apps have failed to accommodate so far.

[legendsayantan]

Interesting. I will look into the plausibility of that feature.

[legendsayantan]

A primary implementation of this feature has been added (tested with MacroDroid). I have also added instructions on how to use it, on README, and will continue to develop on it based on user feedback.

[e-t-l]

It works, thank you! I have been trying to send ADB commands from Macrodroid for years. You finally made it possible 🙏

[N-U-ser]

Commands don't execute if app is not in Background

Due to the intent being broadcast intent, Adb commands don't get executed when the app is not running (Background processing going on Or Remaining in recents), Thus defeating the whole purpose of

automate ADB commands or allow 3rd-party apps to send them ADB commands to execute.

Possible solution

Extinguish app (https://github.com/Moderpach/Extinguish) has added third-party integration to directly turn on/off screen using adb shell commands which target Service

And this can command

adb shell am startservice -n own.moderpach.extinguish/.service.ExtinguishService --ei screen 1

,can also be sent as intent using tasker and that works even when the app is not in Background or Force stopped

I am not that knowledgeable about android apps but if some tweak can be done to the intent listener/filters so that they listen to intent directed/target some service(maybe puedo) and strings from its extras get passed on to be executed as shell command, Then it will work even the app was not in Background.

As i said, i not sure if service and broadcast are fundamentally different and cannot be purposed into doing this.