Forum Replies Created
-
Posts
-
Hi,
The Android emulator is the answer here. It is unbelievably slow compared to the actual Android devices. However, note that you would need an actual Windows machine (not a VM) to debug a physical phone or a tablet, as the Android USB driver does not work well with VirtualBox/VMWare.
Hi,
Building from Eclipse works, as Eclipse uses a separate eclipse-specific build system plugin, while VisualGDB relies on Apache ANT (official command-line build tool for Android).
Looks like your build.xml file is either generated by an old version of Android SDK or has been replaced by some other tool.
Please try deleting it and rebuilding the project. VisualGDB should rebuild the build.xml file automatically.If the problem persists, please attach the log of the first build (after deleting build.xml) and specify your Android SDK version.
You can also try deleting/renaming the build.properties file.
Strange. Please attach your build.xml file here or send it to support@sysprogs.com so that we can try to reproduce your problem.
Hi,
After setting the environment variable you need to restart Visual Studio (or better restart your computer) to get the environment variable propagated.
The problem seems to be quite common for Android SDK (e.g. see here: http://blog.klacansky.com/matter-code/ant-taskdef-class-com-android-ant-setuptask-cannot-be-found).
Could you please attach the D:GabySoftGCodeHexLogicAndroidbuild.xml file here?Hi,
The build problem is caused by the ANDROID_SDK_ROOT environment variable. Please go to System Settings, Environment Variables and set a new Environment Variable for the current user:
Name: ANDROID_SDK_ROOT
Value: directory where you have installed Android SDKNote that VisualGDB 2.8 will provide ANDROID_SDK_ROOT automatically and won’t require this trick any more.
Regarding the breakpoints, there are numerous breakpoint bugs in ndk-gdb and VisualGDB provides workarounds for most of them. If it does not work in your case, please do the following:
1. Open VisualGDB Project Properties (right-click on the project in Solution Explorer).
2. Go to GDB Settings tab.
3. Check the “Log all interaction with GDB” checkbox.
4. Start debugging. Try setting breakpoints.
5. In the GDB Session window run the following commands:info shared sharedlibrary6. Try setting your breakpoints again.
7. Exit debug session.Then please send all .log files from your project directory to support@sysprogs.com so that we can diagnose your problem further.
Hi,
The portable WinCDEmu uses a special driver build that does not rely on .inf files.
Try the new experimental build: http://wincdemu.sysprogs.org/portable/PortableWinCDEmu-3.6.exeHi, guys. Sorry for the delay, got far too many things to do.
Try this build: http://wincdemu.sysprogs.org/portable/PortableWinCDEmu-3.6.exe
Note that it has not been through the usual testing cycle, so feel free to report any bugs…There are many ways in which the source files can be listed in a Makefile and no possible way to support all of them.
Are you using VisualGDB-generated makefiles or your own makefile layout?Hi,
Please change the configuration type to “Makefile project” in Visual Studio project properties (not VisualGDB project properties).
Hi,
That is by design, as VisualGDB cannot distinguish between source files added by someone else and generated files or temporary files.
Note that this should not stop VisualGDB from building and debugging the project correctly if the Makefile was updated by the person adding a new source file.Hi,
Thanks for reporting this problem. Currently VisualGDB does not set ANDROID_SDK_ROOT. You can fix it by setting the variable before running Visual Studio: e.g. make a bat file containing the following lines:
set ANDROID_SDK_ROOT=C:PROGRA~2Androidandroid-sdk "C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEdevenv.exe"We will add the ANDROID_SDK_ROOT support to the next version of VisualGDB.
Hi,
You can specify additional parameters to make by right-clicking on the project in Solution Explorer, selecting “VisualGDB Project Properties” and specifying additional ndk-build arguments. The ndk-build.cmd is currently fixed and cannot be changed via settings. If you want to use a custom build script instead, please write a letter to support@sysprogs.com, we’ll send you a custom build that can do it.
As mentioned before, please send us the GDB log so that we can actually see what’s happening and give you more advice
Hi,
That’s strange. Uninstalling the app should normally reset the state.
As mentioned before, please send us the GDB log so that we can actually see what’s happening and give you more advice.Hi,
There’s a bug in the NDK version of GDB that causes breakpoint problems. VisualGDB fixes it for obvious cases like the JNI directory, but probably does not fix it for your project.
Please open the GDB Session window, select “All interaction with GDB” and try settings your breakpoints. Then send us (or post here) the contents of the GDB Session window. It will contain the GDB commands and replies related to the breakpoints and will help us determine why your breakpoints are not working.You can also try executing the “sharedlibrary” and “info shared” commands in the GDB session window to ensure that your symbols are loaded correctly.
