This chapter describes known problems which can arise during development for Android system. There are four groups of problems:
Please be aware of the fact, that WinGDB is a user interface product working with existing tools and can not solve problems inherent to these tools.
ADB tool (Android Debug Bridge) is itself buggy and sometimes hang. Typically it can happen while deploying the package. WinGDB has a watchdog timer to prevent infinite hang of Visual Studio (60 seconds, can be altered in Preferences). If the deploy process freezes for a significantly longer time than usual, use 'Restart ADB Server' option from WinGDB menu, or find and terminate all ADB processes using the task manager. If it happens regularly and is caused by very long transfer time, enlarge the limit. When using recent SDK versions this problem should not appear frequently, but it is not guaranteed for all possible devices nor old Android versions on the target.
Android SDK/NDK should not be installed a directory whose path contains spaces. Otherwise various problems may occur. This is a problem of NDK/SDK itself. Other tools seem to work with spaces in paths, however this is generally not recommended to use such paths in any circumstances thah involve development for Linux/Unix based systems (including Android). Common intuition says that spaces in paths and Linux/Unix/Cygwin do not match very well -- better avoid them at all.
Such errors typically have one of the following causes:
There are problems when debugging on multicore CPUs due to low-level bugs in NDK debugging tools. Known devices affected are all NVIDIA Tegra based multicore devices, as well as some other like the Galaxy Nexus. The workaround is to disable extra cores. It can be done using the Device Monitor window (Cores page). For Tegra devices you also must use Tegra development pack from NVIDIA, standard SDK+NDK will not work.
The workaround works only with rooted devices (no problem for Tegra devkits). For non-rooted ones, no workaround is currently known.
Do not use several different versions of Android SDK at once, for example one version configured in WinGDB, and another to launch tools from the command line (might be on your PATH also). This can lead to unpredictable results, including hangs of a debug session. This is because ADB runs system-wide process to coordinate multiple connections, and this process is killed (with all these connections) when launch of conflicting SDK tool is detected. ADB gives very little diagnostics for this case and WinGDB has no possibility to react properly. Just ensure single SDK is used.
Error message may appear at build. It concerns a debug certificate which Android SDK generates at installation. Unfortunately it is valid for one year only. To generate a new one please delete the existing one. It is located under: %USERPROFILE%\.android\debug.keystore.
In NDKr7 Google started to cut dependency on Cygwin, but simultaneously introduced some problems. At build you
may meet such error messages:
C:\android\android-ndk-r7\prebuilt\windows\bin\awk.exe: can't open file /cygdrive/c/android/android-ndk-r7/build/awk/check-awk.awk
source line number 1 source file /cygdrive/c/android/android-ndk-r7/build/awk/check-awk.awk context is
Android NDK: Host 'awk' test returned:
Android NDK: Host 'awk' tool is outdated. Please define HOST_AWK to point to Gawk or Nawk !
/cygdrive/c/android/android-ndk-r7/build/core/init.mk(258): error: *** Android NDK: Aborting. . Stop.
Change target to supported one. The target property is available in project properties | Common | General | Target platform. Additionally change "API Levels | Minimum API Level" to expected value. You may also want to change following properties in that section: Target API Level and Maximum API Level.
This might be due to old, unsupported versions of Cygwin. Please ensure that you use recent version.
A crashing shell (or any other Cygwin executable) indicates Cygwin bug. Install newer version.
These might be caused by well-known (and impossible to fix) Cygwin bug. Search on the net for cygwin fork crash (or failure, problem, etc. instead of crash) to find more info. There is no proper fix, although on clean Windows systems (esp. without any antivirus software) the bug should not be frequent or even occur at all.
This is yet another Cygwin bug. You can delete such file from Cygwin console (bash.exe). Launch the console, go to the affected directory and execute the following command:
rm NUL
Change in project properties | Configuration | Source | C++ Standard Library to value "Static STLPort" or "Shared STLPort" or "Static GNU libstdc++".
Appears when you try to install package built for newer/higher target (e.g. Android-14) on device/emulator supporting older/lower target (e.g. Android-10). Try change the target property in project properties | Common | General | Target platform. Additionally you may be interested in changing values in "API Levels", i.e. Minimum/Target/Maximum API Level. Alternatively just use suitable device/emultor.
Appears when you try to install package signed with other key than its current copy on specified device/emulator. It also concerns case where is mixture of production key and debug key. The problem may appear also when you've installed package from another computer, with other key too.
To solve the problem try to uninstall package, before you install the new copy. To uninstall package go to WinGDB | Android | Show device monitor window. Choose proper device (or emulator), then in combo-box "Page:" select option "Packages". There appear list of packages, choose specified one and run command from context-menu "Uninstall" or "Uninstall and clear".
While debugging applications built with NDKr7 there may be meet serious problems like:
0) cannot set breakpoint on specified line
1) at stepping through code the pointer jumps in unpredictable way between various locations
2) crashes
In such case flag -gstabs may be helpful. To add it call context menu on Project in
Solution Window, then Properties | Configuration | Additional C compiler flags, and insert there -gstabs.
The same for "Additional C++ compiler flags" if project contains C++ sources.
It may help in some cases, although workaround is not perfect. If it doesn't help the only solution is
to wait for newer NDK or just use older version (problem does not occur in NDKr6).
The problem does not concern NVIDIA devpack - applications built with it and NDKr7 work correctly
under the debugger. Additionally, NVIDIA provides a newer debugger than Google (GDB 7.2 instead of 6.6) which is much
better in terms of stability and features.
In NDK r8 Google changed GDB version from 6.6 to 7.3.1. While the upgrade itself is a good thing (6.6 was really obsolete), the new debugger seems to be seriously broken. The problem with breakpoints is an effect of GDB being unable to resolve source file path. GDB 6.6 version did resolve same path correctly.
Currently there is no workaround. Just avoid NDK r8.
A subliminal message to Larry Page ;-)
Larry, have you ever considered hiring some QA staff?
This is due to limitations of Visual Studio Extensibility. We currently have a plan how to solve this problem. WinGDB will provide its own language services for C++, C and Java languages. Currently the parsers are in late stage of development. The lexical phase of analysis is finished for all these languages and currently enabled as source of data for syntax coloring, brace matching, code outlining and several other features not requiring syntactic analysis. The syntactic analyzers are in development. The next stage will enable program entity browsers. The final stage will allow to enable member listings, immediate error detection, definition search / definition window and other advanced features.
The C++ back-end does not use clang nor any other third party components. It is planned to support full C++/2003 and currently it is close to that state, except function templates and nested templates (class templates and their specializations are already implemented).
The language analysis engine is meant to be used primarily in our other products, but the Android edition will serve as testing ground for them.
This will be addressed in the future, as it should be possible to use run-as command to kill some processes (but not important ones).
This problem will be addressed in some future release. It has impact only when using source control systems which require explicit checkout to make changes in the file. You must check out the file manually before editing. Systems working like SVN are not affected.
This will also change in the future (possibly depending on demand from potential users).
This bug will be addressed in some future release.
If you get at start of debugging session message-box with contents similiar to those below:
Could not launch the process:
Error starting the debugger:
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
Check debugger path settings in WinGDB/Preferences/General page
and in project/solution properties.
or
Could not launch the process:
Error starting the debugger:
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]
Check debugger path settings in WinGDB/Preferences/General page
and in project/solution properties.
Please ensure that: WinGDB is not Eclipse. It is completely new software which does not reuse any code from Eclipse. Therefore some features might work in Eclipse but not in WinGDB - or vice versa. The long-term goal is to have all Eclipse has and more, but it will take some time and more important features are done first.
There is a problem with colors settings synchronization in VS Shell when you install for the first time. You have to open Tools/Options/Fonts and Colors dialog and manually change some colors. The colors you adjust will be used for syntax coloring from that time. Only default (never changed) colors do not synchronize. We are still investigating the cause of the problem.
There are plenty of Android devices on the market. They have a variety of OS versions, many of them customized by a vendor. Sometimes these versions are very old. Other times they are incomplete, e.g. certain shell commands are missing. Generally speaking, it is impossible to support every possible device in the world.
WinGDB is being tested on a number of different devices, single- and multicore. The base is expanded over time. But there is no a priori guarantee that it will work with your particular device. However, if back-end Android tools work, then chances are WinGDB will work also. Please use the trial version to test before you buy. In case of problems, do not hesitate to contact us. WinGDB has many diagnostic features which can help to find the cause of a problem with particular device.
When in doubt, test on the emulator. WinGDB should always work with the emulator. If it does not, then it is a bug.
Also be aware of the fact that many devices require some configuration steps to be able to connect a debugger to them. Some require enabling Debug mode, while others might need installing modified OS image. Stock phones are usually protected from external access for security reasons. Some devices might require specific drivers. These special requirements are outside of the scope of WinGDB. It is up to you to figure out what is to be done. WinGDB does not aim at being a "magical" solution to all device problems, as it is simply not doable due to high variety and fragmentation of Android device market.
The Android emulator included in SDK is quite slow and unfortunately this is noticeable while debugging. You might experience several second delay during stepping. Delays longer than a couple of seconds should be rather uncommon.
This is explained on appropriate documentation pages several times, but we restate it here: there is a tool called AVD in Android SDK which is intended to configure, manage and launch emulator instances. This program does its job perfectly and there is no point in rewriting it. Please use AVD to choose emulator configuration and start it before starting debugging session in WinGDB.
WinGDB can not start the emulator because you can have multiple emulator configurations (e.g. with different Android versions) and WinGDB does not know which one to start.
You also do not need to exit the emulator when finished debugging. WinGDB does not kill it. Many debug sessions can be launched one after one, as the package is deployed every time and your changes are always reflected.
If you previously used Eclipse to start the emulator, most likely you can still do it this way. However, AVD is the recommended method.
We often receive reports on non-functioning breakpoints. However the most common cause is that the particular line in user's code just does not get executed at all, hence no stop on breakpoint. This is absolutely correct behavior of the debugger.
One particular case is when the native library is not being loaded at all. You can use Android system log to diagnose such errors, as it displays a message every time system loads a library. Possible cause might be that the library is mistakenly configured as static module (instead of shared), or you forget to call System.loadLibrary from your Java code, or the library name does not match.
If you are sure that the code is executed, the problem might be different: