I'm setting up an android project from another company which involves selfmade C++ cross platform libraries. For an older version of these libraries an complete app project was made in java with a jni interface to access these libraries, which are stored as their own modules with gradle.build files. The goal is to get the app compiling for arm64-v8a architecture because of the Google requirements for app update.
The project is set up with:
gradle experimental plugin 0.11.0
gradle plugin 4.1
boost 1.64.0 for armeabi-v7a (got arm64-v8a precompiled libraries as replacement)
opencv 2.4.13.2
ndk r15c
I checked all dependencies for getting a arm64 pendant, which was only needed for the boost dependencies.
I tried changing the ABI list which is used for every project to include all architectures or all seperatly. I tried using other ndk versions. What might help but i didn't accomplish was changing the experimental gradle plugin to the normal plugin but i couldn't get that right.
I expected some compiling or linking errors but it only tells me "ABI filter 'arm64-v8a' is no longer supported in NDK version r15.2.4203891.". If i try other architectures i get the same error, but instead of the 'arm64-v8a' the current selected architecture. If i give an invalid architecture it changes to "Target ABI 'hello' is not supported.", so it recognizes the architecture i think.
Stacktrace of first error:
A problem occurred configuring project ':app'.
Exception thrown while executing model rule: NdkComponentModelPlugin.Rules#configureNativeLibrary(ModelMap, NdkConfig, NdkHandler, ModelMap, File, ServiceRegistry) > create(livestage) > withType()
Exception thrown while executing model rule: NdkComponentModelPlugin.Rules#configureNativeLibrary(ModelMap, NdkConfig, NdkHandler, ModelMap, File, ServiceRegistry) > create(lib-jni-cxx) > withType()
Exception thrown while executing model rule: NdkComponentModelPlugin.Rules#configureNativeBinary(BinaryContainer, ModelMap, NdkConfig, NdkHandler) > withType()
ABI filter 'arm64-v8a' is no longer supported in NDK version r15.2.4203891.
The experimental plugin hasn't been supported for years, so it's no surprise that it doesn't work. Migrate to externalNativeBuild: https://developer.android.com/studio/projects/add-native-code
Related
I am unable to build a NDK project from the Android Studio environment but can build it manually using the command console.
I get the following error after building:
Error:Execution failed for task ':xxxxxx:compileReleaseNdk'.> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'C:\Users\xxxxx\AppData\Local\Android\SDK\android-sdk\ndk-bundle\ndk-build.cmd'' finished with non-zero exit value 2
I got a similar error while invoking ndk-build.cmd manually using the console from the jni directory where my NDK project is stored.However I fixed it by modifying the following in my Application.mk file as follows:
NDK_TOOLCHAIN_VERSION := 4.9
since 4.9 is the tool chain available on my install. I suspect from the Android Studio environment, the toolchain version is being picked incorrectly, and yet I do not know where to set this option in the GUI.
The build.gradle file has the following NDK block:
ndk{
moduleName "xxxxxx"
ldLibs "log"
cFlags "-std=c++11 -fexceptions"
stl "gnustl_static"
abiFilters "arm64-v8a armeabi armeabi-v7a mips mips64 x86 x86_64"
}
Please advise me on how to go about solving this problem.
Just out of curiosity, I moved my project directory to the desktop and tried to build that project. The build was successful.
Finally narrowed down the problem to the NDK compiler not being able to create the following intermediate object file inside my project folder:
C:\Users\xxxxx\GitRepos\REVIEWS\xxx\SMART-xxx\xxxx-xxx-androidnative\xxxLibraries\xxxlibrary\build\intermediates\ndk\debug\obj/local/arm64-v8a/objs/natXXXX/C_\Users\xxxxx\GitRepos\REVIEWS\xxx\SMART-xxxx\xxxx-xxx-androidnative\xxxLibraries\xxxlibrary\src\main\jni\NativeXXXX.o.d
The reason was the well known windows path cannot exceed 255 characters issue. As you can see above the NDK-Build utility tries to append a deep folder hierarchy like "C_\Users\xxxxx\GitRepos\REVIEWS\xxx\SMART-xxxx\xxxx-xxx-androidnative\xxxLibraries\xxxlibrary\src\main\jni\" which exceeds MAX_PATH.
So I am trying to build and test out a CMake with the Android NDK on Android Studio. I can get my library to compile, but it doesn't seem to want to pull any third-party dependencies over. I've been reading through the toolchain and looking for better documentations, with no luck. Can someone tell me if I am missing?
cmake_minimum_required(VERSION 3.4.1)
set(SFML_PATH ${ANDROID_NDK}/sources/sfml)
set(SFML_LIB_PATH ${SFML_PATH}/lib/${ANDROID_NDK_ABI_NAME})
set(SFML_LIB_SYSTEM ${SFML_LIB_PATH}/libsfml-system.so)
set(SFML_LIB_AUDIO ${SFML_LIB_PATH}/libsfml-audio.so)
set(SFML_LIB_GRAPHICS ${SFML_LIB_PATH}/libsfml-graphics.so)
set(SFML_LIB_NETWORK ${SFML_LIB_PATH}/libsfml-network.so)
set(SFML_LIB_WINDOW ${SFML_LIB_PATH}/libsfml-window.so)
set(SFML_LIB_ACTIVITY ${SFML_LIB_PATH}/libsfml-activity.so)
set(SFML_LIB_MAIN ${SFML_LIB_PATH}/libsfml-main.a)
set(SFML_LIBS ${SFML_LIB_SYSTEM} ${SFML_LIB_GRAPHICS} ${SFML_LIB_AUDIO} ${SFML_LIB_WINDOW} ${SFML_LIB_ACTIVITY})
include_directories(${SFML_PATH}/include)
link_directories(${SFML_LIB_PATH})
add_library(native-lib SHARED
src/main/cpp/native-lib.cpp)
target_link_libraries(native-lib log ${SFML_LIBS})
#file(COPY ${SFML_LIBS} DESTINATION ${__android_install_path})
FOREACH(SFML_LIB ${SFML_LIB})
execute_process( COMMAND "${CMAKE_COMMAND}" -E copy_if_different "${SFML_LIB}" "${LIBRARY_OUTPUT_PATH}/${SFML_LIB}" RESULT_VARIABLE __fileCopyProcess )
MESSAGE("Lib: ${SFML_LIB}")
ENDFOREACH(SFML_LIB)
Above is my CMakeLists.txt. I have done a little hacking to get it to compile with SFML with the paths, as I have not found good documentation with CMake and Android yet.
May you add more info for:
"but it doesn't seem to want to pull any third-party dependencies over."?
this one:
https://github.com/googlesamples/android-ndk/tree/master/hello-libs
has static and shared 3rd party libs, you may try it.
For the shared dependent lib, you will need to pack them into APK, that is done inside gradle, cmake will not do it.
The above example shows that, basically they need to be copied into your app/src/main/jniLibs too so they will be packed into apk, and pushed to your android phone/tablet. At runtime they could be loaded.
I have tried to put a group of libraries into one directory, and use
link_directories(...)
then just put the lib names directly into
target_link_libraries(...)
also works. Make sure you have the right libs for the ABIs you intend to support for your app [looks like you are just building for one ABI].
The process could be little long it will depend on your android skills.
An example could be similar to this process:
Crosscompile sfml.
Create your jni bridge
Generate with cmake the project and compile
Copy your files to android studio. create java loading library code.
I guess that you have crosscompiled sfml and you know how works crosscompiling process, if I am wrong check these link below:
Tutorial:
https://github.com/SFML/SFML/wiki/Tutorial:-Building-SFML-for-Android
Source code:
https://github.com/SFML/SFML
Toolchain:
https://github.com/SFML/SFML/blob/master/cmake/toolchains/android.toolchain.cmake
Changes on your cmake:
add this file
FIND_PACKAGE(SFML required)
In cmake put your SFML build directory and cmake will fills your VARIABLES
automatically for instance this variables:
set(SFML_PATH ${ANDROID_NDK}/sources/sfml)
set(SFML_LIB_PATH ${SFML_PATH}/lib/${ANDROID_NDK_ABI_NAME})
set(SFML_LIB_SYSTEM ${SFML_LIB_PATH}/libsfml-system.so)
set(SFML_LIB_AUDIO ${SFML_LIB_PATH}/libsfml-audio.so)
set(SFML_LIB_GRAPHICS ${SFML_LIB_PATH}/libsfml-graphics.so)
set(SFML_LIB_NETWORK ${SFML_LIB_PATH}/libsfml-network.so)
set(SFML_LIB_WINDOW ${SFML_LIB_PATH}/libsfml-window.so)
set(SFML_LIB_ACTIVITY ${SFML_LIB_PATH}/libsfml-activity.so)
set(SFML_LIB_MAIN ${SFML_LIB_PATH}/libsfml-main.a)
There are two ways to make android studio native apps:
Easy way:
Create JNI bridge:
Crosscompile your cmake script and copy your lib to app/src/main/jniLibs
add library in execution time
code:
try
{
Log.v(LOG_TAG, "adding your library");
System.loadLibrary(your_library);
}
catch(UnsatisfiedLinkError e)
{
Log.e(LOG_TAG,e.getMessage());
}
More complete way (it allows to debug library)
Create your ndk module in gradle
example
android.ndk {
moduleName = "your_library"
cppFlags.add("-fexceptions")
//cppFlags.add("-std=c++11")
//cFlags.add("-fopenmp")
cppFlags.add("-I" + file("src/main/jni").absolutePath)
stl = "gnustl_shared" // Which STL library to use: gnustl or stlport
ldLibs.addAll(["android", "EGL", "GLESv2", "dl", "log", "z"])
String libsDir = curDir.absolutePath + "/src/main/jniLibs/armeabi/"
ldLibs.add(libsDir + "your_native_lib.so")
}
I am trying to generate some Boost 1.58 libraries that I need (chrono, regex and thread) for Visual Studio 2012 and link the libraries with CMake. I have real problems for CMake and Visual Studio to find or link the libs, depending on the configuration I set.
I am finally using the following configuration:
bjam.exe --link=static --threading multi --variant=debug stage
But this doesn't seem to generate static libs.
How should I generate the libs and search them with CMake in order for Visual Studio to link them properly?
I finally came up with the solution and I think it is detailed enough to become a generic answer.
Visual Studio searches for dynamic libraries so we need to compile Boost libraries as shared, multithreaded, debug and release, and runtime-link shared. In windows using bjam.exe all commands have the prefix "--" except link, so the right way to build the libraries is:
bjam.exe link=shared --threading=multi --variant=debug --variant=release --with-chrono --with-regex --with-thread stage
This will generate the libs and DLLs in the folder Boost/stage/lib, so we need to set an environment variable Boost_LIBRARY_DIR C:/Boost/stage/lib, for example.
There are more options that may come in hand:
runtime-link = shared/static
toolset= msvc-11.0
The libraries will have a name like this for release:
boost_chrono-vc110-mt-1_58.lib
boost_chrono-vc110-mt-1_58.dll
And for debug:
boost_chrono-vc110-mt-gd-1_58.lib
boost_chrono-vc110-mt-gd-1_58.dll
In order for CMake to link them properly we need to write the following in the CMakeLists.txt:
add_definitions( -DBOOST_ALL_DYN_LINK ) //If not VS will give linking errors of redefinitions
set(Boost_USE_STATIC_LIBS OFF )
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
find_package(Boost COMPONENTS thread chrono regex REQUIRED )
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES( ${PROJ_NAME} ${Boost_LIBRARIES} )
bjam.exe --link=static --threading multi --variant=debug stage
But this doesn't seem to generate static libs.
Building the special stage target places Boost library binaries in the stage\lib\ subdirectory of the Boost tree.
More about building Boost on Windows here
CMake:
SET (CMAKE_BUILD_TYPE Debug) # in order to link with boost debug libs you may need to set that to build your program in debug mode (or do that from command line)
FIND_PACKAGE (Boost 1.58 COMPONENTS "chrono" "regex" "thread" REQUIRED)
#ADD_DEFINITIONS(-DBOOST_ALL_DYN_LINK) # make sure you don't have this as it will try to link with boost .dll's
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
TARGET_LINK_LIBRARIES(${EXE_OR_LIB_NAME} ${Boost_LIBRARIES})
Version 0.7.+'s of the gradle plugin includes preliminary ndk support. I worked off the examples but I get a compilation error when trying to include a standard NDK header:
In file included from /foo/src/main/jni/Bar.h:4:0,
from /foo/src/main/jni/Bar.cpp:1:
/foo/src/main/jni/baz.h:4:25: fatal error: android/log.h: No such file or directory
compilation terminated.
Where baz.h has this line:
#include <android/log.h>
And my gradle file has:
ndk {
ldLibs "log"
}
Has anyone made this work?
shouldn't it be ldLibs "-llog" ?
P.S.
NDK support is very unstable now... I was fighting with it for a few days - it completely broken on Windows. No easy way to disable it (but still possible). On some circumstances build process will generate wrong file path (like /foo/bar//foo/bar/source.c). So we switched back to the 0.6.+ version and monitoring https://code.google.com/p/android/issues/list?q=tools%40android.com
I have a Monotouch project linked to a static library containing C++ modules.
Monotouch version: 3.0.3.5
XCode version: 4.4.1
C/C++ Compiler: Apple LLVM 4.0
When building the project in debug mode for iOS simulator and iOS device everything is OK -
application is linked and runs.
However when building the release configuration for iOS device the following error appears:
Undefined symbols for architecture armv7: "___divmodsi4"
The following line from the static library code somehow causes the trouble:
int number_of_buckets = num_samples / window_samples_step;
If this line is modified as follows the problem disappears:
int number_of_buckets = (int)((float)num_samples / (float)window_samples_step);
Do you have any ideas how to fix the problem without the above modification?
Thanks,
Ury.
This occurs near the end of the build and generally depends on it's original parameters. Try to compare your options between your Release and Debug builds and check that:
you are using the same Additional mtouch arguments on both configuration;
you are using the same compiler, Mono AOT versus LLVM compilers, on both configuration;
you are using the same architecture, ARMv6 versus ARMv7, on both configuration.
Otherwise attach (e.g. preferable to a bug report or pastebin) the full build log (from the Build Output of MonoDevelop's Error Pad) for both Debug and Release builds.
To be more helpful add "-v -v -v" to the Additional mtouch arguments before re-building. This will augment the verbosity (details) about each steps.
You need to set the app's Deployment Target (in the project's options, Build / iPhone Application page) to at least 5.0.