如何调试没有ndk-build构建的Android项目

Question

I try to debug a very basic example Qt 5.3 Android native C++ project, and I would like to debug it on the target without using QtCreator or any other IDE like Eclipse but only NDK tools. This project is compiled through QtCreator tools using Android platform target, in debug mode (-O0, -g), using NDK toolchain, BUT NOT ndk-build.

Therefore I got my .apk, the application itself has been installed on the target and works, everything is fine up to that point. Now I want to execute it in debug mode using NDK tools.

I would like to use ndk-gdb as this seems to be one of the most obvious ways, therefore: - I created manually required files under my main project directory:

bin
src
res
...
jni
|-- Android.mk
`-- Application.mk
libs
|-- armeabi-v7a
|   |-- gdbserver
|   |-- gdb.setup

The tree above only underline the files I added by hand, given that they are normally created by ndk-gdb. Under the 'libs' directory is also stored the native library of the project, called by a simple java wrapper.

jni/Android.mk and jni/Application.mk contains the same single line:

APP_ABI := armeabi-v7a

gdb.setup:

set solib-search-path ./libs/armeabi-v7a
directory <myrootdir>/NDKToolchain/sysroot/usr/include <myrootdir>/NDKToolchain/include/c++/4.6 <myrootdir>/NDKToolchain/include/c++/4.6/arm-linux-androideabi/armv7-a [...]

I checked that the target was connected and accessible by installing the application using adb:

% adb install -r bin/QtApp-debug.apk

It worked ('success'), which I could check directly on the target.

Then when I try to run ndk-gdb, it failed:

% ndk-gdb --start --nowait --verbose

WARNING: The shell running this script isn't bash.  Although we try to avoid bashism in scripts, things can happen.
ndk-gdb: 84: Bad substitution
Android NDK installation path: [...]
Using default adb command: [...]/sdk/platform-tools//adb
ADB version found: Android Debug Bridge version 1.0.31
Using ADB flags: 
Using JDB command: 
Using auto-detected project path: .
Found package name: org.qtproject.example.fridgemagnets
ABIs targetted by application: armeabi-v7a
Device API Level: 18
Device CPU ABIs: armeabi-v7a armeabi
[: 564: 1: unexpected operator
Compatible device ABI: armeabi-v7a
Using gdb setup init: ./libs/armeabi-v7a/gdb.setup
Using toolchain prefix: [...]/ndk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-
Using app out directory: ./libs/armeabi-v7a
Found debuggable flag: false
Found gdb.setup under libs/armeabi-v7a, assuming app was built with NDK_DEBUG=1
ERROR: Could not extract package's data directory. Are you sure that
       your installed application is debuggable?

A previous run of ndk-gdb showed me that for some reason it wanted to use ./obj/local/armeabi-v7a as "app out directory", while I set it in gdb.set to ./libs/armeabi-v7a, therefore I had to hack the ndk-gdb script to force it to use the path I chosed. I don't believe this is related to my real issue (?)

Given that I didn't use ndk-build, I believe that my attempt to use ndk-gdb is hopeless, or at least that it will ask me too much work and hacking of NDK scripts which I don't want to do.

Thus 2 questions:

1. Did I miss something during my build or deployment for getting a debuggable app ? I know that debuggable flag in Manifest being 'false' is not necessarily an issue, as I built my app with debug flags. BTW this seems to be confirmed by the fact that the error message I get is not related to that flag but to the fact that the script seems to exepect a DATA_DIR folder somewhere...
2. Is there a way to debug my application, without using ndk-gdb (and any IDE), but for example just 'gdb' ?

Thanks in advance

Answer 1

Question 1:
I know that as of SDK r8 you can invoke ant with release or debug . Building with the debug flag might package or run your application differently. Thus allowing or disallowing debugging? This seems like it might be the issue.

Question 2:
From what I understand ndk-gdb does a lot of setup and communication with adb to allow debugging your application, as you may have seen from the script. I wouldn't suggest going down the rabbit hole of not using it.