-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No support for debugging library projects #13
Comments
I've created a patch that adds this functionality:
|
Actually, @jmgao thinks that patch will probably break some of the other use cases (I'll let him elaborate). Since you have a fix that you can apply locally, and he doesn't have time to look more closely right now (I'm hoping we get r11b out this week), I'm going to move this to r12. |
OK, I am looking forward to @jmgao 's elaboration. If omitting parsing of manifest may break some things, this can be written differently - in parse_manifest function one could skip extracting package name if it is already given via command line argument. |
Sorry, had a backlog of other things that were on fire. The patch as written doesn't disallow the use of --launch/--launch-activity with --package, which would fail because the manifest wouldn't have been parsed. I added it as an optional argument to --attach in this change, which should hopefully make it to r11c. Out of curiosity, what does your project layout/build look like, and what are you mostly using ndk-gdb for? Would it be helpful for you if there were arguments to specify additional projects/directories to find libraries from? (e.g. something like |
Hi @jmgao!
At MicroBlink, we develop SDK which performs camera management and real time camera image processing - mostly for decoding barcodes and performing OCR. So, we have a library project which contains camera management code and native wrapper. This library project has several flavours - one for each SDK we are offering. Each flavour has its own set of native build parameters (specific compiler flags and source file set) and its own java classes and resources. For each flavour we have a "test" app which we use to test camera management behaviour, scanning behaviour and overall performance. I've described our project layout in more detail in this blog post. We use ndk-gdb primarily to debug native code from these test apps - as you can see, several apps with different package names all use the very same library module which contains native code. For that matter, we need support for debugging native code in library projects. We usually launch an app and then attach the debugger, so
I am not sure. The reason for this is that we use Android Studio for development, and we use custom NDK build script as described here, i.e. in I hope it is now clear why we need support for debugging of library projects. |
This is useful for library projects. Bug: #13 Change-Id: I000997de803ebfdf55ebdb89d868f4300a6902b4
This got added to r12, right? Can this be closed? |
Actually r11c has got |
In r10, I could run
ndk-gdb --package=my.app.package
to debug native code inside android library from test app.In r11,
ndk-gdb
bash script has been removed andndk-gdb.py
does not support that. Please add this feature back.The text was updated successfully, but these errors were encountered: