I am trying to pass a preprocessor define into my native code using the Android NDK that is dependent on build configuration. This is so that I can disable some debug native code easily by switching build configuration in eclipse.
As I understand it, preprocessor defines are added in the android.mk file using LOCAL_CFLAGS or to the Application.mk file using APP_CFLAGS, and I have both of these options working.
So, I am trying to use the ndk-build option NDK_APP_APPLICATION_MK to specify a different Application.mk in one build configuration as follows:
ndk-build NDK_APP_APPLICATION_MK=jni/ApplicationDistribution.mk
This is documented to behave as follows:
ndk-build NDK_APP_APPLICATION_MK=<file>
--> rebuild, using a specific Application.mk pointed to by
the NDK_APP_APPLICATION_MK command-line variable.
This generates the following log:
Android NDK: Parsing xxx/jni/Application.mk
which suggests that it is still looking for the original Application.mk file.
Is this a known bug? Is there an easier way to pass preprocessor defines to native code only for certain eclipse build configurations?
thank you for your time.
Documentation is wrong here - misspelled option.
Use NDK_APPLICATION_MK instead of NDK_APP_APPLICATION_MK.
Related
I build a C++ project depending on the Boost library using CMake (3.4.1). Host platform is Linux, targets are that host and cross-build Android NDK.
I'm only using Boost header files and I just downloaded/extracted the boost folder (and I don't have a /usr/include/boost directory).
In my CMakeLists.txt file I declare the dependency to Boost like this:
find_package(Boost 1.57 REQUIRED)
And I configure my build like this:
BOOST_ROOT=/path/to/boost cmake ../src
Which actually works as expected for my native build.
When I now configure a build exactly the same way (only specifying some more environment variables and a CMAKE_TOOLCHAIN_FILE) CMake gives me:
BOOST_ROOT=/path/to/boost JAVA_HOME=/bla/bla/bla \
ANDROID_NDK=/bla/bla/bla \
ANDROID_SDK=/bla/bla/bla \
ANT=/usr/bin/ant \
cmake ../src -DCMAKE_TOOLCHAIN_FILE=/bla/bla/android.toolchain.cmake
CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:1247 (message):
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:4 (find_package)
So I believe I did almost the same to build for the Android target but the very same method that finds Boost for the host-build doesn't work here.
I tried to set Boost_DIR, BOOSTROOT and BOOST_INCLUDEDIR all with the same effect. Also I've deleted all content in the build directory before trying anything new.
What can be possible reasons for this behavior? I've already tried to print BOOST_ROOT directly in the FindBoost.cmake script like this:
message("BOOST_ROOT: $ENV{BOOST_ROOT}")
With the expected behavior (writing BOOST_ROOT: /path/to/boost).
Of course I can cheat now and just link the boost folder into the include folder of the cross compiler but that's not nice of course and I want to find out what's going on.
When cross-compiling, the toolchain file normally sets the variable CMAKE_FIND_ROOT_PATH. Combined with the CMAKE_FIND_ROOT_PATH_MODE_LIBRARY variable set to ONLY, CMAKE_FIND_ROOT_PATH variable is used as effective chroot for find_library calls, so only libraries under the given prefix(es) are searched.
Analogue variables exist to adjust the behavior for find_path (used for searching include paths) and find_program.
THe toolchain file you use actually sets CMAKE_FIND_ROOT_PATH at line 1521:
set( CMAKE_FIND_ROOT_PATH "${ANDROID_TOOLCHAIN_ROOT}/bin"
"${ANDROID_TOOLCHAIN_ROOT}/${ANDROID_TOOLCHAIN_MACHINE_NAME}"
"${ANDROID_SYSROOT}"
"${CMAKE_INSTALL_PREFIX}"
"${CMAKE_INSTALL_PREFIX}/share" )
and below sets CMAKE_FIND_ROOT_PATH_MODE_* variables to ONLY. So you need to have Boost installed under one of these directories, and give hints (like BOOST_ROOT) relative to it.
Note, that Boost should be built for the target platform (Android NDK in you case), not for the platform where you cross-compile (Linux).
I am trying to build Qt application for android using Qt Creator. I use CrystaX NDK for android instead of goolge's one because I need to use boost libraries in my project, and, as CrystaX's official site says, it is comes with it.
I am using following versions of tools:
Qt Creator 3.4.2
Qt 5.5.0
CrystaX NDK 10.2.1
At first, I had to manually add libraries and headers paths in my .pro file, because it hasn't been found automatically. There was compiler error: can't locate libcrystax, there was some errors in source files about including boost headers. I've added following lines in my project file:
android {
INCLUDEPATH += $$NDK_ROOT/sources/crystax/include \
$$NDK_ROOT/sources/boost/1.58.0/include \
$$PWD/ssl
LIBS += -L"$$PWD/ssl" -lssl -lcrypto
LIBS += -L"$$NDK_ROOT/sources/crystax/libs/$$ANDROID_TARGET_ARCH"
ANDROID_EXTRA_LIBS = $$NDK_ROOT/sources/crystax/libs/$$ANDROID_TARGET_ARCH/libcrystax.so
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android
}
After rebuilding again, I've got an error (runtime error) that says libgnustl_shared requires libcrystax, but libcrystax is not loaded or something similar.
After searching the internet, I've found that it's happening because one library that requires another, is loading before it, and that second library, is not being searched for, at application directory, only in system paths.
I've found a workaround - to load required library manually. I copied default QtActivity.java into my project directory (android/src/.../QtActivity.java) to replace default one and added following code:
static {
System.loadLibrary( "crystax" );
}
After that I am not getting that error, but now I'm stuck with another one:
java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1285]: 37 cannot locate '__aeabi_ldiv0'...
Is it possible to use Qt + CrystaX NDK for build android app? Am I doing it wrong way? Please, explain how to do it properly, if I've mistaken or if I misunderstood whole concept. Any help is appreciated.
This happens because you haven't linked with libgcc.a. I don't know how exactly your build system works (well, Qt's one), but generally, adding libgcc.a to the list of additional libraries should help:
ANDROID_EXTRA_LIBS = $$NDK_ROOT/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/lib/gcc/arm-linux-androideabi/4.9/libgcc.a
This line specify arm variant of libgcc.a; obviously, you should use proper one depending on ANDROID_TARGET_ARCH value.
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.
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");
I'm working on a large game engine that must be ported to Android. All the code is C/C++, so we are porting via the NDK. I've got everything building, but after lots of scouring, I'm still uncertain what the best method is for building Debug vs. Release versions of our .so file. Changing things by hand every time is getting old.
Do you have different Application.mk files for each target? Or is there some way to include multiple targets in a single Android.mk file under the jni/ directory? Or perhaps a third option might be to write a standard makefile that sets environment variables that the Android.mk file uses to inform the build process?
Finally, one last question regarding the android:debuggable flag that must be set in the AndroidManifest.xml file. What this actually have any effect on the generated native code that's copied to the device?
Best and thanks,
Kevin
Do you have different Application.mk files for each target?
No. Separate subdirectories, all with their own Android.mk (shared and static libs) but only one Application.mk for me.
My Application.mk is just:
APP_STL := gnustl_static
APP_OPTIM := debug
I'm still uncertain what the best method is for building Debug vs. Release versions of our .so file. Changing things by hand every time is getting old.
It's a bit spread out, for me at least, using the jni/Android.mk + Application.mk layout.
Application.mk has APP_OPTIM := debug
Then in the application element of AndroidManifest.xml I have android:debuggable="true"
When you build with ndk-build, it uses this manifest flag to determine optimization (which is useful to turn off or on, off for profiling, etc.)
(A Little Off topic) I recently ran across
https://code.google.com/p/android-ndk-profiler/
Which, when combined with http://code.google.com/p/jrfonseca/wiki/Gprof2Dot
Generates some pretty images to help my little mind grasp how things are running over on the phone itself.
You're not required to use the Android.mk system to build your .so's. Personally, I use my own Makefile's with the targets I need and this allows for very standardized debug vs. release build specification.
I use a single file to build a library for diferent targets. In the Application.mk add this "APP_ABI := armeabi armeabi-v7a" it works for me.