[ARM 32-bit] Unable to start debugging with an android physical device (Hot Reload) #9573
Comments
ArtefactoDev
added
Area: App+Library Build
This phrasing is confusing, are you trying to debug or use hot reload? The error looks like the debugger is not connecting.
Does the default template with no changes work? What change did you make that "breaks" things? The error looks like what you would see if you put the emulator in airplane mode, for example. |
jonathanpeppers
added
need-info
I can't debug when I try to use a physical Android device.
No work.
Shouldn't the template, without any modifications, work without errors?
Basically, trying to get around the 'ADB0020' error, I only added these lines:
|
dotnet-policy-service
bot
added
need-attention
I do this daily, and it is working for me. What device are you using? Can you share a
Is the device a 32-bit device? If so, you would need to list <RuntimeIdentifiers Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">android-arm;android-arm64;android-x64;</RuntimeIdentifiers>A |
jonathanpeppers
added
need-info
Not for me, even using the default template without any changes Are you trying an emulator or are you trying to use a physical device for this test? because in the emulator it works normally.
I attributed the log to open ticket to try to help.EngineTrace_4472.txt
I know, I explained what happens when you try to debug a physical device using the default template, without any changes.
I added all the code from the 'csproj' project to the ticket. Maybe the problem is with arm.. But, don't you agree that this should already come by default in the default template, if we consider that more than 90% of the time we will come across ARM devices on Android? Thank you very much for the excellent help, I'm sure the team will solve it! Because you are excellent! |
dotnet-policy-service
bot
added
need-attention
|
The logs above are not
The default is |
It's a possibility. |
|
You already mentioned the solution for this which is to add |
|
Device Android: Okay, I cleared everything. 1 - I created a default template without any changes to the '.Net Maui App'. 2 - If I try to debug on the Android device), it will give an error: 3 - I add the line you passed: 4 - Return the error 5 - Add 'project.assets.json' to help |
This feels like an IDE/Visual Studio/project system bug, but you may have to close and reopen the project to force it to run NuGet restore again. You might also try |
|
I try add two lines:
The error has stopped choosing arm32, I can generate the apk and add it to the device, but the error that started it all comes back (not able to debug): I feel like I'm in a loop. |
|
I formatted my machine. I only installed Visual Studio. I chose the "MAUI App" model and without any modifications I tried to generate the debug on the physical device and I had exactly the same error. I believe there must be a problem with Visual Studio generation. |
|
Good afternoon everyone, any news? |
|
If you are having trouble with a specific device: Does the emulator work just fine or a different device? We would prioritize this based on how many people are using 32-bit arm devices. Or if it happens to every Motorola device, we would want to investigate. |
|
Any arm 32 cell phone. The problem is not the model, but any x32 processor arm. Samsung, Motorola, Sony, Huawei or any other brand with this processor will not work. |
jonathanpeppers
removed
the
need-attention
jonathanpeppers
changed the title
|
@ArtefactoDev did you find any workaround for your device? |
|
@dellis1972 I tried on an x64 device and get the log and on x86 yes it shows this every time: |
|
@WilliamWatterson86 can you find out what the value for We are trying to figure out where the issue is. I suspect the runtime reading the timeout into a variable which is overflowing. But we need to know what the property is first. |
dellis1972
added
the
need-info
|
@dellis1972 here is the result of that command during a failed session debug=127.0.0.1:8835,timeout=1740583188,loglevel=0,server=y |
dotnet-policy-service
bot
added
need-attention
|
have to tried this on other devices or emulators? (32 bit , 64 bit). |
dellis1972
added
need-info
|
@WilliamWatterson86 do you get the same |
|
x64 bit devces seem to be ok, I have tried a couple of these. I only have one x86 Samsung A13 device. So I havent been able to try it on other x86 devices so far. |
dotnet-policy-service
bot
added
need-attention
|
do you have android-arm in your |
|
@dellis1972 - yes i have this line:
|
|
I can reproduce this when deploying an arm32 app to an x86 emulator:
the other entry was with x86 RID and has the correct timeout argument. |
Context dotnet#9573 Not sure why, but we are getting an odd problem were the `timeout` value we pass to mono for the debugger is not long enough. This is causing the debugger to timeout. What we see is `timeout=3` rather than `timeout=1740583188`. Lets upgrade to use `std:format` to see if that helps as it with automatically take care of the conversion for us.
Fixes: #9573 Context: 8e1c0e6 A customer reports that they are unable to attach a debugger to 32-bit Android apps: > am start -a "android.intent.action.MAIN" -c "android.intent.category.LAUNCHER" -n "com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity" > Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity } … [monodroid-debug] Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8805,server=y,embedding=1,timeout=8 … [mono] Listening on 127.0.0.1:8805 (timeout=8 ms)... [mono] debugger-agent: Timed out waiting to connect. Of particular note from the above log messages is the `timeout=8` value, which is considerably lower than it needs to be, which is a [value in *milliseconds*][0]. This low value is responsible for the subsequent `debugger-agent: Timed out` log message. The `timeout=` value was introduced in commit 8e1c0e6, which used `%d` to convert the `timeout_time` value; [for context][1]: struct RuntimeOptions { int64_t timeout_time = 0; // … }; // … char *debug_arg = utils.monodroid_strdup_printf ( "--debugger-agent=transport=dt_socket,loglevel=%d,address=%s:%d,%sembedding=1,timeout=%d", loglevel, options.host, options.sdb_port, options.server ? "server=y," : "", options.timeout_time ); `options` is a `RuntimeOptions`, and `options.timeout_time` is thus a `int64_t`, but it's being `printf`d via `%d`. `%d` is supposed to be an *int*; from [**printf**(3)][2]: > **d**, **i** > The *int* argument is converted to signed decimal notation. which means using `%d` for an `int64_t` will only work properly on ILP64 targets. Android, notably, is an ILP32 (32-bit) or LP64 (64-bit) target, *never* ILP64; it's a wonder this worked *anywhere*, with any degree of reliability. The fix is to realize that it doesn't even make sense to be forwarding `RuntimeOptions::timeout_time` in this manner in the first place: `RuntimeOptions::timeout_time` is compared against `time(NULL)`, i.e. it's a [Unix time value][3] (*seconds* since 1970-01-01 UTC), not a value in milliseconds at all! Replacing the use of `options.timeout_time` with 30000 allows for a value that is reasonable for the target domain, *and* works properly and consistently on both ILP32 (32-bit) and LP64 (64-bit) Android targets. [0]: https://github.com/dotnet/runtime/blob/9022f3a9b63b56234726606bc5547378b2d08f6b/src/mono/mono/component/debugger-agent.c#L581 [1]: https://github.com/dotnet/android/blob/8e1c0e6e2f4c41c9a24904bb1cea943357d78ac4/src/monodroid/jni/monodroid-glue-internal.hh#L98-L106 [2]: https://linux.die.net/man/3/printf [3]: https://en.wikipedia.org/wiki/Unix_time
Fixes: #9573 Context: 8e1c0e6 A customer reports that they are unable to attach a debugger to 32-bit Android apps: > am start -a "android.intent.action.MAIN" -c "android.intent.category.LAUNCHER" -n "com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity" > Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity } … [monodroid-debug] Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8805,server=y,embedding=1,timeout=8 … [mono] Listening on 127.0.0.1:8805 (timeout=8 ms)... [mono] debugger-agent: Timed out waiting to connect. Of particular note from the above log messages is the `timeout=8` value, which is considerably lower than it needs to be, which is a [value in *milliseconds*][0]. This low value is responsible for the subsequent `debugger-agent: Timed out` log message. The `timeout=` value was introduced in commit 8e1c0e6, which used `%d` to convert the `timeout_time` value; [for context][1]: struct RuntimeOptions { int64_t timeout_time = 0; // … }; // … char *debug_arg = utils.monodroid_strdup_printf ( "--debugger-agent=transport=dt_socket,loglevel=%d,address=%s:%d,%sembedding=1,timeout=%d", loglevel, options.host, options.sdb_port, options.server ? "server=y," : "", options.timeout_time ); `options` is a `RuntimeOptions`, and `options.timeout_time` is thus a `int64_t`, but it's being `printf`d via `%d`. `%d` is supposed to be an *int*; from [**printf**(3)][2]: > **d**, **i** > The *int* argument is converted to signed decimal notation. which means using `%d` for an `int64_t` will only work properly on ILP64 targets. Android, notably, is an ILP32 (32-bit) or LP64 (64-bit) target, *never* ILP64; it's a wonder this worked *anywhere*, with any degree of reliability. The fix is to realize that it doesn't even make sense to be forwarding `RuntimeOptions::timeout_time` in this manner in the first place: `RuntimeOptions::timeout_time` is compared against `time(NULL)`, i.e. it's a [Unix time value][3] (*seconds* since 1970-01-01 UTC), not a value in milliseconds at all! Replacing the use of `options.timeout_time` with 30000 allows for a value that is reasonable for the target domain, *and* works properly and consistently on both ILP32 (32-bit) and LP64 (64-bit) Android targets. [0]: https://github.com/dotnet/runtime/blob/9022f3a9b63b56234726606bc5547378b2d08f6b/src/mono/mono/component/debugger-agent.c#L581 [1]: https://github.com/dotnet/android/blob/8e1c0e6e2f4c41c9a24904bb1cea943357d78ac4/src/monodroid/jni/monodroid-glue-internal.hh#L98-L106 [2]: https://linux.die.net/man/3/printf [3]: https://en.wikipedia.org/wiki/Unix_time
|
Wow, beautiful work. Please when will this fix be available to use? |
|
If we can get Fix Debugger timeout on 32 bit devices for .net 9 #9880 in, then it will be in the next .net 9 Release which is next month I think. |
Fixes: #9573 Context: 8e1c0e6 A customer reports that they are unable to attach a debugger to 32-bit Android apps: > am start -a "android.intent.action.MAIN" -c "android.intent.category.LAUNCHER" -n "com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity" > Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity } … [monodroid-debug] Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8805,server=y,embedding=1,timeout=8 … [mono] Listening on 127.0.0.1:8805 (timeout=8 ms)... [mono] debugger-agent: Timed out waiting to connect. Of particular note from the above log messages is the `timeout=8` value, which is considerably lower than it needs to be, which is a [value in *milliseconds*][0]. This low value is responsible for the subsequent `debugger-agent: Timed out` log message. The `timeout=` value was introduced in commit 8e1c0e6, which used `%d` to convert the `timeout_time` value; [for context][1]: struct RuntimeOptions { int64_t timeout_time = 0; // … }; // … char *debug_arg = utils.monodroid_strdup_printf ( "--debugger-agent=transport=dt_socket,loglevel=%d,address=%s:%d,%sembedding=1,timeout=%d", loglevel, options.host, options.sdb_port, options.server ? "server=y," : "", options.timeout_time ); `options` is a `RuntimeOptions`, and `options.timeout_time` is thus a `int64_t`, but it's being `printf`d via `%d`. `%d` is supposed to be an *int*; from [**printf**(3)][2]: > **d**, **i** > The *int* argument is converted to signed decimal notation. which means using `%d` for an `int64_t` will only work properly on ILP64 targets. Android, notably, is an ILP32 (32-bit) or LP64 (64-bit) target, *never* ILP64; it's a wonder this worked *anywhere*, with any degree of reliability. The fix is to realize that it doesn't even make sense to be forwarding `RuntimeOptions::timeout_time` in this manner in the first place: `RuntimeOptions::timeout_time` is compared against `time(NULL)`, i.e. it's a [Unix time value][3] (*seconds* since 1970-01-01 UTC), not a value in milliseconds at all! Replacing the use of `options.timeout_time` with 30000 allows for a value that is reasonable for the target domain, *and* works properly and consistently on both ILP32 (32-bit) and LP64 (64-bit) Android targets. [0]: https://github.com/dotnet/runtime/blob/9022f3a9b63b56234726606bc5547378b2d08f6b/src/mono/mono/component/debugger-agent.c#L581 [1]: https://github.com/dotnet/android/blob/8e1c0e6e2f4c41c9a24904bb1cea943357d78ac4/src/monodroid/jni/monodroid-glue-internal.hh#L98-L106 [2]: https://linux.die.net/man/3/printf [3]: https://en.wikipedia.org/wiki/Unix_time
Fixes: #9573 Context: 8e1c0e6 A customer reports that they are unable to attach a debugger to 32-bit Android apps: > am start -a "android.intent.action.MAIN" -c "android.intent.category.LAUNCHER" -n "com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity" > Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.companyname.exemploandroid/crc64358cda76bdc6f75f.MainActivity } … [monodroid-debug] Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8805,server=y,embedding=1,timeout=8 … [mono] Listening on 127.0.0.1:8805 (timeout=8 ms)... [mono] debugger-agent: Timed out waiting to connect. Of particular note from the above log messages is the `timeout=8` value, which is considerably lower than it needs to be, which is a [value in *milliseconds*][0]. This low value is responsible for the subsequent `debugger-agent: Timed out` log message. The `timeout=` value was introduced in commit 8e1c0e6, which used `%d` to convert the `timeout_time` value; [for context][1]: struct RuntimeOptions { int64_t timeout_time = 0; // … }; // … char *debug_arg = utils.monodroid_strdup_printf ( "--debugger-agent=transport=dt_socket,loglevel=%d,address=%s:%d,%sembedding=1,timeout=%d", loglevel, options.host, options.sdb_port, options.server ? "server=y," : "", options.timeout_time ); `options` is a `RuntimeOptions`, and `options.timeout_time` is thus a `int64_t`, but it's being `printf`d via `%d`. `%d` is supposed to be an *int*; from [**printf**(3)][2]: > **d**, **i** > The *int* argument is converted to signed decimal notation. which means using `%d` for an `int64_t` will only work properly on ILP64 targets. Android, notably, is an ILP32 (32-bit) or LP64 (64-bit) target, *never* ILP64; it's a wonder this worked *anywhere*, with any degree of reliability. The fix is to realize that it doesn't even make sense to be forwarding `RuntimeOptions::timeout_time` in this manner in the first place: `RuntimeOptions::timeout_time` is compared against `time(NULL)`, i.e. it's a [Unix time value][3] (*seconds* since 1970-01-01 UTC), not a value in milliseconds at all! Replacing the use of `options.timeout_time` with 30000 allows for a value that is reasonable for the target domain, *and* works properly and consistently on both ILP32 (32-bit) and LP64 (64-bit) Android targets. [0]: https://github.com/dotnet/runtime/blob/9022f3a9b63b56234726606bc5547378b2d08f6b/src/mono/mono/component/debugger-agent.c#L581 [1]: https://github.com/dotnet/android/blob/8e1c0e6e2f4c41c9a24904bb1cea943357d78ac4/src/monodroid/jni/monodroid-glue-internal.hh#L98-L106 [2]: https://linux.die.net/man/3/printf [3]: https://en.wikipedia.org/wiki/Unix_time Co-authored-by: Jonathan Pryor <[email protected]>
Android framework version
net9.0-android
Affected platform version
VS 17.12.2, SDK 9.0.100, Windows 11 24H2
Description
The system compiles the code and sends it to the Android phone, however, after generating the .apk package in the system correctly, Visual Studio does not allow me to debug it.
I can open the generated package on my cell phone without errors, but I cannot debug it using 'hot reload' in any way.
Cell phone model: Motorola G(8)
Android Version: Android 10
Detail, on the same machine I have another application developed in Xamarin for the same cell phone, and I can debug it normally.
Steps to Reproduce
Video Error:
https://github.com/user-attachments/assets/4260e896-6c6a-4fd8-9101-87aff3ee9893
1 - Start Visual Studio
2 - Create a New Project
3 - .NET MAUI App (name: ExemploAndroid)
4 - Net 9
('include sample content' NOT selected)
Change the file 'ExemploAndroid.csproj' to:
Plug in your cell phone (already configured in developer mode), choose to debug and after deployment, Visual Studio stops debugging.
Did you find any workaround?
unfortunately not.
Relevant log output
The text was updated successfully, but these errors were encountered: