Develop Reference

Using CrystaX with Qt to build android application: java.lang.UnsatisfiedLinkError

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.

Eclipse not updating "built-in" include paths for Android NDK Project after switching to GCC 4.8

I have an Android/Eclipse project that uses the NDK and I've recently enabled c++11 support by adding the following to my Application.mk file:
NDK_TOOLCHAIN_VERSION := 4.8 #same result here with clang
APP_CPPFLAGS += -std=c++11
This basically works fine, c++11 features are available and compile as expected. This goes for ndk-build and Eclipse builds (which just invoke nkd-build), but the eclipse code parser becomes confused now. When I open a file that uses types added to the STL in c++11 (like for example std::unique_ptr), I get red squiggles and an error entry in the Problems tab saying Symbol 'unique_ptr' could not be resolved. This wouldn't be so bad, but if errors are present in that list Eclipse refuses to launch (or debug) the application. Right-clicking on the #include <memory> line and selecting Open Declaration also opens the wrong (4.6) file.
When checking the project properties under C/C++ General --> Paths and Symbols --> Includes it still lists the old (4.6) includes when Show Built-in values is ticked: Screenshot
Are those just cached from somewhere and I can get it to re-generate those entries? I've obviously tried to Clean and Rebuild the project, with no effect. I'd rather not add them manually if that can be avoided, upgrading the NDK to new versions already requires quite a few changes until it compiles again. Where are these entries generated from and how do I trigger an update?

I wish I could say I have a definitive answer for you, as I've been battling this problem for quite a while myself, but I do have a decent workaround. For starters, the "built-in" entries under "CDT Managed Build Setting Entries", are generated based on the contents of your Application.mk file which is located in the jni directory. There is no other way of changing them, and these are what populate the "Includes" section in the C++ perspective's Project Explorer. But I see that must have read the documentation.html in the NDK installation to see what to put in that file already. The issue then becomes that as soon as you change something or breathe too hard, your includes suddenly and irreversably become unresolved. The workaround for this is to recall the exact path of each include entry, right-click on the project, go to New->Folder, then in the dialog click Advanced, and select Link to Alternate Location (Linked Folder). Then navigate to the path (or extend a variable if you are fancy) of the include folder, rename it something descriptive (you can't have 4 linked folders named "include"), and voilà! You suddenly have a usable workspace again. I guess the "Includes" section functionality is a bit flimsy still, at least for ADT, and doing this puts the includes on the same footing as other files that are actually in your project. I'd be thrilled if the officially sanctioned mechanism started to work reliably, and I eagerly await news of such. HTH!

Much smaller .so file for identical source code

My Android application (game) uses native C++ code for certain operations. That is, I use the Android NDK. The native C++ code is compiled for armeabi only (to the default, armeabi-v5).
The last time I built my c++ code into nativestuff.so was a few months ago, in another computer (Windows 7 + cygwin, because cygwin is recommended for compiling with Android NDK).
I just installed the NDK on my current PC (Windows 7), along with the newest cygwin, and rebuilt the c++ code for my app.
To my surprise, it generates an .so file of 14KB, while the previous .so file was 37KB. Note that the c++ source files are exactly the same (they haven't changed for a year), my project is under version control, so I'm 100% sure.
I tested the c++ functionality in the game, and it works exactly as before, without any bugs.
My C++ files use only cstring.h and jni.h as includes. My Android.mk is as follows:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := nativestuff
LOCAL_SRC_FILES := nativestuff.cpp
include $(BUILD_SHARED_LIBRARY)
Any idea why the drastic change in .so filesize?
(I added the linux tag as well to this question, because maybe it's a general thing so I want to make sure that linux gurus also check it.)

Run objdump -x file.so on both versions. This will list all the sections and their sizes. That should give you a clue as to where the problem lies. (i.e. is there a new .debug section that's 23KB long? Maybe debug mode got enabled.)
If your code sections are radically different, compare the output of objdump -d file.so. Maybe your compiler automatically inlined more code, which saved a lot of space.
If another section is new/different, post the output in another SO question.

Maybe the previous .so was generated with debugging information.
(compiled with gcc -g option)

You may try one thing: use the command size executable-name. That will give you size of the different areas of your executable code. If the previous build is available do the same to that. You may get an idea where the change is.

ndk-build option NDK_APP_APPLICATION_MK not working?

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.

Debug vs. Release builds in the Android NDK

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.