App Manager ADB mode breaks Automate Shizuku connectivity after recent update

[kooooolaaa]

Please check before submitting an issue

• I know what my device, OS and App Manager versions are
• I know how to take logs
• I know that generating a report, in whole part or in part, using AI/LLM is prohibited
• I know how to reproduce the issue which may not be specific to my device

Describe the bug

This issue started immediately after updating App Manager to the latest version.
Before this update, the same setup worked reliably:
Automate could consistently connect to Shizuku
No ADB connectivity issues after reboot
However, after the update, Automate can no longer reliably connect to Shizuku after reboot when App Manager ADB mode is enabled.
Error log (Automate)
android.system.ErrnoException: isConnected failed: ECONNREFUSED (Connection refused)
Shizuku is unavailable via ADB on 172.30.1.11:xxxxx

To Reproduce

Install Shizuku and enable wireless debugging
Install Automate and configure Shizuku Keeper flow
Enable App Manager ADB mode
Reboot device
Run Automate flow

Expected behavior

Automate should connect to Shizuku normally after reboot, as it did before the App Manager update.
After the recent App Manager update, Automate fails to connect to Shizuku via ADB with ECONNREFUSED, and Shizuku is reported as unavailable on the wireless debugging endpoint.

Screenshots

No response

Logs

No response

Device info

Android device (Samsung One UI)
Shizuku (wireless debugging / ADB mode)
Automate (Shizuku Keeper flow / ADB shell command blocks)
App Manager with ADB mode enablede:

• OS Version:
• App Manager Version:
• Mode: Root/ADB/NonRoot

Additional context

Disabling App Manager ADB mode (switching it off or setting it to non-ADB behavior) immediately restores normal functionality between Automate and Shizuku.
This strongly suggests the issue is triggered specifically by App Manager’s ADB handling.

[MuntashirAkon]

In v4.1.0 onwards, App Manager automatically connects to ADB via Wireless Debugging after restarting the device the moment it connects to Wi-Fi.

Now, the exact workflow done by Shizuku to open an ADB connection automatically is unknown to me (last time I checked, Shizuku didn't even support automatic ADB connection after a reboot, most users have used some untrusted forks). If they have added it now, my guess is that they may not have handled a case where the Wireless Debugging is already on, causing it to unable to open a connection and making the API unavailable to third-party apps. You should check the logs from the app to see exactly what is happening, but I don't think the issue is related to App Manager. App Manager should be able to handle the said case pretty well.

[kooooolaaa]

In v4.1.0 onwards, App Manager automatically connects to ADB via Wireless Debugging after restarting the device the moment it connects to Wi-Fi.

Now, the exact workflow done by Shizuku to open an ADB connection automatically is unknown to me (last time I checked, Shizuku didn't even support automatic ADB connection after a reboot, most users have used some untrusted forks). If they have added it now, my guess is that they may not have handled a case where the Wireless Debugging is already on, causing it to unable to open a connection and making the API unavailable to third-party apps. You should check the logs from the app to see exactly what is happening, but I don't think the issue is related to App Manager. App Manager should be able to handle the said case pretty well.

From what I can tell, the issue looks like a classic race condition right after reboot.
At boot time, Shizuku’s watchdog starts first, while App Manager’s ADB auto-connect triggers at the same time. Meanwhile, Wireless Debugging is not fully ready yet, so the connection state is unstable. This is where the conflict happens.
However, when Automate has already established the Shizuku connection, things behave differently. In that case, App Manager’s ADB mode can attach normally without any issues. That suggests the problem isn’t the ADB connection itself, but the timing during the initial startup phase.
So essentially, once the system reaches a stable state with an active ADB / wireless debugging session, App Manager just behaves like a client and everything works fine.
This is why I suspect App Manager’s ADB auto-connect is not inherently broken, but it becomes problematic because it acts as an automatic reconnection trigger during boot, which overlaps with Shizuku’s watchdog and causes the instability.

[MuntashirAkon]

Your comment sounds like AI generated. Even if that's the case, the issue is likely with Shizuku: If it runs first, App Manager works, but if App Manager runs first, Shizuku doesn't.

[kooooolaaa]

Your comment sounds like AI generated. Even if that's the case, the issue is likely with Shizuku: If it runs first, App Manager works, but if App Manager runs first, Shizuku doesn't.

Before updating App Manager, the exact same Shizuku version worked correctly. The issue started immediately after updating App Manager, without updating Shizuku or changing any settings. That is why I suspect the regression is related to App Manager rather than Shizuku itself.
As a temporary workaround, I have to disable App Manager's Wireless Debugging feature. At the moment, this is the only way I can use both App Manager and Shizuku without the issue occurring.

[HGP23]

@MuntashirAkon
Love this app and kudos to you for all the hard work so thank you. Please don't take this the wrong way just constructive feedback but I have to agree with OP on all of his comments as my experience is the same instantaneously after updating to 4.1.0.

Precisely the race condition at first is exactly what I was thinking is probably the issue, but given the last couple weeks of experience seeing different quirks and weird conditions, testing and playing with things, to me it seems it's something from appmanager causing the issue.

However, your comment of shizuku first then appmanager doesn't work and vice versa, I would say that has not been my experience and it's solely appmanager not working, getting lost, getting that split brain issue if you recall from some time ago where it double loads or what have you after some time... Like it thinks I have root when I'm on wireless debugging for ADB after some time of it running so it all of a sudden gives me all the root and expansive options in the app dashboard and all the sub settings everywhere as if I'm root though I'm not.

Again, this isn't a bot, this is just constructive feedback you could take it or leave it but I love the app and thank you again just wanted to share my feedback as I don't usually have time to send or submit debug reports or even comments

FWIW, been using both apps, OG non-fork Shizuku, and yours for many many years without issue.

I think until we get that dashboard fixed with all apps loading and registering, given the Android 17 (P7P here) causing the link brake or whatever it is that you called it in the other post and issues causing it, we won't know or should blame another app just yet. I'm talking about the stalling and not loading and showing the list of the apps on the dashboard or even running apps area or anywhere, so it has become somewhat, useless, and unusable, at least for me and with my device no matter what I've tried to do 😔

[HGP23]

App Manager automatically connects to ADB via Wireless Debugging after restarting the device the moment it connects to Wi-Fi.

Not to be a thorn and pain in your side, but is there a way or plan for future to include a settings option to allow us to disable it from automatic connection when the phone restarts as there are cases where you don't want it to connect. Or you've restored your phone and you're out and about all day or all week without Wi-Fi yet it's trying to connect in the background, I would think battery drain for no reason.

Don't get me wrong I love the idea, but the solution of changing ADB mode or connectivity mode or whatever within the app isn't a solution per se cuz it breaks the whole ADB over TCP and wireless debugging where you have that connected via remote service server running active and showing check mark and remote service and remote server not activating and vice versa sometimes. Causing a full clear of settings and desyncing and repairing and connecting and all that