I am trying to add the VTK to my native Android project in AS 3.3. I have installed the NDK r17c. I would like to use some of the VTK functionalities in my native application. Also, I am using gradle 3.3.2 for building my android project and CMake 3.6.4 for building native side of the project. My problem is that I haven't found a suitable tutorial (I am new to Android native development) for importing the VTK into the Android Studio using all building tools that I have described. Is there a way to do that?
Also, I would like to add that I am using Windows 7 OS.
EDIT: I had updated my CMakeLists.txt file with some lines I had found relevant in the official example (https://github.com/Kitware/VTK/tree/master/Examples/Android). I would like to use VTK inside my native-lib library:
# For more information about using CMake with Android Studio, read the
# documentation: https://d.android.com/studio/projects/add-native-code.html
# Sets the minimum version of CMake required to build the native library.
cmake_minimum_required(VERSION 3.4.1)
# Creates and names a library, sets it as either STATIC
# or SHARED, and provides the relative paths to its source code.
# You can define multiple libraries, and CMake builds them for you.
# Gradle automatically packages shared libraries with your APK.
link_directories(src/main/jni/japi src/main/jni/acquisition)
file(GLOB native_SRC
"src/main/jni/japi/*.h"
"src/main/jni/japi/*.cpp"
)
add_library( # Sets the name of the library.
native-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
${native_SRC})
file(GLOB acquisition_SRC
"src/main/jni/acquisition/*.h"
"src/main/jni/acquisition/*.cpp"
)
#file(GLOB acquisition_SRC
# "src/main/jni/acquisition/*.h"
# )
add_library( acquisition-lib STATIC ${acquisition_SRC})
#add_library(
# acquisition-lib
#
# STATIC
#
# src/main/jni/acquisition/test-lib.h
# src/main/jni/acquisition/test-lib.cpp)
# Searches for a specified prebuilt library and stores the path as a
# variable. Because CMake includes system libraries in the search path by
# default, you only need to specify the name of the public NDK library
# you want to add. CMake verifies that the library exists before
# completing its build.
find_library( # Sets the name of the path variable.
log-lib
# Specifies the name of the NDK library that
# you want CMake to locate.
log )
# Specifies libraries CMake should link to your target library. You
# can link multiple libraries, such as libraries you define in this
# build script, prebuilt third-party libraries, or system libraries.
target_link_libraries( # Specifies the target library.
native-lib
# Links the target library to the log library
# included in the NDK.
${log-lib})
target_link_libraries( native-lib acquisition-lib )
set(OpenCV_DIR "../opencv/src/sdk/native/jni")
find_package(OpenCV REQUIRED)
message(STATUS "OpenCV libraries: ${OpenCV_LIBS}")
target_link_libraries(native-lib ${OpenCV_LIBS})
target_link_libraries(acquisition-lib ${OpenCV_LIBS})
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,--exclude-libs,libippicv.a -Wl,--exclude-libs,libippiw.a")
##ADDED for including the VTK
find_package(VTK COMPONENTS
vtkInteractionStyle
vtkRenderingOpenGL2
vtkRenderingFreeType
vtkTestingCore
vtkTestingRendering
)
include(${VTK_USE_FILE})
target_link_libraries( native-lib ${VTK_LIBRARIES} )
Ok, it took me about a week to get this working, but it paid off. I will list all the things I needed to do to be able to use VTK in my android application.
STEP 1: Building VTK on Linux machine
Because Android is based on the Linux OS, you need to build libraries in .a or .so format. To do this, the easiest thing to do is to build VTK on Linux machine. So you have to install Linux to your machine eather as dual boot or, as in my case, install a virtual machine that runs Linux.
After that, you need to install all the thing needed to download and build VTK for Android. Here is the list of the things you need to download and install to your Linux machine:
Download and install the Android NDK- I downloaded the same version that I am using in my Android Studio - r17c
Download and install the Android SDK , i.e. Android Studio
Download and install ANT
Download and install Java
Download and install CMake - also after I installed it, I needed to run: sudo apt-get update && sudo apt-get install build-essential
Download and install Git
Install OpenGL - I used: sudo apt-get install freeglut3-dev
Define ANDROID_NDK environment variable - point it to unzipped android NDK folder
Define ANT_HOME environment variable - point it to unzipped ANT folder
Define JAVA_HOME environment variable - point it to unzipped Java JRE folder
Define ANDROID_SDK environment variable - point it to the location of Android/Sdk folder
Define CMAKE_HOME environment variable - point it to the location of your installed CMake
Add to PATH enviroment variable: ANT_HOME/bin, JAVA_HOME/bin, ANDROID_SDK/platform-tools, ANDROID_SDK/tools, CMAKE_HOME/bin
After the installation of the all the needed tools above, you need to download the VTK source code using git:
Create an 'vtk' folder somewhere
cd vtk
git clone https://github.com/Kitware/VTK.git
Now, you can go and build the VTK:
mkdir vtk/vtk-android
cd vtk-android
ccmake ../VTK
press c (configure)
press c (configure)
press q (quit)
cmake -DVTK_ANDROID_BUILD=ON -DANDROID_NATIVE_API_LEVEL=23 -DANDROID_ARCH_ABI=arm64-v8a ../VTK - here I defined the 23 api level because that is what I am using in my applicatin. Also, here is where you define the architecture ABI of your targeted devices. My device is arm64-v8a so I am using that. In order to build VTK for other architectures, you will need to build for every each one of them. Also, you can edit this in the next step!
ccmake ../VTK
OPTIONAL: at this point, you can define additional modules you need in your application. If you just skip this step, the modules (.a files) you will get are:
vtkCommonColor, vtkCommonComputationalGeometry, vtkCommonCore,
vtkCommonDataModel, vtkCommonExecutionModel, vtkCommonMath, vtkCommonMisc,
vtkCommonSystem, vtkCommonTransforms, vtkDICOMParser, vtkdoubleconversion,
vtkexpat, vtkFiltersCore, vtkFiltersExtraction, vtkFiltersGeneral,
vtkFiltersGeometry, vtkFiltersHybrid, vtkFiltersModeling, vtkFiltersSources,
vtkFiltersStatistics, vtkfreetype, vtkglew, vtkImagingCore,
vtkImagingFourier, vtkImagingMath, vtkImagingSources, vtkInfovisCore,
vtkInteractionStyle, vtkIOCore vtkIOGeometry, vtkIOImage, vtkIOInfovis,
vtkIOLegacy, vtkIOPLY, vtkIOXML, vtkIOXMLParser, vtkjpeg, vtkjsoncpp,
vtklibxml2, vtklz4, vtklzma, vtkmetaio, vtkParallelCore, vtkpng,
vtkRenderingCore, vtkRenderingFreeType, vtkRenderingOpenGL2,
vtkRenderingVolume, vtkRenderingVolumeOpenGL2, vtksys, vtkTestingRendering,
vtktiff, vtkWrappingTools, vtkzlib
If these modules are not sufficient for you, you need to add some lines to VTK/CMake/vtkAndroid.cmake file because there the build for android is defined. Lines you add must look like:
-DVTK_MODULE_ENABLE_VTK_[name-of-the-module]:STRING=YES
You can find out all possible name-of-the-module values if you press t (toggle) and scroll to VTK_MODULE_ENABLE_VTK_... part of the configuration.
c (configue)
g (generate)
make
Ok, so the build process starts. On my laptop it took ~30mins (I assigned 3GB of RAM to the virtual machine).
STEP 2 : Importing the VTK to the Android Studio
After the build process is finished, you need to copy the folder vtk/vtk-android/CMakeExternals/Install/vtk-android to the your Windows machine.
The folder lib contains the build VTK library as a set of static libraries (.a files), and the folder include contains all the header files of the VTK you neeed to get the VTK working in full.
Now, in your Android Studio project, create a new Android Library module called vtk.
Create the src/main/jni folder and inside that folder copy the lib and include folder described above.
In jni folder crate an vtk-lib.cpp file which will serve as an interface from your Java code to the VTK library. An example may be:
#include <jni.h>
#include <vtkConeSource.h>
extern "C"
JNIEXPORT void JNICALL
Java_link_to_your_java_function(
JNIEnv *env,
jobject /*this*/) {
vtkConeSource *cone = vtkConeSource::New();
cone->SetHeight(3.0);
cone->Delete();
}
In the build.gradle file of your vtk module, add this lines:
android {
...
defaultConfig {
...
externalNativeBuild {
cmake {
cppFlags "-std=c++11"
arguments "-DANDROID_CPP_FEATURES=rtti exceptions",
"-DANDROID_STL=gnustl_shared"
abiFilters 'arm64-v8a'
}
}
}
...
externalNativeBuild {
cmake {
path "src/main/jni/CMakeLists.txt"
}
}
}
After that, to the jni folder add a CMakeLists.txt file which will be used for building the module:
cmake_minimum_required(VERSION 3.4.1)
set(LIB_DIR ${PROJECT_SOURCE_DIR}/lib/${ANDROID_ABI})
add_library(vtk-common-color STATIC IMPORTED)
set_target_properties(vtk-common-color
PROPERTIES IMPORTED_LOCATION
${LIB_DIR}/libvtkCommonColor-8.90.a)
#53 more libraries from lib folder
add_library( vtk-lib SHARED ${PROJECT_SOURCE_DIR}/vtk-lib.cpp)
target_include_directories(vtk-lib PRIVATE ${PROJECT_SOURCE_DIR}/include)
target_link_libraries(
vtk-lib
-Wl,--start-group -L ${TARGET_OUT}
vtk-common-color
#53 more libraries names
-Wl,--end-group
)
And that's it, voila!
You can
start with the official example on GitHub:
NativeVTK is built around the
Android native interface and does not have any Java code associated with it.
Any unser interface elements would need to be created in C++ using regular
VTK widgets or other OpenGL elements. This is best for applications that
are mainly focused on rendering or visualization with very minimal user
interface. In this example all the key code is in jni/main.cxx and it will
look very much like the regular VTK code you are used to.
It doesn't use Android Studio, and for good! Loading huge amounts of 3rd party native code into Android Studio is both useless and frustrating. It is much better to have such libraries compiled with their native build tools, and only import small modules that require lots of changes and/or interactive debugging.
Since Crosswalk is over 40mb. I have decide split my apk to reduce apk size...
I have know how to publish differenk apk on Google Play Store...I have readed documantations...
Documentation says:
Supporting multiple CPU architectures When using the Android NDK, you
can create a single APK that supports multiple CPU architectures by
declaring each of the desired architectures with the APP_ABI variable
in the Application.mk file.
For example, here's an Application.mk file that declares support for
three different CPU architectures:
APP_ABI := armeabi armeabi-v7a mips APP_PLATFORM := android-9
NDK Application Documantation says
The Application.mk file is really a tiny GNU Makefile fragment that
defines several variables for compilation. It usually resides under
$PROJECT/jni/, where $PROJECT points to your application's project
directory. Another alternative is to place it under a sub-directory of
the top-level $NDK/apps/ directory. For example:
$NDK/apps//Application.mk Here, is a short name used to
describe your app to the NDK build system. It doesn't actually go into
your generated shared libraries or your final packages
I have no experience for NDK...watched some videos...
In this question latest answer told
For arm you'd put this line in Application.mk :
APP_ABI := armeabi armeabi-v7a
And for intel x86 :
APP_ABI := x86
And you have to change AndroidManifest.xml to have a
different version for each platform (following the instructions in the
link you provided).
Be carefull, if you run cordova build android again, it will probably
replace all the content of platforms/android, and your changes will be
lost.
To build the project use
platforms\android\cordova\build.bat -release
So if I do integrate my app with NDK and puting APP_ABI variable will split apk cpu architecture?
is there a easy way for this? do I have to do additional steps?
Crosswalk library for single architecture will increase the APK size by 20M. If you find it's over 40M, the library maybe for both of x86 and ARM.
If you are using official packaging tools of Crosswalk, you can choose targeting architecture. If you are using Crosswalk as library reference, you can download the library for different architecture separately from official website.
I would like to be able to build a shared library in using the android ndk-build script, but for some reason I get a bunch of errors:
# I have Application.mk and Android.mk in the current folder
ndk-build -C .
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
Is there a way to build the Android shared library with only the source and header files?$$\int$$
Yes, you can write
ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk
But it's much easier to create ./jni directory and put both Application.mk and Android.mk there.
I'm trying to build static FAT library for Android NDK which should contain armv6 and armv7 versions.
Tried libtool - doesn't help, cause on MacOS it is not compatible with Android ABI.
Tried ranlib that I found in my NDK folder also with no success.
As an option could someone explain how should I use Android.mk to specify an appropriate library for an architecture.
On Android you don't (at least currently) create fat binaries. Instead, your APK will contain 1:n binaries for the architectures you wish to support.
Your Application.mk (preferred) or Android.mk should define a APP_ABI variable for the architecture(s)
For example, to support ARM (generic) and ARMv7a:
APP_ABI := armeabi armeabi-v7a
See $(NDK)/docs/APPLICATION-MK.txt for more information.
I've downloaded a custom toolchain (linaro) to build ARM based Android apps. How do I tell the NDK to use it? Can I define or set something in Android.mk and Application.mk that would allow me to do that? Is there another way?
The NDK makefile system is quite extensible and you can indeed define a different toolchain. You'll need some understanding of how Make works.
Toolchains are discovered and initialized in build/core/init.mk line 261 (in NDKr6, the line # may change in future versions). The initialization code looks for files named config.mk under $(NDK_ROOT)/toolchains/*. So you'll need to add your toolchain in a subdirectory under the NDK toolchains directory, and add a config.mk and setup.mk to that subdirectory. Look at toolchains/x86-4.4.3 and toolchains/arm-linux-androideabi-4.4.3 for examples. You should be able to cut and paste the ARM toolchain config.mk and setup.mk if your toolchain has a standard layout.
Once you've defined a toolchain in the toolchain directory, you can switch to it by setting the NDK_TOOLCHAIN variable inside your Application.mk file.
As the other answer mentions, toolchains are discovered by ndk-build makefile system in $(NDK_ROOT)/toolchains/ and you can mirror ideas you see there. But there are a few extra concepts for supporting non-Android target platforms that are interesting although they may be soon outdated as ndk-build starts to explicitly support other platforms, such as mingw targeting win32 (or other gcc compilers targeting plain 'ol linux).
In config.mk:
TOOLCHAIN_ABIS := (list of ABIs that the toolchain supports)
This is an important definition, because you can use this name in your Application.mk to build using the toolchain for a particular ABI. One of the benefits of corrupting the usage of this definition, is that ndk-build can simultaneously build for multiple ABIs. It always assumes that the platform is Android, but if you want to target win32 using a mingw based toolchain, you can define an "ABI" as x86-win32, and then use this ABI in your Application.mk to select it as an additional target via APP_ABI:= x86-win32 Then in your Android.mk files you can use the TARGET_ARCH_ABI definition to select win32 specific sources and include paths, for example:
ifeq ($(TARGET_ARCH_ABI),x86-win32)
LOCAL_SRC_FILES += my_win32_file.c
LOCAL_CFLAGS += -DSOME_WIN32_SPECIFIC
endif
The final piece is that in setup.mk for your toolchain, it may be insufficient to look at other toolchains as examples, because what setup.mk for a particular toolchain really does is override build settings in default-build-commands.mk, so what you want to do is inspect that file, and redefine things in it that you don't like.
Following the previous example, mingw does not support the noexec flag in the binaries, and you can get rid of this feature by adding the following lines in your setup.mk:
# These flags are used to enforce the NX (no execute) security feature in the
# generated machine code. This adds a special section to the generated shared
# libraries that instruct the Linux kernel to disable code execution from
# the stack and the heap.
TARGET_NO_EXECUTE_CFLAGS := # our platform doesn't support this flag!
TARGET_NO_EXECUTE_LDFLAGS := # our platform doesn't support this flag!
# These flags disable the above security feature
TARGET_DISABLE_NO_EXECUTE_CFLAGS := # our platform doesn't support this flag!
TARGET_DISABLE_NO_EXECUTE_LDFLAGS := # our platform doesn't support this flag!
This is just one example of the many features in default-build-commands.mk that may need to be overridden, and of course it's important to provide TOOLCHAIN_NAME so that the toolchain can be selected via NDK_TOOLCHAIN variable inside your Application.mk file in addition to the ABI methodology I mention above.
well，you can simply add "NDK_TOOLCHAIN_VERSION = 4.9" in your Application.mk