I want to build some libraries into executables that I need to use with my application. For example I need to build the C library slocate, so that I can use it in my application. Another example, I have to build sqlite-3.1 db to be usable with Python from ASE.
How can I go about achieving that?
Thanks a lot.
You need to build them using the Android NDK. After you build them into *.so files you can use them in your native code and access that through JNI. It's not as hard as it sounds but it takes a good bit of setup.
Related
I'm trying to use FFmpeg in a new app and found these two repositories on GitHub: http://hiteshsondhi88.github.io/ffmpeg-android/ and http://hiteshsondhi88.github.io/ffmpeg-android-java/.
What are their differences? I mean, Android NDK is just a way to put native code together with your Java code, right? If so, using FFmpeg-android as a shared native library and using FFmpeg-android-java which seems to be a java library that encapsulates calls to the shared native library, are the same thing. Or am I wrong?
Thank you
The second one includes a full android project and precompiled libraries. The first one is only a bunch of shell scripts that will download and compile different tools (including ffmpeg) using the NDK that you provide.
We have developed an iPad application where the core logic is written in CPP code, so that we can use the same code files/libraries to other platforms.
Now I want to use those files and develop similar Android application, but unable to create .so files and integrate paths in Android.mk files and all. I am basically an iOS developer, this is first time I am looking into Android NDK.
Can anyone help and guide if there is any straight forward steps to it.
I have already gone through android developers site and few other tutorial sites. But none of those worked for me.
Require easy-clear steps to call cpp method in java, if I do have few cpp files and .a libraries with me already.
You aren't very specific at the step you are stuck at.
Here's a very quick explanation on how to call native code from java (android) :
first create a method to be exported by the native and called by java (this uses JNI, so google JNI , JNIEXPORT)
once you have this method defined in your native code, it's time to create a shared library (.so) file , using the compiler that comes in the NDK (because you are compiling for android ). You will need to compile for the correct architecture of the device (armeabiv7s is the most common now days).
you need to add the library file in your app.apk inside the armeabi folder (more details in NDK tutorials).
inside your java code you will need to load the shared library via the System.loadLibrary(LIBRARY_NAME);
inside your java code you will need to have defined static native methods that are in pair with the methods you exported from your CPP code
Quick tips :
use C functions,not CPP , since CPP will be mangled in the resulting shared library. In other words, you will need to create a C wrapper that will call your cpp code.
look over a hello world tutorial for NDK , and work yourself from there . Here's a link to such tutorial http://trivedihardik.wordpress.com/2011/06/16/hello-world-example-using-ndk-in-android/
You will bump later on into compilation issues with the makefiles, but by then you will probably be able to be more specific with your question.
Easiest way is to use the hello-jni Android studio sample project.
There are a lot of settings and configurations, you get them from the sample that is a working unit, always easiest when starting from something working.
First run (and modify) the hello-jni and learn how the interactivity between the Java and C parts works. About everything works except environmental ANSI C/C++ stuff. You have to get things like language, country etc from Java and transfer it to the C-code. You are in US in English with "inches and gallons" in JNI.
Then to an own project you create with android studio, copy and modify from it bit by bit from hello-jni. When you have our own branded hello-JNI you can add bit by bit your own code. Often using C-dummies for testing the interactivity with the Java part is easier, then change it to the real C/C++ code of yours.
Read the Android/Android studio documentation and learn and understand. Use the Android emulators, much easier and they are good.
The project configuration stuff is by far the hardest to handle at the start. If I would make a new project today, I would start from the Hello-JNI once again.
I want to write an Android application that is able to display list of exported functions by a shared library (.so).
nm/objdump/readelf tool is only available for Windows/Linux. So I have thought about compiling platfor_external_elfutils to get a toolchain with nm or objdump tool.
However, this is not a good solution considering the big dependencies the toolchain may cause (can be up to xx MB).
I want to ask if there is any available simple code to achieve the purpose without having to compile and attache the whole toolchain in my app.
This is probably too late for the original poster, but libelf can be built as a static library (libelf.a) from Android sources, at least since JB4.2. Just use
make libelf
In the main directory to build it.
If someone knows how to build it as a dynamic library/shared object that would be much appreciated.
You can use libelf library (from elftoolchain - it's BSD licensed) to parse the binary. libelf comes with source for elfdump utility that dumps various information about ELF file including export list. Just strip out the source you don't need and you're ready. Executable for this won't take more than 100KB.
Can somebody help me write Android.mk for LibXtract or point me in correct directoin?
Here is source for lib - https://github.com/jamiebullock/LibXtract.git
Or mayby there is a way to use linux generated shared objects in Android?
Especially for bigger established projects, crafting Android.mk files is quite an effort. More so, if you are not familiar with Android NDK build architecture whose understanding requires digging deep into the documentation and Android NDK make files. I would suggest trying to use existing make files by setting CC to point to your NDK tool chain, and CFLAGS += -sysroot $(SYSROOT) where SYSROOT=${NDK_INSTALL_DIR}/platforms/android-<level>/arch-<arch>/ (depending on targeted Android API version and architecture). Even without knowing about your library, I would bet you should have good chance of success this way. Android NDK documentation (${NDK_INSTALL_DIR}/doc/STANDALONE-TOOLCHAIN.html) details the use of independent tool chain and also instructs how to create a standalone tool chain that will not require the use of -sysroot argument to xxx-gcc.
If you decide to use Android.mk instead, you might check existing projects -CSipSimple comes to my mind (PJSIP converted from standard form GNU make files).
Important is to create the shared objects using Android tool chains. It is possible to build them outside of your application source tree, and then just copy the shared objects into the package source libs/<architecture>/ directory.
Integration with your build system depends on details that are not known (including how smooth you desire this whole integration to be e.g. because of other people working with the same project). If you are creating an application from command line, the easiest would be to have GNU make file or shell script in the package root directory ensure libXtract.so and your application package is up-to-date by calling libXtract make file and ant to build and pack your Java application. If you are using ant there should be a way to specify using make to take care of libXtract.so. I am not sure if eclipse is completely relying on ant for building an application to know if this would be enough for enabling complete build by clicking mouse buttons from within eclipse, too.
The answer to this question says you could use cmake script to build Android.mk files - I have not tried this approach.
I am building a multi-platform SDK for real time 3D applications. This SDK is programmed in C++ and works under Windows, Apple's iOs, MacOS, Linux and Android.
The project structure is complex, it consists in 3 native C++ static libraries, linked with some external static libraries in a complete shared library. This is very simple under all the managed OSes, except for Android.
The major problem in Android is bi-directional communication/calls between native code and Java code. I got this solved some time ago using SWIG to wrap the shared library's classes. To achieve that I wrote our my own build scripts (Makefiles) to handle native compilation with the ndk r4, swig code generation, java pre-compilation and jar creation.
Lately we added some callback/listener classes in the C++ layer, that we wanted to be derivable/overloadable in Java, for this we used SWIG's directors feature. But it appears that it needs JNI features (weak global references) that were not in the NDK r4b. So we need to switch to a newer Android NDK (r6b) that has these features. But since our custom build scripts were written for NDK r4b they won't work anymore.
My concern is to have everything built properly through Android's NDK/SDK (eventually through Eclipse) with Android.mk files so we don't have to rewrite everything from scratch each time we switch to a new NDK.
I'd like to know if there is a way to manage such complex project structure with standard Android.mk, ndk-build, ant and eclipse (including the SWIG part). And if so, how ?
Don't hesitate to ask for precisions, I am not sure I am being really clear.
Any help greatly appreciated.
Florent Lagaye.
I've been looking for a similar thing and, although I haven't figured it out yet, there is a good example with building gstreamer on Android.
http://cgit.collabora.com/git/user/derek/androgenizer.git/
It supposedly works with any libtoolized application.
Here is the directions for how to build:
http://gstreamer.freedesktop.org/wiki/GstreamerAndroid_InstallInstructions
What we ended doing is writing specific rules in the Android.mk file to manage swig interface generation.
Remember to add the generated c++ source to the list of source files before including BUILD_STATIC_LIB or BUILD_DYNAMIC_LIB, and to instruct swig to generate the java source in folder accessible by your Android java project.