I have a really simple helloworld.cpp program
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
And I'm trying to compile it for android x86 with the cross-compiler from the toolchain:
/Users/me/android-ndk-r8/toolchains/x86-4.4.3/prebuilt/darwin-x86/bin/i686-android-linux-g++ helloworld.cpp -L "/Users/me/android-ndk-r8/sources/cxx-stl/stlport/libs/x86/" -lstlport_static
However, I get errors:
helloworld.cpp:2:20: error: iostream: No such file or directory
Any idea why?
Check the documentation.html file included with the NDK, under "Standalone Toolchain". It says that if you invoke the compiler in this way you won't be able to "use any C++ STL". However it is possible, as the documentation explains, if you first create a "customized" toolchain installation, using something like the following command:
$NDK/build/tools/make-standalone-toolchain.sh --platform=android-8 --install-dir=/tmp/my-android-toolchain --arch=x86
where $NDK is the path to your NDK directory. Note the --arch=x86 which means that the toolchain is prepared specifically for the x86 Android. This prepares what you need in one directory, including the STL headers and folders. You should then be able to use -lstdc++ to link against the STL (static version), i.e. something like:
/tmp/my-android-toolchain/bin/i686-android-linux-g++ helloworld.cpp -lstdc++
For a more complete explanation, please see the NDK documentation.
The NDK documentation is not entirely accurate, at least not currently. In fact, it states when using the prebuilt toolchain "You won't be able to use any C++ STL (either STLport or the GNU libstdc++) with it.", but this is out of date. I created a small hello world program using the include with the same error. It can be solved without creating your own toolchain though, which is nice if you don't want to have to add one more step to your configuration process and allows you to always use the latest SDK platform without creating a new toolchain every time.
The NDK ships with the source code for several versions of standard C++ libraries: GAbi++, STLport, and GNU STL. Each flavor comes with prebuilt shared and static libs as well. My example below will use stlport.
To use the stand-alone toolchain at its installed location, you can do something like this:
export CXX='$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-g++ --sysroot="$NDK_ROOT/platforms/android-19/arch-arm"'
This, for example, would set your CXX compiler to compile ARM on the OS X system using SDK platform level 19. This much you probably already knew. Also, you would want to export your CC, CPP, LD, AR, and RANLIB if you use it. I also personally create an envar for READELF.
To add support for C++ libs, you could do something like follows:
$CXX helloworld.cpp -I$NDK_ROOT/sources/cxx-stl/stlport/stlport -L$NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi -lstlport_shared
Note that this will link the libstlport_shared.so which will now be required at runtime, so you may need to add a relative path to the command above to support that, depending on your APK structure. If you want to just test this simple case, you can just run this on the emulator as follows:
adb push a.out /data
adb push $NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi/libstlport_shared.so /data
adb shell
# su
# cd /data
# chmod 777 a.out
# ./a.out
To get rid of the headache of dealing with shared library paths, you can also statically link the C++ library in by changing "-lstlport_shared" to "-lstlport_static". There are some consequences of doing this, as explained in the NDK Dev Guide. The biggest issue is due to having the static library linked in multiple places, causing:
- memory allocated in one library, and freed in the other would leak or even corrupt the heap.
- exceptions raised in libfoo.so cannot be caught in libbar.so (and may simply crash the program).
- the buffering of std::cout not working properly
A useful tool is also included to see what dependencies your program has, the readelf tool.
To see what other shared libraries your program requires, you can run the following:
$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-readelf -a a.out | grep NEEDED
Other cool standard tools:
addr2line - convert a stack trace address to a line of code
nm - Displays the symbol table
objdump - displays info on an object
i call one of the functions from gnustl after it runs fine from prebuilt aosp arm-linux-androideabi-gcc --std=c++11 and after crashing error i cant get a backtrace from logs or reason, my hope is turning to crossbuilt qemu-linux-user to run host compiled i686 binary on the arm, difficulty is interacting with crosshost libs aapt from adt always crashes on any other than platform specific libs, unless kernel module packaged update is possible...
Related
I am new to this build system, but I've spent dozens of hours trying to get qmake + clang to produce a working android binary. I would appreciate any help or advice. Here is as simple an example as I can come up with:
First, here is a working build command. It gives me a shared object that I can call from android (with Unity, using C# native interops):
C:\Users\deltav\AppData\Local\Android\Sdk2\ndk\21.3.6528147\toolchains\llvm\prebuilt\windows-x86_64\bin\clang.exe ^
-target aarch64-none-linux-android21 -shared -v ^
-DANDROID_ABI=arm64-v8a -DANDROID_ARM_MODE=arm -DANDROID ^
M:\simpleExample\simpleExample.c ^
-o M:\simpleExample\libsimpleExample.so
Here is the verbose output of running that command: https://pastebin.com/18HcnDYh
On the other hand, here is the simpleExample.pro file that is NOT giving me a good binary: https://pastebin.com/wxrx6Myc
Here is the qmake output for building in release mode: https://pastebin.com/KWavwrb7
As you will know, qmake uses a kit to execute the project. My kit: https://imgur.com/a/Ehtmgin
The specific issue that has pushed me down this debugging path is from C# trying to load my shared object like this:
[DllImport("simpleExample")]
public static extern float getSpeedY();
The error that I get is this:
"DllNotFoundException: Unable to load DLL 'simpleExample': The
specified module could not be found."
Again, this error is not an issue if I just build from the CLI without qmake. I do not beleive this is a unity or C# error, as I worked the problem from that side first.
What I have tried so far:
I have used multiple ELF & DWARF tools to compare the ABIs of the generated binaries, which all told me the binaries were identical.
I tweaked and shaved down the clang calls that qmake generated until I got a vaild build command. Unfortunately I can't just replace qmake with the complile command because there are other projects that I need to apply this fix to.
QMake version 3.1
Ironically, CMake basically works out of the box.
Answer: Looking at the clang linking call, you can see QMake 3.1 was adding "libc++shared" as a dependency. I'm not sure why, as this was a C project.
The equivalent CMake project did not do this.
Packaging libc++shared with my binary fixed the issue.
We are attempting to add first class build support for Android to a C++ library. We want to supply a stock Android.mk, and disgorge it from dependencies like a jni subfolder in an Eclipse or Android Studio project directory. That is, we want to:
cd library-src
ndk-build <options>
In the above, library-src is not NDK_PROJECT_PATH. Rather, its the root folder for the library.
We visited the NDK's help (ndk-build -?), but it did not tell us how to remove the assumptions. We tried the following, but it produced an errors:
$ ndk-build -f Android.mk
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
/opt/android-ndk-r10e/build/core/build-local.mk:143: *** Android NDK: Aborting
Stop.
Attempting to set NDK_PROJECT_PATH results in a similar error:
$ NDK_PROJECT_PATH=. ndk-build -f Android.mk
Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk
/opt/android-ndk-r10e/.../add-application.mk:199: *** Android NDK: Aborting...
Stop.
And attempting to set APP_BUILD_SCRIPT results in a similar error:
$ NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=Android.mk ndk-build -f Android.mk
Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk
/opt/android-ndk-r10e/.../add-application.mk:199: *** Android NDK: Aborting...
Stop.
How do we use ndk-build without the jni directory?
Its important that we remove the limitations/assumptions. If we can't remove them, then we can't automate building and testing. If we can't automate building and testing, then we can't add the support because our governance has some QA and testing gates that we won't be able to pass through. (I'm willing to tolerate a manual adb push to test on-device).
I must admit that I don't understand your limitations. Why adding file library-src/Android.mk is OK, but library-src/jni/Android.mk breaks your QA and testing gates. Furthermore, Android.mk is usually not enough to launch a build. Whether you want to choose the STL variation, or ABI, or toolchain, it is natural to define these settings in a different file, Application.mk, which also goes to the jni directory by convention. Add library-src/jni directory, and Android developers will thank you when their tools of trade get upgrades and they can stay with the standard configuration.
But Android build is a very flexible system, and you can achieve literally what you ask for.
The experiments that you made did not work because ndk-build is simply a thin wrapper around GNU make, and treats environment variables with low priority.
ndk-build APP_BUILD_SCRIPT=Android.mk NDK_PROJECT_PATH=.
will most likely simply work for you. If you need more control, you can use something like
ndk-build APP_BUILD_SCRIPT=Android.mk NDK_PROJECT_PATH=. APP_STL=gnustl_static APP_ABI=armeabi-v7a APP_PLATFORM=android-19 NDK_TOOLCHAIN_VERSION=4.9
You can control the output directories, too. See NDK_APP_OUT, NDK_APP_LIBS_OUT.
One last hint: if your global build process is based on make, you can invoke $(MAKE) directly instead of going through ndk-build. It is also OK if you require standalone toolchain to keep platform-independent make logic.
I use Qt Creator to compile an Android application. I needed to integrate OpenCV into it, and it took me half a day to configure it properly, so I want to document the steps I took here, in case somebody else ever has to do it.
Edit: For OpenCV 4.x see the answers below. My answer was tested on OpenCV 2.4 only.
Original answer:
First, I downloaded OpenCV-2.4.10-android-sdk, and put into my project directory. It contains static libraries, and link order matters for static libraries for GCC. So you need to order them just so. This is how my .pro file looked in the end ($$_PRO_FILE_PWD_ refers to the project directory):
INCLUDEPATH += "$$_PRO_FILE_PWD_/OpenCV-2.4.10-android-sdk/sdk/native/jni/include"
android {
LIBS += \
-L"$$_PRO_FILE_PWD_/OpenCV-2.4.10-android-sdk/sdk/native/3rdparty/libs/armeabi-v7a"\
-L"$$_PRO_FILE_PWD_/OpenCV-2.4.10-android-sdk/sdk/native/libs/armeabi-v7a"\
-llibtiff\
-llibjpeg\
-llibjasper\
-llibpng\
-lIlmImf\
-ltbb\
-lopencv_core\
-lopencv_androidcamera\
-lopencv_flann\
-lopencv_imgproc\
-lopencv_highgui\
-lopencv_features2d\
-lopencv_calib3d\
-lopencv_ml\
-lopencv_objdetect\
-lopencv_video\
-lopencv_contrib\
-lopencv_photo\
-lopencv_java\
-lopencv_legacy\
-lopencv_ocl\
-lopencv_stitching\
-lopencv_superres\
-lopencv_ts\
-lopencv_videostab
ANDROID_PACKAGE_SOURCE_DIR=$$_PRO_FILE_PWD_/android
}
After that the project will compile but it will fail to run with the error
E/AndroidRuntime(11873): java.lang.UnsatisfiedLinkError: Cannot load library: link_image[1891]: 176 could not load needed library 'libopencv_java.so' for 'libMyProject.so' (load_library[1093]: Library 'libopencv_java.so' not found)
To overcome this, you need to add libopencv_java.so to your APK, and then manually load it from QtActivity.java. That's what the ANDROID_PACKAGE_SOURCE_DIR=$$_PRO_FILE_PWD_/android line at the end was for. Now you need to place libopencv_java.so here:
project_root/android/libs/armeabi-v7a/libopencv_java.so
project_root/android/src/org/qtproject/qt5/android/bindings/QtActivity.java
You can get QtActivity.java from the Android target build directory, in my case the full path was c:\Workspace\build-MyProject-Android_for_armeabi_v7a_GCC_4_9_Qt_5_4_0-Debug\android-build\src\org\qtproject\qt5\android\bindings\QtActivity.java, and just copy it.
Then you find those lines in it:
// now load the application library so it's accessible from this class loader
if (libName != null)
System.loadLibrary(libName);
And load libopencv_java.so before them, so they become:
// This is needed for OpenCV!!!
System.loadLibrary("opencv_java");
// now load the application library so it's accessible from this class loader
if (libName != null)
System.loadLibrary(libName);
Note that you pass opencv_java to System.loadLibrary(), even though the file is libopencv_java.so.
Edit: I forgot to mention, but I already had installed OpenCV Manager on my phone when trying to run one of the samples that come with OpenCV-2.4.10-android-sdk, so I don't know if it's needed or not. In any event, keep it in mind, if it fail even after my steps, you might need to download OpenCV Manager (it's available on the Google Store).
Edit 2: I'm using adt-bundle-windows-x86-20140702, android-ndk-r10d, OpenCV-2.4.10-android-sdk, Qt Creator 3.3.0, and my build target is "Android for armeabi-v7a (GCC 4.9, Qt 5.4.0)".
Edit 3: From Daniel Saner's comment:
In OpenCV 3.x, opencv_java has been renamed to opencv_java3. Also, while I didn't look into the specific changes that might have effected this, the workaround regarding that library in the final step seems to no longer be necessary. The app compiles and runs without the ANDROID_PACKAGE_SOURCE_DIR line
Edit 4: #myk's comment:
Worked for me with OpenCV 3.2. To workaround the build issues with carotene finish the LIBS+ section with: -lopencv_videostab\ -ltegra_hal\ – myk 2 hours ago
For OpenCV 4, sashoalm's approach did not work for me until I adapted it:
Download the Android-Pack and unzip it somewhere. We'll create a qmake-variable OPENCV_ANDROID which points to that directory later.
Add the following snippet to your *.pro-file:
android {
contains(ANDROID_TARGET_ARCH,arm64-v8a) {
isEmpty(OPENCV_ANDROID) {
error("Let OPENCV_ANDROID point to the opencv-android-sdk, recommended: v4.0")
}
INCLUDEPATH += "$$OPENCV_ANDROID/sdk/native/jni/include"
LIBS += \
-L"$$OPENCV_ANDROID/sdk/native/libs/arm64-v8a" \
-L"$$OPENCV_ANDROID/sdk/native/3rdparty/libs/arm64-v8a" \
-llibtiff \
-llibjpeg-turbo \
-llibjasper \
-llibpng \
-lIlmImf \
-ltbb \
-lopencv_java4 \
ANDROID_EXTRA_LIBS = $$OPENCV_ANDROID/sdk/native/libs/arm64-v8a/libopencv_java4.so
} else {
error("Unsupported architecture: $$ANDROID_TARGET_ARCH")
}
}
This will work for the arm64-v8a only. If you happen to build for another architecture (apparently 32-Bit is still the default for Qt#Android), you must change the .../libs/arm64-v8a part of the paths (occurs 3 times) and the same to match your actual target-architecture (the contains(...)-part in the second line of the snippet).
Tell qmake where to find the SDK. Add the following to qmake-call: "OPENCV_ANDROID=/path/to/OpenCV-android-sdk".
e.g., this looks like qmake example.pro "OPENCV_ANDROID=/home/user/OpenCV-android-sdk" from command line.
when you use QtCreator, add "OPENCV_ANDROID=..." to the "Additional arguments"-field. You can find it after enabling the Project-Mode in the Build-section of the android-kit. Expand the qmake-field under Build Steps
Starting from Android android-ndk-r18b, with Qt Creator 4.9.x kits, I could not use the openCV-4.1.1 pre-compiled shared libraries (.so) with Qt Android ABI armeabi-v7a target and ABI arm64-v8a, as Opencv standard is based on GCC, While the NDK-r18b removed gcc and uses clang compiler. ( I am getting
Fatal signal 11 (SIGSEGV), code 1
On initialize calling android_getCpuFeatures() when the application starts)
Thus, openCV shared libs must be compiled from sources for clang in order to be used with Qt Android kits.
This reference Compiling OpenCV on Android from C++ (Without OpenCVManager) was of real help. I would leave a reference here as well for a simple procedure I used under windows 10, to get opencv compiled with NDK 18 (clang) for Qt Android:
Downloaded openCV source code
Downloaded openCV contrib source for selected openCV version
Used cmake for windows
in the unzipped opencv source folder, created a new build folder.
MinGW from Qt installation can generally be used for building, So I used Qt 5.11.x (MinGW 5.3.0 32 bit) command line tool from Qt menu.
from command line, in new build folder, I could generate cmake configuration :
C:\opencv-4.1.1\build> "C:\program files\cmake\bin\cmake" .. -G"MinGW Makefiles"
-DBUILD_SHARED_LIBS=ON
-DANDROID_STL=c++_shared
-DANDROID_ABI="armeabi-v7a with NEON"
-DANDROID_NATIVE_API_LEVEL=23
-DANDROID_TOOLCHAIN=clang
-DCMAKE_TOOLCHAIN_FILE=D:\Qt\android-ndk-r18b\build\cmake\android.toolchain.cmake
-DANDROID_NDK=D:\Qt\android-ndk-r18b
-DANDROID_SDK=C:\Users\moham\AppData\Local\Android\sdk
-DCMAKE_BUILD_TYPE=Debug
-DBUILD_ANDROID_PROJECTS=OFF
-DWITH_OPENCL=ON -DWITH_TBB=ON -DENABLE_NEON=ON
-DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF
-DBUILD_FAT_JAVA_LIB=OFF
Then , C:\opencv-4.1.1\build>\mingw32-make -jx and C:\opencv-4.1.1\build>\mingw32-make install
the result libs can be picked from opencv-4.1.1\build\install folder
Link in Qt Android project:
android {
#opencv
OPENCVLIBS = $$PWD/../opencv-4.1.1\build\install/sdk/native
INCLUDEPATH = $$OPENCVLIBS/jni/include
contains(ANDROID_TARGET_ARCH,armeabi-v7a) {
# might need libs to be copied into app's library folder and loaded on start-up, in case android ships older libs??!
ANDROID_EXTRA_LIBS = \
$$OPENCVLIBS/libs/armeabi-v7a/libopencv_core.so \
$$OPENCVLIBS/libs/armeabi-v7a/libopencv_imgproc.so \
$$OPENCVLIBS/libs/armeabi-v7a/libtbb.so
LIBS += -L"$$OPENCVLIBS/libs/armeabi-v7a"\
-lopencv_core -lopencv_imgproc -ltbb
}
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android
}
Also, copy the libs to ANDROID_PACKAGE_SOURCE_DIR
Note: If detailed control over cmake configuration is needed, cmake windows gui can be used, while not a must and not tested. AmMIN's procedure is helpful for cmake tool, remember to add flag for shared Android STL.
I use Qt Creator to compile an Android application. I needed to integrate OpenCV into it, and it took me half a day to configure it properly, so I want to document the steps I took here, in case somebody else ever has to do it.
Edit: For OpenCV 4.x see the answers below. My answer was tested on OpenCV 2.4 only.
Original answer:
First, I downloaded OpenCV-2.4.10-android-sdk, and put into my project directory. It contains static libraries, and link order matters for static libraries for GCC. So you need to order them just so. This is how my .pro file looked in the end ($$_PRO_FILE_PWD_ refers to the project directory):
INCLUDEPATH += "$$_PRO_FILE_PWD_/OpenCV-2.4.10-android-sdk/sdk/native/jni/include"
android {
LIBS += \
-L"$$_PRO_FILE_PWD_/OpenCV-2.4.10-android-sdk/sdk/native/3rdparty/libs/armeabi-v7a"\
-L"$$_PRO_FILE_PWD_/OpenCV-2.4.10-android-sdk/sdk/native/libs/armeabi-v7a"\
-llibtiff\
-llibjpeg\
-llibjasper\
-llibpng\
-lIlmImf\
-ltbb\
-lopencv_core\
-lopencv_androidcamera\
-lopencv_flann\
-lopencv_imgproc\
-lopencv_highgui\
-lopencv_features2d\
-lopencv_calib3d\
-lopencv_ml\
-lopencv_objdetect\
-lopencv_video\
-lopencv_contrib\
-lopencv_photo\
-lopencv_java\
-lopencv_legacy\
-lopencv_ocl\
-lopencv_stitching\
-lopencv_superres\
-lopencv_ts\
-lopencv_videostab
ANDROID_PACKAGE_SOURCE_DIR=$$_PRO_FILE_PWD_/android
}
After that the project will compile but it will fail to run with the error
E/AndroidRuntime(11873): java.lang.UnsatisfiedLinkError: Cannot load library: link_image[1891]: 176 could not load needed library 'libopencv_java.so' for 'libMyProject.so' (load_library[1093]: Library 'libopencv_java.so' not found)
To overcome this, you need to add libopencv_java.so to your APK, and then manually load it from QtActivity.java. That's what the ANDROID_PACKAGE_SOURCE_DIR=$$_PRO_FILE_PWD_/android line at the end was for. Now you need to place libopencv_java.so here:
project_root/android/libs/armeabi-v7a/libopencv_java.so
project_root/android/src/org/qtproject/qt5/android/bindings/QtActivity.java
You can get QtActivity.java from the Android target build directory, in my case the full path was c:\Workspace\build-MyProject-Android_for_armeabi_v7a_GCC_4_9_Qt_5_4_0-Debug\android-build\src\org\qtproject\qt5\android\bindings\QtActivity.java, and just copy it.
Then you find those lines in it:
// now load the application library so it's accessible from this class loader
if (libName != null)
System.loadLibrary(libName);
And load libopencv_java.so before them, so they become:
// This is needed for OpenCV!!!
System.loadLibrary("opencv_java");
// now load the application library so it's accessible from this class loader
if (libName != null)
System.loadLibrary(libName);
Note that you pass opencv_java to System.loadLibrary(), even though the file is libopencv_java.so.
Edit: I forgot to mention, but I already had installed OpenCV Manager on my phone when trying to run one of the samples that come with OpenCV-2.4.10-android-sdk, so I don't know if it's needed or not. In any event, keep it in mind, if it fail even after my steps, you might need to download OpenCV Manager (it's available on the Google Store).
Edit 2: I'm using adt-bundle-windows-x86-20140702, android-ndk-r10d, OpenCV-2.4.10-android-sdk, Qt Creator 3.3.0, and my build target is "Android for armeabi-v7a (GCC 4.9, Qt 5.4.0)".
Edit 3: From Daniel Saner's comment:
In OpenCV 3.x, opencv_java has been renamed to opencv_java3. Also, while I didn't look into the specific changes that might have effected this, the workaround regarding that library in the final step seems to no longer be necessary. The app compiles and runs without the ANDROID_PACKAGE_SOURCE_DIR line
Edit 4: #myk's comment:
Worked for me with OpenCV 3.2. To workaround the build issues with carotene finish the LIBS+ section with: -lopencv_videostab\ -ltegra_hal\ – myk 2 hours ago
For OpenCV 4, sashoalm's approach did not work for me until I adapted it:
Download the Android-Pack and unzip it somewhere. We'll create a qmake-variable OPENCV_ANDROID which points to that directory later.
Add the following snippet to your *.pro-file:
android {
contains(ANDROID_TARGET_ARCH,arm64-v8a) {
isEmpty(OPENCV_ANDROID) {
error("Let OPENCV_ANDROID point to the opencv-android-sdk, recommended: v4.0")
}
INCLUDEPATH += "$$OPENCV_ANDROID/sdk/native/jni/include"
LIBS += \
-L"$$OPENCV_ANDROID/sdk/native/libs/arm64-v8a" \
-L"$$OPENCV_ANDROID/sdk/native/3rdparty/libs/arm64-v8a" \
-llibtiff \
-llibjpeg-turbo \
-llibjasper \
-llibpng \
-lIlmImf \
-ltbb \
-lopencv_java4 \
ANDROID_EXTRA_LIBS = $$OPENCV_ANDROID/sdk/native/libs/arm64-v8a/libopencv_java4.so
} else {
error("Unsupported architecture: $$ANDROID_TARGET_ARCH")
}
}
This will work for the arm64-v8a only. If you happen to build for another architecture (apparently 32-Bit is still the default for Qt#Android), you must change the .../libs/arm64-v8a part of the paths (occurs 3 times) and the same to match your actual target-architecture (the contains(...)-part in the second line of the snippet).
Tell qmake where to find the SDK. Add the following to qmake-call: "OPENCV_ANDROID=/path/to/OpenCV-android-sdk".
e.g., this looks like qmake example.pro "OPENCV_ANDROID=/home/user/OpenCV-android-sdk" from command line.
when you use QtCreator, add "OPENCV_ANDROID=..." to the "Additional arguments"-field. You can find it after enabling the Project-Mode in the Build-section of the android-kit. Expand the qmake-field under Build Steps
Starting from Android android-ndk-r18b, with Qt Creator 4.9.x kits, I could not use the openCV-4.1.1 pre-compiled shared libraries (.so) with Qt Android ABI armeabi-v7a target and ABI arm64-v8a, as Opencv standard is based on GCC, While the NDK-r18b removed gcc and uses clang compiler. ( I am getting
Fatal signal 11 (SIGSEGV), code 1
On initialize calling android_getCpuFeatures() when the application starts)
Thus, openCV shared libs must be compiled from sources for clang in order to be used with Qt Android kits.
This reference Compiling OpenCV on Android from C++ (Without OpenCVManager) was of real help. I would leave a reference here as well for a simple procedure I used under windows 10, to get opencv compiled with NDK 18 (clang) for Qt Android:
Downloaded openCV source code
Downloaded openCV contrib source for selected openCV version
Used cmake for windows
in the unzipped opencv source folder, created a new build folder.
MinGW from Qt installation can generally be used for building, So I used Qt 5.11.x (MinGW 5.3.0 32 bit) command line tool from Qt menu.
from command line, in new build folder, I could generate cmake configuration :
C:\opencv-4.1.1\build> "C:\program files\cmake\bin\cmake" .. -G"MinGW Makefiles"
-DBUILD_SHARED_LIBS=ON
-DANDROID_STL=c++_shared
-DANDROID_ABI="armeabi-v7a with NEON"
-DANDROID_NATIVE_API_LEVEL=23
-DANDROID_TOOLCHAIN=clang
-DCMAKE_TOOLCHAIN_FILE=D:\Qt\android-ndk-r18b\build\cmake\android.toolchain.cmake
-DANDROID_NDK=D:\Qt\android-ndk-r18b
-DANDROID_SDK=C:\Users\moham\AppData\Local\Android\sdk
-DCMAKE_BUILD_TYPE=Debug
-DBUILD_ANDROID_PROJECTS=OFF
-DWITH_OPENCL=ON -DWITH_TBB=ON -DENABLE_NEON=ON
-DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF
-DBUILD_FAT_JAVA_LIB=OFF
Then , C:\opencv-4.1.1\build>\mingw32-make -jx and C:\opencv-4.1.1\build>\mingw32-make install
the result libs can be picked from opencv-4.1.1\build\install folder
Link in Qt Android project:
android {
#opencv
OPENCVLIBS = $$PWD/../opencv-4.1.1\build\install/sdk/native
INCLUDEPATH = $$OPENCVLIBS/jni/include
contains(ANDROID_TARGET_ARCH,armeabi-v7a) {
# might need libs to be copied into app's library folder and loaded on start-up, in case android ships older libs??!
ANDROID_EXTRA_LIBS = \
$$OPENCVLIBS/libs/armeabi-v7a/libopencv_core.so \
$$OPENCVLIBS/libs/armeabi-v7a/libopencv_imgproc.so \
$$OPENCVLIBS/libs/armeabi-v7a/libtbb.so
LIBS += -L"$$OPENCVLIBS/libs/armeabi-v7a"\
-lopencv_core -lopencv_imgproc -ltbb
}
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android
}
Also, copy the libs to ANDROID_PACKAGE_SOURCE_DIR
Note: If detailed control over cmake configuration is needed, cmake windows gui can be used, while not a must and not tested. AmMIN's procedure is helpful for cmake tool, remember to add flag for shared Android STL.
I've build the Android NDK toolchain manually. Everything works except when I use the compiler it can't find basic STL stuff like . So it can't compile code containing STL because it doesn't know where to look for the headers by default. I've never had this problem before using a custom or prebuilt toolchain. However if I manually add the include directories like
-I$(NDK_TOOLCHAIN)/arm-linux-androideabi/include/c++/4.6/
Then it works just fine. It is a pain to add every important dir manually (there is more than this one). Surely something broken in the process.
These are the steps I followed to get it build:
sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl
Download NDK
Untar NDK to [SOME_LOCATION], using /opt/ndk/
Set NDK_ROOT=/opt/ndk/
./build/tools/download-toolchain-sources.sh src/
Download MPC 0.9
Move mpc tar to ./src/mpc/
./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) arm-linux-androideabi-4.6
./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) x86-4.6
./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) mipsel-linux-android-4.6
All the STL files exist in the proper location. All the headers and compiled libraries for each version if I build a STANDALONE toolchain after using as reference these custom built toolchains.
==
UPDATE
Forcing gcc to spit out its include search paths:
echo "#include <bogus.h> int main(){}" > t.c; /opt/android-9_arm/bin/arm-linux-androideabi-gcc -v t.c; rm t.c
This contains a search path under includes:
/opt/android-9_arm/bin/../lib/gcc/arm-linux-androideabi/4.6.x-google/../../../../arm-linux-androideabi/include
At that location is indeed the following ./cxx/4.6/STL_HEADERS
Comparing the output with a NDK build from google does indeed differ in serious spots. The real question is now how do I guarantee my custom build of GCC points to the appropriate G++ STL header location.
It turned out to be a bug in make-standalone-toolchain.sh. The fix was:
mv $NDK_TOOLCHAIN/arm-linux-androideabi/include/c++/4.6 $NDK_TOOLCHAIN/arm-linux-androideabi/include/c++/4.6.x-google
That fixed it for the most part. However now that the ndkr8b has released with official GCC 4.6 support this bug stills exists (as of july 25 2012). More details on some bugs related to the standalone toolchain (http://code.google.com/p/android/issues/detail?id=35279).