[Android] Debugging NDK make libraries

[Knu]

Hello,

this is my setup:

CoreLibrary.a <- static , core library
HelperLibrary.a <- helper static library, built on base of CoreLibrary.a
MyDLL.so <- actual dynamic library built upon HelperLibrary.a These are built using visual studio and NDK. I use MyDLL.so p/invoked from xamarin. So far, so good. Now, i want to debug this dynamic library: as far as i’ve understood i have to convert it into a VisuaLGDB project? Can’t i just add the .so project i already have to the solution generated from the wizard? I tried that way, but on build the .so isn’t packed inside the apk. I tried manually copying it into /lib/ but on build that directory gets cleaned up (so i’m clearly doing it wrong or missing something). Can’t find a place to say “please embed THIS dynamic library into deployment” in the visualGDB project properties. I tried then to debug the apk i already have but i get an error about not having GDB for armv7-a, do i really need to build everything for armeabi and debug it on emulator? What if i want to debug on device, what am i missing here? What’s the best course of action? I’m not really sure where to go from here. Thanks in advance!

[ket]

Hi,

Starting from VisualGDB version 4.0, setting project dependencies will set the library usage lines in Android.mk. Always check the Android.mk file changes after setting the project dependencies and building the solution for the first time. If the library project builds both static and dynamic versions of the library, then VisualGDB will try to guess which dependency to actually make.

If you want to include a native library not built with VisualGDB inside the same solution in Visual Studio, then look into your Android NDK install directory’s docs folder and read PREBUILTS.html, that will tell you how to include the library in the Android.mk file.

In VisualGDB Project Properties you can turn off the option to delete the libs folder on clean.

Getting an error that GDB for armv7-a does not exist is strange, please post the full error message and logs given here. Debugging on devices and emulators is both supported. Please note that if you are using a armv7-a device, then you also need to build your libraries and app for this armv7-a abi.

[Knu]

Hi,

thanks for your fast answer. Sorry if my english was a little shaky on my previous post: i wrote it after a LONG day 😀

However, i did what you suggested and it looks like i can include my own library now. I created a new project (Set to NOT update Android.mk automatically this time) and added to Android.mk

include $(CLEAR_VARS)
LOCAL_MODULE := libsandBoxTestAndroid-prebuilt
LOCAL_SRC_FILES := ../../Android/Debug/libsandBoxTestAndroid.so
include $(PREBUILT_SHARED_LIBRARY)

and changed Application.mk to

APP_ABI := armeabi-v7a

If i check the built APK, i can see that in lib/armeabi-v7a/ finally there is libsandBoxTestAndroid.so – great!

I then tried to load the library by editing the C source file from the wizard

	char szBuf[512];
sprintf(szBuf, "You have pressed this huge button %d times", s_ButtonPressCounter++);

void * myLibHandle;
myLibHandle = dlopen("libsandBoxTestAndroid.so", RTLD_NOW );

if(!myLibHandle)
sprintf(szBuf, "%s", dlerror() );

however dlopen() is not happy

Cannot load library: load_library[1091]: Library libsandBoxTestAndroid.so not found

unless i specify its absolute path

myLibHandle = dlopen("/data/data/com.visualgdb.example.NativeVSAndroidProject/lib/libsandBoxTestAndroid.so", RTLD_NOW );

But googling it looks like it’s a common issue? sorry for the offtopic, but maybe this comes in handy to somebody in the future (i’ll bother you more in the future, i guess 😀 )

Thanks again!

EDIT: i still have a question though – how come my breakpoints in source from the static libraries are never considered by GDB?

[ket]

Hi,

Try running the sharedlibrary command in the GDB Session window manually after dynamically loading the library. Some older gdb versions will not load the symbols automatically after the dlopen call. Make also sure that the included libraries are all built in the debug mode.

It makes sense that using dlopen just with the library name won’t work – the working directory of the app process is not inside the apk. The working directory can be root, meaning that no relative path is going to work. To confirm this, you can probably call some function in the c code to find out what the current working directory is.

[Knu]

that sounds reasonable, i remember i read about the sharedlibrary command but i didn’t actually remembered to try it :facepalm:

thanks again!

[Author]

Posts