Breaks LADB

[brian6932]

LADB requires you to force stop Shizuku to actually be able to use it, if you don't you get an infinite loading screen https://github.com/tytydraco/LADB

LADB's dev is aware of this:

[RikkaW]

I can't resurface the "problem". I believe it's a problem of LADB.

In addition, Shizuku does not do anything that blocks other connections 🙃.

🙃:
LADB: bundle an adb binary and sell for money
Shizuku: implement a subset of adb protocol
This money is too easy to earn

[tytydraco]

I can't resurface the "problem". I believe it's a problem of LADB.

In addition, Shizuku does not do anything that blocks other connections 🙃.

Sorry, allow me to clarify. Shizuku doesn't intentionally block the connection, but the Android device can only have one active ADB connection at once. It can either only be ADB or Shizuku. It's nobody's fault except the devices. The same issue happens if you connect your phone to a PC with ADB, and try to launch LADB. It won't work either since the device already has a connection with the PC.

🙃:
LADB: bundle an adb binary and sell for money
Shizuku: implement a subset of adb protocol

Also, I don't think it's fair to say Shizuku and LADB do the same thing. My app focused on simply giving an end user access to the ADB binary. Shizuku is a backend framework for developers go give permissions to apps.

This money is too easy to earn

Money shouldn't be brought into it. My app is open source, users can compile it for free if they like. It's just a way for me to support myself for college. This is the first time I am selling an app, and I promise refunds if requested and support via email for my users.

I am a fan of your work <3 but it is not nice to degrade my projects :(

[qinlili23333]

On my device LADB can work while Shizuku running.
-Zenfone6 Android11

[RikkaW]

@tytydraco

but the Android device can only have one active ADB connection at once.

I believe there is no such limitation (I have also tested with "traditional wireless adb", adb tcpip).

[tytydraco]

Ohh, I see. Interesting. I am only on Android 10 so perhaps it is different for me. I will have to further investigate. Have you tried with Android 10?

[RikkaW]

@tytydraco Tested with Android 9, also works with multiple connections.

I found when use adb to connect self, run adb devices from the device may also show an emulator device.

$ ./adb devices
List of devices attached
192.168.0.116:5555      device
emulator-5554   device

Maybe this is the reason 🤔.

[tytydraco]

@tytydraco Tested with Android 9, also works with multiple connections.

I found when use adb to connect self, adb devices may also show an emulator device.

$ ./adb devices
List of devices attached
192.168.0.116:5555      device
emulator-5554   device

Maybe this is the reason 🤔.

That has been an issue for me previously. Maybe it has come back again. Thank you for the debugging ❤️

[RikkaW]

@tytydraco Always use adb -s can bypass this problem 😋.

[tytydraco]

@tytydraco Always use adb -s can bypass this problem 😋.

Well -s requires a serial right? I guess a way that I could get around that would be to parse adb devices output and remove entries that classify as an emulator. That leaves problems if there are other connections, so I may then have to pick the topmost device. Unless there is a way to get the ADB serial from the device itself. I can get the serial using Android APIs but Q needs extra permissions. I wonder if there is another way you know of?

[haruue]

Well -s requires a serial right?

adb -s can also be used with the ip:port pair such as 127.0.0.1:12345 after the wireless adb connection is obtained.

[tytydraco]

adb -s can also be used with the ip:port pair such as 127.0.0.1:12345 after the wireless adb connection is obtained.

Just worked with this, looked promising but I believe I found a cleaner solution using transport IDs. Specifying -t 1 should choose the functional device, not the emulator. In testing, regardless if I specify 1 or 2, the device connects properly, even when the emulator is connected. The only downside is that it takes slightly longer than usual to connect.