My problem is the following: I have succesfully built GDAL 1.10.1 using an Android toolchain (CC=i686-linux-android-gcc, CXX=i686-linux-android-c++) that produces the following output libraries libgdal.a, libgdal.la, libgdal.lai, libgdal.so, libgdal.so.1, libgdal.so.1.17.1 in the output folder .libs (in the following I'll call this folder $GDAL_LIB_PATH).
I am trying to build a simple Android app (a simple widget application with a QPushButton named TestAndroid) using Qt 5.4 on Windows. If I don't use GDAL everything works fine and I am able to run my app on an Android emulator for all available platforms: x86, armeabi and armeabi-v7.
Nonetheless, if I try to use GDAL (ex. by simply calling GDALAllRegister() in the initialization of the app) and then linking to libgdal.so the application crashes with the following error:
E/art ( 1614):
dlopen("/data/app/org.qtproject.example.TestAndroid-1/lib/x86/libTestAndroid.so",
RTLD_LAZY) failed: dlopen failed: could not load library
"libgdal.so.1" needed by "libTestAndroid.so"; caused by library
"libgdal.so.1" not found
I have verified that the Android platform is the right one (x86), otherwise the linker would skip the wrong libgdal.so object.
I have included libgdal.so in the *.apk (generated by Qt) using ANDROID_EXTRA_LIBS *= $GDAL_LIB_PATH/libgdal.so. The other files libgdal.so.x.x cannot be included in the same way since Qt prevents it.
In order to avoid dynamic linking I have also tried to link my app with libgdal.a but many link-time errors appears (ex. undefined reference to 'atof')
I have searched on the web but I have not found a solution to my problem.
I am not constrained to use dynamic linking so, a solution to any of the following problems is good for me:
Is there a way to avoid the creation of libgdal.so.x.x files when building GDAL ?
Is there a way to include libgdal.so.x.x files in the *.apk file generated by Qt ?
How can I avoid link-time errors when linking the static library libgdal.a ?
Thanks in advance for any reply!
After several days of trials and errors (mainly errors) I have found a solution to my problem.
I'm writing it as an answer to my question so that it may be helpful to others.
The problem was during the link-time of GDAL. Briefly: the linker created the "real name" shared library libgdal.so.1.17.1 together with the links to it libgdal.so.1 and libgdal.so.
For some reasons (which I ignore) forcing the link to libgdal.so, the linker searches for libgdal.so.1 (which, in turn, would have searched for libgdal.so.1.17.1).
The workaround that solved my problem can be summarized in the following steps:
In the GDAL root, run the ./configure according to the desired configuration (see http://trac.osgeo.org/gdal/wiki/BuildingForAndroid) checking that libtool is ENABLED
Edit the created libtool file (e. g. with gedit) as follows:
replace the value of library_names_spec with library_names_spec="\$libname\${shared_ext}"
replace the value of soname_spec with soname_spec=""
Type make
In the output folder .libs/ the only libgdal.so will be created and now the link to libgdal.so seems to work fine.
Related
I'm trying to load shared libraries in Unity. It works on Windows/Editor but not on Android, whatever I do or use for libraries I always get the DllNotFoundException.
I am using lib.so files, those are for 32BIT ARM EABIS, so the cross platform compilation seems to succeed.
my lib.so files are in the Assets/Plugins/Android/libs/armeabis-v7a/ folder.
I tried different syntax for DllImport (assuming the lib is called Plugin, and the files Plugin.dll and libPlugin.so) :
[DllImport("Plugin")] => works for Windows only
[DllImport("libPlugin.so")] => obviously wont work for Windows, but doesn't work for Android either.
If I open the .apk with winrar, libs are in the libs/armeabis-v7a folder.
The smartphone I use for my tests is an OnPlus3 with a armv8 processor.
Anyone managed to sucessfuly load a shared native library on Android ? Any ideas about what I'm doing wrong ?
Thank you
EDIT:
plugin code can be found here : https://github.com/FFmpeg/FFmpeg
C# code can be found here : https://github.com/Ruslan-B/FFmpeg.AutoGen/blob/7e001dde3acaad70ed188b75e686f23574f81388/FFmpeg.AutoGen/FFmpegInvoke.cs
Adding FFmpegInvoke.cs in the Unity Project or generating the FFmpeg.Autogen.dll and adding it to the project gives the same result (dll just makes the Unity Project faster to build).
I noticed few things you are doing wrong:
my lib.so files are in the Asset/Plugins/libs/armeabis-v7a/ folder.
That should be at:
Assets/Plugins/Android/libs/armeabi-v7a
If you have the x86 architecture version of the plugin,you should place them at:
Assets/Plugins/Android/libs/x86
I tried different syntax for DllImport (assuming the lib is called
Plugin, and the files Plugin.dll and libPlugin.so) :
None of those are correct. If the plugin file name is "libPlugin.so", you should use "Plugin" as the name.
Do not include the lib prefix.
Do not include the ".so" postfix.
Again, if the plugin name is "libVideoPlayer.so", you have to use "VideoPlayer". The "lib" and ".so" are removed. Nothing else will work.
One final note for you, for Android C++ plugin, you do not need to export the plugin. For example, DLLExport __declspec(dllexport) is not necessary.
Although, you must put the function name inside "extern "C""
I'm running the latest build of android studio. Trying to make a project compilable and running utilizing the power of this https://github.com/tpruvot/cpuminer-multi/ c++ stuff. What I've tried so far is create new project with c++ support - it creates the corresponding project structure. It also includes CPP file that is called from the main activity. Now let's say I want all this aforementioned miner code to be there as well - I’ve tried just copy-pasting it into the cpp folder. What are my next steps? Calling ndk-build against $ProjectFileDir$\app\src\main directory just fails with an error Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk . Same goes if I try to import an existing project like https://github.com/mdelling/cpuminer-android - first of all I’m trying to do and ndk-build, but it just fails saying that it treats warning like errors so all the cpp/h functions remain inaccessible and are not packed into resulting apk. If I try to install the resulting apk it just crashed on the start. So for the first case – how can I like all the cpp sources to the app, and for the second – how can I make it work at all?
First of all, the crash is probably because your Java code is trying to load the c++ shared library and fails, because the library was not built due to the NDK errors. So take care of the errors first.
Second, did you configure your Android.mk properly? Have a look here, for example (it is for Eclipse and not Android Studio, but the mk file is the same): Getting started with Android NDK. Looking at an existing simple project can also help: hello-jni.
I get this in logcat when trying to load a library compiled only for armeabi (assuming that it is the fallback for all arm* abis).
08-14 09:43:51.516 7486-7486/package_name E/art﹕ dlopen("/data/app/package_name-1/lib/arm/libLibrary.so", RTLD_LAZY) failed: dlopen failed: unknown reloc type 160 # 0xa3725ab4 (82108)
Due to practical constraints, I cannot test this on a rooted device, so all I know is that the /data/data/package_name folder has a symlink lib -> /data/app/package_name-1/lib/arm
I know that this is not a device specific problem, since I have used native libraries earlier on the same device (with a different app, but same architecture earlier).
Can someone help me out here? Really confused on what exactly is happening.
I use gradle build (Android Studio), and the libLibrary.so is present inside the lib/armeabi folder within the apk on unzipping it.
The question was only partially correct. The true problem was with the relocation type (of which I had no idea initially).
Relocation errors usually occur when the loader and the object file do not understand the same format.
In this case, the .so file was built with c++_static instead of gnustl_static. Android/NDK provides most c++11 functionality, but some of them are not fully operational/functional like std::to_string which led me to try c++_static.
Hope this helps someone else out there who still has hairs left on his/her head.
Hi I am trying to port an OpenGL desktop app to android. I have no knowledge of android development so am depending on Qt Creator to package the app. As part of the setup, I have invoked 'make-standalone-toolchain' script in android ndk with following settings
--platform=android-21
--toolchain=arm-linux-androideabi-4.9
--system=linux-x86_64
Then I used android-cmake and passed it the path of my newly created standalone-toolchain, which created libassimp.so, libassimp.so.3, and libassimp.so.3.1.1(ln) inside my assimp directory tree.
I passed the libassimp.so path to Qt creator project build menu under 'additional libraries'. However, on deploying the app on android, it crashes with error:
dlopen("/data/app/org.qtproject.example.a3dqtquick-2/lib/arm/lib3dqtquick.so", RTLD_LAZY) failed: dlopen failed: could not load library "libassimp.so.3" needed by "lib3dqtquick.so"; caused by library "libassimp.so.3" not found
I can even see the libassimp.so (not libassimp.so.3) file inside the project build directory at
../android-build/libs/armeabi-v7a.
Not sure where to go from here, manually placing libassimp.so.3 at this location does not sort out the problem. Thanks for reading. I will add further info on your feedback . please forgive any info deficiency as this is my first experiment with android.
Following is the deployment-settings.json file
"description": "This file is generated by qmake to be read by androiddeployqt and should not be modified by hand.",
"qt": "/home/ubashir/programs/Qt/5.4/android_armv7",
"sdk": "/home/ubashir/programs/android-sdk-linux",
"sdkBuildToolsRevision": "21.1.2",
"ndk": "/home/ubashir/programs/android-ndk-r10d",
"toolchain-prefix": "arm-linux-androideabi",
"tool-prefix": "arm-linux-androideabi",
"toolchain-version": "4.9",
"ndk-host": "linux-x86_64",
"target-architecture": "armeabi-v7a",
"qml-root-path": "/home/ubashir/code/3dqtquick",
"application-binary": "/home/ubashir/code/3dqtquickAndroid/lib3dqtquick.so"
UPDATE:
I have now tried this.. replace all links to assimp.so.3.1.1 with copies of the latter so now my library libassimp.so.3 is a file instead of link to libassimp.so.3.1.1. I manually added libassimp.so.3 to my project subfolder android/libs/aremabi-v71 --- no good. I confirm that my build directory shows all libassimp files as I manually added them so presumably they are being deployed but the error remains :
failed: dlopen failed: could not load library "libassimp.so.3" needed by "lib3dqtquick.so".
As outlined here http://webmail.dev411.com/p/gg/android-ndk/1386vger6e/use-assimp-c-library-in-ndk-ld-error-obj-local-armeabi-v7a-libassimp-so-incompatible-target-for-use-with-vuforia
I even edited the link.txt file after running cmake on my assimp build directory for android, altering the entry -soname,libassimp.so.3 with -soname,libassimp.so but it still creates libassimp.so.3.1.1 with its two links , i.e., libassimp.so.3 and libassimp.so. So still stuck..
I ran into the same problem with a shared library I built with CMake for and Android project. I found a way to fix it. There might be a cleaner solution if you were more familiar with CMake.
Search through the CMakeLists.txt file(s) for "SOVERSION" and "SET_TARGET_PROPERTIES()"
In the SET_TARGET_PROPERTIES() routine comment out the lines for VERSION and SOVERSION as follows
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES # create *nix style library versions + symbolic links
DEFINE_SYMBOL DSO_EXPORTS
# VERSION ${PROJECT_VERSION}
# SOVERSION ${PROJECT_SOVERSION}
CLEAN_DIRECT_OUTPUT 1 # allow creating static and shared libs without conflicts
OUTPUT_NAME "${PROJECT_NAME}${PROJECT_DLLVERSION}" # avoid conflicts between library and binary target names
)
Then rerun the configure and generate steps in CMake and rebuild the target. This should give you a .so without any version numbers.
I'll suggest you to take a look at the solution I've found to my problem (that is very similar to yours):
libgdal.so android error: could not load library "libgdal.so.1"
Hope this helps.
I want to make some changes to LatinIME. I got the code from git repository-
git clone https://android.googlesource.com/platform/packages/inputmethods/LatinIME
But I don't know how to build the apk file from the code. If anyone has build the LatinIME from the code, can you please share instructions.
Specifically I want to know how to build the dictionary tools (I guess I would need ndk), how to build the native code (again I guess it would required ndk) and finally how to build the java code by using the lib file from native code.
I tried creating Android app project in eclipse (using existing code option) by giving root directory as LatinIME/java I was able to compile but since it didn't have libjni_latinime.so, it crashed. I then got the .so file from emulator and put it in the libs/armeabi-v7a folder. Now I get this exception:
10-15 12:54:55.289: E/AndroidRuntime(32253): FATAL EXCEPTION: InitializeBinaryDictionary
10-15 12:54:55.289: E/AndroidRuntime(32253): android.content.res.Resources$NotFoundException: File res/raw/main_en.dict from drawable resource ID #0x7f070003
I think I may have solved this...
Having encountered a similar problem in another project where resources were being unnecessarily compressed due to their file extension I renamed the dictionaries (.dict) to .jet - an extension excluded from compression. Voila, dictionaries are now working. Not sure how good of a resolution that is seeing as the dictionaries are now uncompressed but it's a step in the right direction at least?
So far i have customised the LatinIME many times for different projects. I never faced this problem.
But i never used eclipse to create apks. I downloaded whole AOSP code onto my machine and compiled the modified source with AOSP. And mm creates the apk file in out folder, and can be installed with adb install -r latinime.apk
Here is how to download AOSP :http://source.android.com/source/downloading.html
And here is how to compile it initially : http://source.android.com/source/initializing.html and http://xda-university.com/as-a-developer/getting-started-building-android-from-source
And the LatinIME can be found in <android roo>/packages/inputmethods/LatinIME, Modify the code ther and cd to the same path and run mm (you need to do source build/envisetup.sh and lunch full-eng done in same terminal before doing mm)
First some background. As also suggested by the other answer issue seems to be related of .dict files being compressed. For example you can see how official Android builds solve this in project's tests for LatinIME
# Do not compress dictionary files to mmap dict data runtime
LOCAL_AAPT_FLAGS += -0 .dict
A quick searching the web reveals that to day this kind of directive or instructing aapt from Eclipse isn't trivial. You would probably end up creating a build.xml in case you want to handle don't-compress-dicts case properly.
One nice suggestion is this answer/question on how to instruct aapt to not to compress certain files.
If you want to build this from official git link you provide, you'll end up building whole Android repo, which you can by following building-running instructions.
If using gradle, add this
android {
aaptOptions {
noCompress 'dict'
}