Develop Reference

Android Studio, LOCAL_C_INCLUDES += /foo/bar/include not working?

I have an Android Studio project that uses NDK
and I can't get include paths to work.
let say I have app/src/main/jni/foo/bar/file.c
and it includes "my/lib/inc.h"
When I add
LOCAL_C_INCLUDES += /home/user/include/ (to app/src/main/jni/Android.mk)
where the folder "my" is located I still get file not found from ndk-build
If I add "my" to app/src/main/jni it works fine.
What am I missing?

Android studio is probably ignoring your Android.mk and generating its own.
At the present instant in time, the NDK isn't well supported by Android Studio, and although you will find various version-specific gradle rule modifications which have apparently worked for their authors, it may be easier build the NDK code yourself and merely let the packaging stage pickup the results.

Building PCL for Android

Does anyone have instructions for building the Point Cloud Library (PCL) for Android? I found a few superbuilds of PCL that claim to be able to build PCL and its dependencies. I tried the superbuild from http://www.hirotakaster.com/weblog/how-to-build-pcl-for-android-memo/. I'm using Ubuntu 14.10, Android 19, NDK r10d, and PCL 1.6.0, but I'm willing to use any versions. I'm also using the terminal for compiling. For Android hardware, I'm using a Project Tango.
I tried using android-cmake (http://code.google.com/p/android-cmake/), but I'm not sure how to build the proper toolchain. I continually receive the error "Could not find any working toolchain in the NDK. Probably your Android NDK is broken." I get this error with plain cmake and ccmake, too.
Does anyone have any detailed instructions for building PCL for Android (e.g., a bash script or terminal instructions)? Or, does anyone have a link to pre-built libraries?

(Caveat Emptor: This is not a long term solution)
I was able to get past the CMAKE error by editing the cmake file
pcl-superbuild/toolchains/toolchain-android.cmake
These two changes should get past the errors mentioned above:
set( ANDROID_NDK_HOST_SYSTEM_NAME "linux-x86" ) # Line 468
Should be
set( ANDROID_NDK_HOST_SYSTEM_NAME "linux-x86_64" )
This will generate another error, unless you change the following line (Line 1023)
if( ANDROID_NDK_RELEASE STRGREATER "r8" ) # r8b
Should be
if( ANDROID_NDK_RELEASE STRGREATER "r10" ) # r8b
The first change adds _64 to x86_64. The second adds compatibility for r10d.
This doesn't fix all of the errors though, because BOOST threads don't place nicely with GCC 4.6+. Implement the patch shown at this link (https://svn.boost.org/trac/boost/ticket/6165).
Again, that still doesn't fix all of the errors. (I haven't figured out why this is needed yet, math.h shouldn't need std::). In the file,
pcl-superbuild/CMakeExternals/Source/pcl/common/include/pcl/pcl_macros.h
Edit lines 99-102:
# define pcl_isnan(x) isnan(x)
# define pcl_isfinite(x) isfinite(x)
# define pcl_isinf(x) isinf(x)
They should be:
# define pcl_isnan(x) std::isnan(x)
# define pcl_isfinite(x) std::isfinite(x)
# define pcl_isinf(x) std::isinf(x)
PCL still generates many warnings, but at least it compiles (so far)
**EDIT: **
This doesn't get you all the way (unfortunately) because the boost libraries don't play well with C++11.
To fix this, download boost 1.55 from http://sourceforge.net/projects/boost/files/boost/1.55.0/, and overwrite the boost directory
pcl-superbuild/CMakeExternals/Source/boost/boost_1_45_0
(This directory gets created when you run make for the first time).
Next, modify
pcl-superbuild/CMakeExternals/Source/boost/CMakeLists.txt
and find the line:
file(GLOB lib_srcs ${boost_root}/libs/filesystem/v2/src/*.cpp)
replace it with
file(GLOB lib_srcs ${boost_root}/libs/filesystem/src/*.cpp)
That's as far as I've gotten

this link helps a lot, you can take a look. I also left some comments there..
http://www.hirotakaster.com/weblog/how-to-build-pcl-for-android-memo/
for compile pcl 1.6 with ndk r10d, you need to replace toolchain-android.cmake with the toolchain from opencv library

I built PCL and its dependencies using Ubuntu 14.10, 32-bit. I also had to use NDK r8c, 32-bit. The key to building Hirotakaster's superbuild was using a 32-bit os.

I managed to compile your super build with Ubuntu 15.10 64-bit and NDK r10e. I changed the toolchain-android.cmake with the one from OpenCV. Then in common.hpp(found in /Source/pcl/common/include/pcl/common/impl) I had to add the following lines:
# include < math.h >
# define pcl_isnan(x) std::isnan(x)
# define pcl_isfinite(x) std::isfinite(x)
# define pcl_isinf(x) std::isinf(x)

Building android app on Qt using additional library (Assimp)

Hi I am trying to port an OpenGL desktop app to android. I have no knowledge of android development so am depending on Qt Creator to package the app. As part of the setup, I have invoked 'make-standalone-toolchain' script in android ndk with following settings
--platform=android-21
--toolchain=arm-linux-androideabi-4.9
--system=linux-x86_64
Then I used android-cmake and passed it the path of my newly created standalone-toolchain, which created libassimp.so, libassimp.so.3, and libassimp.so.3.1.1(ln) inside my assimp directory tree.
I passed the libassimp.so path to Qt creator project build menu under 'additional libraries'. However, on deploying the app on android, it crashes with error:
dlopen("/data/app/org.qtproject.example.a3dqtquick-2/lib/arm/lib3dqtquick.so", RTLD_LAZY) failed: dlopen failed: could not load library "libassimp.so.3" needed by "lib3dqtquick.so"; caused by library "libassimp.so.3" not found
I can even see the libassimp.so (not libassimp.so.3) file inside the project build directory at
../android-build/libs/armeabi-v7a.
Not sure where to go from here, manually placing libassimp.so.3 at this location does not sort out the problem. Thanks for reading. I will add further info on your feedback . please forgive any info deficiency as this is my first experiment with android.
Following is the deployment-settings.json file
"description": "This file is generated by qmake to be read by androiddeployqt and should not be modified by hand.",
"qt": "/home/ubashir/programs/Qt/5.4/android_armv7",
"sdk": "/home/ubashir/programs/android-sdk-linux",
"sdkBuildToolsRevision": "21.1.2",
"ndk": "/home/ubashir/programs/android-ndk-r10d",
"toolchain-prefix": "arm-linux-androideabi",
"tool-prefix": "arm-linux-androideabi",
"toolchain-version": "4.9",
"ndk-host": "linux-x86_64",
"target-architecture": "armeabi-v7a",
"qml-root-path": "/home/ubashir/code/3dqtquick",
"application-binary": "/home/ubashir/code/3dqtquickAndroid/lib3dqtquick.so"
UPDATE:
I have now tried this.. replace all links to assimp.so.3.1.1 with copies of the latter so now my library libassimp.so.3 is a file instead of link to libassimp.so.3.1.1. I manually added libassimp.so.3 to my project subfolder android/libs/aremabi-v71 --- no good. I confirm that my build directory shows all libassimp files as I manually added them so presumably they are being deployed but the error remains :
failed: dlopen failed: could not load library "libassimp.so.3" needed by "lib3dqtquick.so".
As outlined here http://webmail.dev411.com/p/gg/android-ndk/1386vger6e/use-assimp-c-library-in-ndk-ld-error-obj-local-armeabi-v7a-libassimp-so-incompatible-target-for-use-with-vuforia
I even edited the link.txt file after running cmake on my assimp build directory for android, altering the entry -soname,libassimp.so.3 with -soname,libassimp.so but it still creates libassimp.so.3.1.1 with its two links , i.e., libassimp.so.3 and libassimp.so. So still stuck..

I ran into the same problem with a shared library I built with CMake for and Android project. I found a way to fix it. There might be a cleaner solution if you were more familiar with CMake.
Search through the CMakeLists.txt file(s) for "SOVERSION" and "SET_TARGET_PROPERTIES()"
In the SET_TARGET_PROPERTIES() routine comment out the lines for VERSION and SOVERSION as follows
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES # create *nix style library versions + symbolic links
DEFINE_SYMBOL DSO_EXPORTS
# VERSION ${PROJECT_VERSION}
# SOVERSION ${PROJECT_SOVERSION}
CLEAN_DIRECT_OUTPUT 1 # allow creating static and shared libs without conflicts
OUTPUT_NAME "${PROJECT_NAME}${PROJECT_DLLVERSION}" # avoid conflicts between library and binary target names
)
Then rerun the configure and generate steps in CMake and rebuild the target. This should give you a .so without any version numbers.

I'll suggest you to take a look at the solution I've found to my problem (that is very similar to yours):
libgdal.so android error: could not load library "libgdal.so.1"
Hope this helps.

STLport and Android NDK - STLport loaded as static, Linux/gcc ld reports "multiple definitions"

I've looked thru a lot of material on Android NDK and STLport. I have complex app, java+native code, which loads STLport (a c++ standard library port). The original codebase had "APP_STL := stlport_static" in the Application.mk in the project's "jni" subdir. Causes ld to load the lib static. This caused many compile failures, in current SDK/NDK.
Tried to load as a dynamic lib, as per a suggestion. (In "../jni/Application.mk", set "APP_STL := stlport_shared") With this, I get a clean compile, and load, and the app runs flawlessly on the Android armeabi-v7a emulator, if I disable checkJNI on the "dalvik" virtual machine.
But once I enable checkJNI, I get an "unsatisfiedLinkError" on the libapplication.so, which looks like it might result from STLport being dynamically loaded. So, I want to load STLport in static mode (logcat reports this after several other libs successfully loaded). During the build, compile is ok, but I am getting two multiple definition errors, specifically: "multiple definition of 'vtable for std::bad_exception' " and of 'std::exception::~exception()'. (I have also tried using "gnustl_static").
I am using gcc version 4.3.0 and make version 3.81, command line mode, and small wrapper around build-ndk, for android ndk-r9c, with a build target version of android-8, "ant" to build the .apk file, and so on.
Someone who has more familiarity with Android than me (I am a complete noob) might have seen this before. If so, please advise. Thanx. - Rus

It's definitely possible to use stlport_static with NDK r9c. What object files are mentioned with multiple definition errors? Maybe, you are using some prebuilt libraries? Maybe, the gcc version 4.3 is problematic? Why don't you use the default (gcc 4.8)?
With that, the NDK document explicitly encourages use of shared STL, but you must not forget to call System.loadLibrary() in correct order:
System.loadLibrary("stlport_shared");
System.loadLibrary("Rusfuture");

Android load native library

I'm trying to load a library I built with the standalone NDK toolchain.
I built libGLmove.so and placed it in libs/armeabi of my Eclipse project
However, the call to System.loadLibrary("GLmove") throws an UnsatisfiedLinkError
Any ideas as to how to resolve the problem or make Android find my library?
How does ndk-build package the library after it builds it?
Edit: The exact compile flags are:
/Users/thomas/Documents/android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/darwin-x86/bin/arm-eabi-g++ --sysroot=/Users/thomas/Documents/android-ndk-r5b/platforms/android-8/arch-arm -march=armv7-a -mfloat-abi=softfp -mfpu=neon -Wl,--fix-cortex-a8 -fno-exceptions -fno-rtti -nostdlib -fpic -shared -o GLmove.so -O3

Have you checked in the resulting .APK file (use a zip utility to look at/unarchive it) to see if your library makes it through packaging? I'm a little suspicious that it might not, because I notice that everything that gets built into the "libs" folder in the project and on my build machine goes into a folder called "lib" (no 's') in the APK.
I wouldn't be too surprised if it turned out that the Eclipse build process doesn't package up any libraries it doesn't know about. This is, of course, unlike what happens with resources, which just get packaged by virtue of being in the right place.
If you find your library is not in your APK file, I don't think you can just manually put it in there, since it won't show up in the package manifest and will break any signing as well.
You don't mention whether or not your Eclipse project is an NDK project (right click on the project, Android Tools->Add Native Support.) If not, I suspect you'll need to make it into one and then add your library to the Android.mk file as a dependency and not a target.
Or: you could try putting your library into /res in the project and use System.load() instead of System.loadLibrary() to load it. I'll admit that I've never tried that myself, tho.

I was running into this same problem. The things I had wrong.
In the make file I had the "LOCAL_SRC_FILES" spelled wrong.
In the c source file I had the library name inside the method name
Java_com_my_namespace_libname_activity_methodName(JNIEnv* env, jobject _this) {
//Fancy Native Junk Here
}
Once I fixed those two things, re-ran ndk-build and refreshed the eclipse project with F5 it started to work.

You don't give very many details, but it may be that the .so you've built relies on a library that isn't available on the version of phone you're using.
I've not found any way to tell the NDK which Android SDK version you're targeting so don't have any very clear idea of how this side of it should work, but it looks like it would be easy to bring in a dependency from a newer SDK version into your .so so it won't load on all phones.

Could you please check the syntax and the location of System.loadLibrary("GLmove")
the System.loadLibrary call should be in static block of the Java source file
static {
System.loadLibrary("nativelib");
}
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html

If your native library needs other libraries you'll need to load them first. If that doesn't help, check to see that your project directory does not contain spaces.
Also, you may find this tutorial helpful: http://mindtherobot.com/blog/452/android-beginners-ndk-setup-step-by-step/