Godot: Unable to debug Android game over USB in 3.2 beta3

[smt923]

Godot version:
3.2 (>=beta3 & master)

OS/device including version:
Windows 10 v1903 (x64) - editor
Xiaomi Redmi Note 7, Android 9 - player/device

Issue description:
In latest stable (3.1.2), if I press the one click export, everything works flawlessly and my profiler/monitor/etc connect and I get remote debugging from my phone:

0 param: --remote-debug
1 param: localhost:6007
2 param: --use_depth_32
3 param: --use_immersive
Installing to device (please wait...): Xiaomi Redmi Note 7
** Device API >= 21; debugging over USB **
** DEVICE API >= 21; DEBUGGING OVER USB **
Reverse result: 0
** Debug Process Started **
Godot Engine v3.1.2.stable.official - https://godotengine.org
OpenGL ES 2.0 Renderer: Adreno (TM) 512

if I copy the project and launch it with 3.2 (both beta3 and master), or even make a new blank project and set it up for Android exporting, localhost changes to 127.0.0.1 (unsure if this is exactly why it's breaking) and I get an error about USB debugging, even though it was working fine on 3.1.2:

0 param: --remote-debug 
1 param: 127.0.0.1:6007 
2 param: --xr_mode_regular  
3 param: --use_depth_32 
4 param: --use_immersive    
Installing to device (please wait...): Xiaomi Redmi Note 7  
--- Device API < 21 or no USB connection; debugging over Wi-Fi ---  
--- DEVICE API < 21 OR NO USB CONNECTION; DEBUGGING OVER WI-FI ---

no more output after that, no profiler or monitor info (everything else is fine though)

on 3.2 beta3 I can set the remote debugging IP to my local IP and the wifi debugging does work as a temporary workaround, but as USB worked in 3.1 it'd be nice to have it back

Steps to reproduce:
Test one project's one click deploy in both 3.1.2 and 3.2, for me it doesn't matter what the project is, 3.2 never lets me debug over usb 3.2 beta2 works as normal, the remote-debug address being localhost still

Minimal reproduction project:
N/A (works with basically any project that is exportable)

[smt923]

From some discussion in a question here this seems to have only started happening in beta3, 3.2 beta2 actually connects fine, the remote-debug address stating localhost as it does in 3.1.2, I still don't know if that is the cause but it's the only obvious difference in godot's output

[akien-mga]

Likely a regression from #32854, CC @cooperra.

[cooperra]

Interesting. Let me see if I can shed some light:

There is code (already in stable) that checks Android version. If the version is too low to support adb reverse, then instead of debugging over USB, it debugs over the network.

The code I added handles a case I found where even on newer devices, adb reverse fails when the adb connection is over the network instead of USB (usually for the convenience of WiFi).

I added code that checked whether the adb connection was over USB. If it wasn't, we fall back to using the network instead of USB (to avoid the adb reverse issue I encountered).

The code I added parses the output of adb devices -l to determine whether USB is connected. In this case, it (falsely) concludes it isn't connected and falls back to the network.

I did my development on Linux. I didn't try the change on Windows.

So here are my questions for @smt923:

1. When your device is plugged in and you're having this issue, what is the output of the command adb devices -l when you run it from the Windows command prompt?
2. What is the output of adb shell getprop ro.build.version.sdk?

[smt923]

Output of adb devices -l:

List of devices attached
122fb5aa               device product:lavender model:Redmi_Note_7 device:lavender transport_id:1

output of adb shell getprop ro.build.version.sdk:

28

[cooperra]

Well, there's the issue. The code expects " usb:" to be in that string, but it's not.

We need to either 1) detect USB another way, or 2) determine some other way whether adb reverse will fail. I suppose we could run it before building the APK and see if it fails then. There's gotta be a better way.

[zacharytyhacz]

What an interesting bug. To add a little bit to the conversation, I have had a really similar issue thats USB related - some USB cords work over others for some reason (MacOS 10.13 High Sierra -> Samsung Galaxy S5, could be OS related ).

I'm not sure what is different between the cords, both visually appear the exact same besides the length of the cord, but only one works with Godot to debug with.

It's not exactly related, but this is something that this thread reminded me of.

[smt923]

Just for some perspective and to test it for my self I tried this on Linux too - exact same phone, hardware etc - and indeed adb devices -l on linux reports:

List of devices attached
122fb5aa               device usb:2-6 product:lavender model:Redmi_Note_7 device:lavender transport_id:1

and of course this means the remote usb debugging in beta3 works fine for me on Linux

if anyone on Windows doesn't want to use beta2 then, for now, setting the editor up for wifi debugging (for me: changing the "remote host" to your local IP instead of 127.0.0.1) does let you keep remote debugging android over wifi, and it honestly feels perfectly fine

[capnm]

… If the version is too low to support adb reverse …

Note that there is a related issue if (e.g. after adb restart) the reverse port becomes unavailable #33900

[Anutrix]

Is there anyway to test this issue?

[Anutrix]

Found out that usb:x-y means Bus x Port y which the adb is easily able to detect on Linux (probably using lsusb). But on windows, there's no direct way to find it or at the least Windows version of adb doesn't use it. And hence skips printing that string "usb:".

[Anutrix]

I found a fix/hack.
adb -d get-state returns the string device if connected via USB.
adb -e get-state returns the string device if connected via Wifi.
These can used to test for USB instead. There should be better way too.
Error message is shown if there are no devices.

[Toshiwoz]

The issue is still there right? I haven't noticed before, but now that my game is crashing only on android I really needed the feature.
Via wifi or usb gives me the same problem.
Also "small deploy with network FS" seems to have problems too.

[joenorton]

Just ran into this, same situation still happening as OP. And this is on 3.2 RC2, it just straight up breaks USB debugging.
Edit: Win10 64 bit, Android 9 Moto G6. Everything worked on 3.1.2
Also adding my device debug info as well:

List of devices attached
ZY323CRGWW             device product:ali model:moto_g_6_ device:ali transport_id:1

[akien-mga]

Confirmed the issue on Windows 10 too.

If I connect two phones, one over USB (ID 1) and one over Wi-Fi (ID 2), adb device -l gives me:

$ ./platform-tools/adb devices -l
List of devices attached
a3751fd4               device product:beryllium model:POCOPHONE_F1 device:beryllium transport_id:1
192.168.1.6:5555       device product:m0xx model:GT_I9300 device:m0 transport_id:2

Assuming that all Wi-Fi connection would use as device identifier an IPv4 or IPv6 URI, we could do some string parsing to assess it and define whether the device is USB or not.

But that might be a bit brittle, and I don't know how the output would be like on Linux (I can test in a bit) or macOS (I can't test), so a short term solution might be to revert #32854, and investigate further after 3.2 is released.

[akien-mga]

Assuming that all Wi-Fi connection would use as device identifier an IPv4 or IPv6 URI, we could do some string parsing to assess it and define whether the device is USB or not.

I had a quick look and I couldn't find a clear specification of how the serial numbers may look like depending on their transport type. I checked the adb source code and it has the information internally, but from a quick overview I couldn't find any way to retrieve this from the public command line options.

I'll go with a revert for now as there are way more users affected by this regression than by the original issue fixed #32854. We can work on a better version of #32854 to integrate in 3.2.1.