Unable to debug Android on 8.2 beta

Today I upgrade my development environment to 8.2 beta from 8.1, and find I can’t debug my android project which works fine on 8.1.
I’ve aslo tried a new empty androd project, and still get the problem.

The debug process seems be stuck when the output window shows below info:

My environment: VS 2015 RTM + Elements 8.2.88.1805

Please solve this severe bug of Elements 8.2 beta, otherwise 8.2 is useless for me.

It’s confirmed because if I downgrade from 8.2 to 8.1 Android debug works fine.

Environment:
Win8.1/Win10 RTM + VS2015 Community + Elements 8.2.88.1809

You are aware what “beta” means, right?

We’re looking into the issue and we’ll fix it as soon as we can. but 8.2 is in beta, so it’s expected that there will be bugs and regressions, and that stuff wont work. Don’t rely on needing a beta build for production work.

Sorry but I was afraid this is ignored, because there’s no reply to log it as a bug or tell if it’s reproduceable after almost two weeks.

My apologies for not replying sooner to this thread, then. There was a second thread about the same issue, and I probably got them mixed up or didn’t realize there were two. In addition, a few key devs from the Elements team were on vacation this past couple of weeks, which is why things have been moving ahead more slowly.

Thanks, logged as bugs://72661

If my Android application crash, it’s not stopped in correct location in Visual Studio (in C# (not RemObjects) it just like there is virtual breakpoint at the crash location).
So I need to stop Visual Studio and run manually from Android then try to reproduce the crash while watching logcat.
It’s make Visual Studio useless if crash happened.
It’s happen in 8.1 (not beta) and 8.2 (beta).

Ok, that seems to be an unrelated issue. Can you start a new thread and provide more details, such as test case? Thanx!

After the 8.2.88.1811, it’s OK to debug, but the LogCat/Output is still not working.

The Output always stops here:
http://talk.remobjects.com/uploads/default/original/2X/7/7827558c08e793a1f8a0a06b7f7fad8a05ac294e.PNG

Curious; I didn’t actually get to this issue yet, but glad to see it’s at least partially solved now.

@Esword: Just tried this and I get:

Seems to both break on breakpoints & emit logcat.

Forgot to mention that I’m using the Android SDK ARM emulator or a real device, is this related? Maybe I can try your emulator?

I’ve reproduced it many times: breakpoints & logcat both work fine on 8.1.85.1801, but after I upgrade to any beta version of 8.2, they can’t behavior normally.

In rare conditions, the breakpoints works but logcat is dead as I posted days ago.

But at present when I try to reproduce the issue on 8.2.88.1819, the problem is severe again:

The emulators I use are the VS included Android emulators.

I’ve just installed the VS Android emulators, but don’t know how to deploy my android app to it via CrossBox, because the CrossBox can only detect my three Android SDK emulators (41_47, 44_40, 51_4):

I’ve also found ADB can’t detect my VS Android Emulator. If this VS emulator works fine, maybe my problem is related to ADB?

that’s probably becaue you now probably have two Android installs. I think VS uses the one from

C:\Program Files (x86)\Android\android-sdk

If you make Elements use that too it should work (might need a restart of VS)

I install the standalone VS Android Emulator without a new Android SDK from VS setup. But finally I find a solution to make the VS Android Emulator use my existed Android SDK automatically:
Add a Path registry variable in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Android SDK Tools

I’ve also installed the new Elements 8.2.88.1825, and start a series of tests.

  1. Things go better with VS Android Emulator(x86) and my physical device Galaxy Nexus(ARM) : Debugger works, but Output window is stuck. I’ve started a new thread to trace it: Output window can’t print Android Logcat content

  2. But the issue is still on Android SDK Emulator(ARM): the app gets stuck by waiting for debugger forever.

So could you help to check if my issue can be reproduced on your Android SDK Emulator(ARM)?
In most cases, x86 emulator and physical device are much faster than ARM emulator. I guess maybe the cause is sth related to the time-out issue of the communication between Elements and ADB.

Reproduced the Android ARM emulator issue. I’ll look into that one.

bugs://72661 got closed with status fixed.