I have an Android project which includes NDK code. From this code, I need to call functions from other libraries built with NDK, which I have in the jniLibs folder:
jniLibs/armeabi/libtess.so
jniLibs/armeabi-v7a/libtess.so
...
if I try to load these libraries from java, as System.loadLibrary("tess"), it works fine.
However, when I try to link my NDK library to it by adding this to build.gradle:
ndk {
moduleName "myJNILib"
stl "stlport_shared"
ldLibs "log", "tess"
}
it cannot find it.
And of course, if I don't link against it, it cannot compile myJNILib, since it can't find the symbols.
Is there anyway to make this work using gradle? Or I really need to build my library outside of gradle if I want to link with other prebuilt libraries?
What I think you'll want to do is mostly rely on the natural NDK building... stuff... I'm not sure what a good word for that is.
Anyway, you'll want to follow this tutorial. It worked for my own stuff pretty neatly. You'll also, more than likely, want to read this introduction to Android.mk files. It's very helpful for debugging and making sure you're linking correctly.
You may run into two problems in doing this:
Undefined symbol errors, which can be an absolute pain. More than likely you will want to eliminate that dependency. I spent hours on this problem and finally concluded that the file must just not be there. Somehow.
You may also run into it not being able to find an extension of the file you're working on (Ergo, it may say that foo1.so can't find the library foo2.so.# despite you having linked foo2.so. You may have to compile a .a library if that happens, but that may not be the best solution.).
Well, I hope that helps!
Related
I'm trying to cross-compile the qhull library for Android, on a Linux x86-64 host. I'm fairly new to CMake, but rather experienced with other buildsystem tools.
I've setup a toolchain file, according to all the recommendations I've found, and it has worked for several other packages. Yet, no matter what I try, nothing seems to augment the linker path for one or more of qhull's executable programs. The problem is that it can't find Android NDK's libsup++.a, which is an implicit dependency of its compiler (GCC). If I take the generated link command and manually add -Lpath_to_libsup++.a, then the link succeeds.
In my toolchain file, among the things I've tried are:
CMAKE_FIND_ROOT_PATH
link_directories()
CMAKE_EXE_LINKER_FLAGS
I don't see anything unusual about its CMakeLists.txt, at least with respect to the first point of failure (user_eg3).
I'd prefer not to patch the library, if possible. I know many others are using this on Android (it's a dependency of point cloud library), so I assume I'm probably missing a step.
BTW, I'm using CMake v3.4.3, Android NDK r10e, and qhull v7.2.0.
I found a workaround.
In this post, Florian mentioned that CMake internally sets CMAKE_EXE_LINKER_FLAGS_INIT to $ENV{LDFLAGS}. I've found that if I set the environment variable LDFLAGS=-Lpath_to_libsup++.a, it gets passed through to the link command, which now succeeds.
I'd still like to know the proper CMake solution to this problem. Or, if the problem lies with qhull, then maybe someone can peek at its CMakeLists.txt (linked above) and point out what it's doing wrong.
I've been working for a month with android ndk, so I am quite a newbie. Currently I am trying to integrate some code into a big project and have multiple problems both with NDK and gstreamer. Questions are stupid but I would be very grateful if someone helped me:
1) After I build and compile a project, do I still need all of those Android.mk files? Or can I just add .so libraries using System.loadlibrary("library")?
2) After I build my .so files, do I still need to declare all .a files as build-shared libraries and link them to the .so which needs them?
3) When I add native android support, do I need to create separate libsomename.so or choose the existing?
Maybe someone could also link me to the good article about building?
1)No, if its already compiled all you need is the so and loadLibrary call. However, if you want to update the library with your app its probably a good idea to keep them
2)No, once you have a .so file that's all you need
3)I'm not sure what you're asking there.
first of all, i got into a problem last time when trying to compile a c program to linux- arm architecture, for using it in an android app later. I succeeded in doing so, and i'll write later a post on how to use the NDK standalone toolchain.
Now that i've finally got that working, I'm trying to compile a .c file, which has a line "include bluetooth/bluetooth.h" in it. When I try to compile the file, i get a: "no such file or directory" error on it. My makefile includes the word "-libbluetooth".
The standart NDK gcc library does'nt have a bluetooth support, so i've downloaded "libbluetooth.so" from my device, which is what i needed to make it work, according to the brief research on the subject over the internet. I still get the same error.
I'll be glad to know if anyone has encountered the same problem.
thank u
Dekel
You need the bluetooth library to link your program; but to compile it, you need the appropriate headers. libbluetooth.so is not part of Android official API, but luckily you can find it sources and the include files that declare its public (but unofficial) API, if you download the AOSP source tree, according to Google's instructions. Actually, you are interested in a small part of the tree: ./external/bluetooth/bluez/lib. There you will find the bluetooth/bluetooth.h include file. In your Android.mk, you will have a line similar to:
LOCAL_C_INCLUDES += $(AOSP_ROOT)/external/bluetooth/bluez/lib
So, I have a little C library. I want to make this library available to other devs that develop native C code in android (other libraries, native apps etc).
What's the best way to go? I don't really have much clue yet, trying to figure all this out.
I've read that there are two paths to go with the NDK: using Android.mk and using create-standalone-toolchain -- is this correct? How does each one of these works? Is there a third way without the NDK, and should this be used now that the NDK is available?
**
This may have been asked before, but I understand things have changed since the release of the NDK, as a lot of posts I find seem obsolete.
this question can have a Huge answer, I will try to be as brief as possible.
Using the Android NDK, make a new android project, create a JNI folder, and create an Android.mk file, in it, make two libs, one being your lib, exported as a shared lib and the other, a jniwrapper that will test it. Here is an example of how it was done by a guy for his own lib.
You can make a shared lib by compiling with the standalone toolchain, here is an article on the subject and also take a look at the curl Readme for android, it explains how to compile curl for Android using the standalone toolchain, I believe it's the better way to do it, and also to easier for you since you will use the cross-compiler in a regular fasion...
A project that I am trying to build has one of these, and I want to know exactly which tools are needed to build the project. I see some reference to NDK when I search but is that the only tool? It appears that this file is making a jar file, I see no reference to native code ( c++ )
The Android.mk files in the SDK samples are required to properly include the samples in the SDK build (if you are actually venturing into that territory). These have no bearing on what you are doing when you use the sample. To the OP, I'm not sure if you are using a sample project, but if you are, you can ignore this file.
the best answer to your question is reading this article:
Android.mk file syntax specification
https://android.googlesource.com/platform/ndk/+/4e159d95ebf23b5f72bb707b0cb1518ef96b3d03/docs/ANDROID-MK.TXT
after reading it you can figure out the idea behind the android.mk file.
cheers
I've seen some of the Android sample code come with an Android.mk file for no apparent reason -- maybe this gets auto-generated upon project creation if you happen to have the NDK installed or something. Android.mk does seem to be an NDK-specific thing.
So if there's really no native code involved, then if you're looking to build from the command line, make sure you have the JDK, Ant, and Android SDK installed.
Then take a look at
http://developer.android.com/guide/developing/projects/projects-cmdline.html#UpdatingAProject
After you run the "android update project ..." step, you should hopefully be able to do an "ant debug" to build the application.