Once the APK launches, I get this error:
E AndroidRuntime: java.lang.RuntimeException: Unable to start activity
ComponentInfo{com.engine001.test/android.app.NativeActivity}:
java.lang.IllegalArgumentException: Unable to load native library:
/data/app/com.myapp.test-2/lib/arm/libLauncher.so
Even the most basic NDK app seems to have this issue, even without linking to other .so. Using latest Tegra/NDK/etc... tools.
Entire system worked fine until I upgraded systems and updated tools.
EDIT: I have tried to install the previous version of the tools I had working (ndk r12b). I have also tried literally copying my old NVPACK and setting things back up to no avail.
I am not sure what to include. This is a very large project currently in use.
I cannot include actual Java code as I modify the APK after and this cannot be done if a DEX file is produced, which is what Java entails. So to be clear, using a pure NativeActivity.
Unable to load native library: /data/app/com.myapp.test-2/lib/arm/libLauncher.so
Newer NDK does not support this path anymore. You need to ensure that your ABIs are x86, x86_64, armeabi-v7a, arm64-v8a. i.e. paths should be something like below:
/data/app/com.myapp.test-2/lib/arm64-v8a/libLauncher.so
Related
I've an application which has 32 bit native libraries. When I'm reinstalling the same app with 64-bit libraries, It's unable to create lib softlink which is present in data/data/application-package-name.
This lib softlink maps to data/app/app-package-name-hash/arm(in 32bit) or data/app/app-package-name-hash/arm64(in 64bit)
What's the problem?
Android build system is unable to create lib softlink inside the data/data/app_package_name which maps to data/app/app-package-name-hash/arm(in 32bit) or data/app/app-package-name-hash/arm64(in 64bit)
What error are you seeing?
My native code isn’t able to find a file in the shared object which should be inside data/data/app_package_name/lib, hence giving unable to open file error
32-bit strucuture in data/data/application-package-name
64-bit strucuture in data/data/application-package-name
Project strucuture
Referenced:
https://stackoverflow.com/a/27523384/5047036
Yes, I had same issue with 64 bits: I've missed the (not needed) softlink to legacyNativeLibraryDir arm64 in data/data/application-package-name
In order to find the path for native libs (regardless of device architecture) you should use getContext().getApplicationInfo().nativeLibraryDir
Reference: https://developer.android.com/ndk/guides/abis#aen
I have an alljoyn library in my project to pair android devices for a voting app. In old devices the app runs properly but in new devices it stops when it is starting to run.
This is the error, I got:
Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: library "libcrypto.so" not found
at java.lang.Runtime.loadLibrary0(Runtime.java:1016)
at java.lang.System.loadLibrary(System.java:1657)
at com.example.nima.voting.alljoyn.peergroupmanager.PeerGroupManager.<clinit>(PeerGroupManager.java:60)
NOTE: I'm not an Android developer.
That said, I found this StackOverflow question, which mentions similar behavior to what you described:
The master Android process is zygote. Its like init in Linux. Zygote
loads OpenSSL when its start, and it loads version 0.9.8. If you link
against OpenSSL 1.0.1, then you will get mysterious runtime crashes.
The crashes are due to the Android loader using the 0.9.8 version of
the library (already mapped from Zygote), and not your version of
OpenSSL.
You can use a shared object, but your shared object must be a wrapper around the static version of libssl and libcrypto.
You mentioned that the app loads properly in old devices but crashes in new devices. If the new devices are linking against OpenSSL v1.0.1 and the old ones against v0.9.8, then this might be the root cause of your problem.
The solution seems to be either to compile against static libraries for libcrypto (and for libssl too, apparently), or to rename these dependencies after the build, then copy them into your precompiled directory (if I interpreted the answer in the link correctly):
The reason is that the system comes with its own (probably different)
version of these shared libraries, and the loader will use
/system/lib/libssl.so and /system/lib/libcrypto.so instead of your
private copies.
I'm trying to build an executable from a c file (not written by me) so that I can use it on my phone.
I'm using a toolchain directly from the Android NDK (that use Clang) built for arm64.
The c file needs, as expressed in the makefile, libpthread librtlsdr libmysqlclient, so I downloaded the arm64 versions of these libraries in my toolchain sysroot directory. First question: is this the right way of doing this?
Anyway, after doing this and executing make, it fails saying that it cannot find libpthread.so.0 and libpthread_nonshared.a.
To solve this I copy in the sysroot folder the file it wants from the libc6 arm 64 package (that are not only the two written above, but many others needed in cascade): this way the "make" seems to work fine but once I push it in my device, with the libraries it needs, and run it, I got a runtime error saying:
cannot find verneed/verdef for version index=32770 referenced by symbol "_res" at "/data/local/tmp/TEMP/libc6.so.6"
In this case the problem should be libc6, but I can't figure how to solve this.
This one is related to the libpthread I've downloaded, so the libc6 package, which is probably not suited for Android.
So the real problem is: is there a way to get rid of the first error I mentioned using just the pthread included in Android?
What I hope is that I'm just missing something or using in the wrong way.
Thanks
No, this is not how you are expected to build an executable for Android. You can either use the NDK toolchain, or an alternative toolchain, as described here: Cross compiling static C hello world for Android using arm-linux-gnueabi-gcc.
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.
I created another question because all of the others were answered with a solution that was similar but unrelated. I have also ensured that it's not a symbol stripping issue.
I'm getting the dreaded error:
D/AndroidRuntime(16487): Shutting down VM
W/dalvikvm(16487): threadid=1: thread exiting with uncaught exception (group=0x41b1b700)
E/AndroidRuntime(16487): FATAL EXCEPTION: main
E/AndroidRuntime(16487): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.test.test/android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to load native library: /data/app-lib/com.test.test-1/libtest.so
E/AndroidRuntime(16487): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2211)
E/AndroidRuntime(16487): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2261)
...
Everything compiles and links just fine.
I also have app_dummy() and it's producing it properly as when I run with objdump I get it:
001186f4 g DF .text 000001a4 ANativeActivity_onCreate
If it matters, using vs-android with toolchain 4.7.2, targeting 2.3.3 (android-10), for armv7-a. I have libraries that I include appropriately, and end up fully linking.
My one theory, which I'm still unable to prove, is that there are some .so files that I also need to include with the apk. I assumed that the external libraries (so) would be merged with my own. If this is not the case, this would likely explain the issue at hand.
I am not using any makefiles directly - vs-android is handling most of it. I only have access to some .xml and .property files.
It seems this error will come up ambiguously if there are dependant libraries that cannot be found. Since I'm using vs-android, I'm still unsure how to even get the external .so files to properly be included in the apk under the /libs/ path.
The only solution to include external .so files is to somehow get the libraries into your apk and link them manually within code, call System.loadLibrary() on the Java side before your native library gets loaded, or have one native library load the libraries and then launch your main library.