I recently checked out a project originally built under Windows (using JNI) in my Studio on Ubuntu
When I run a clean task, I see an error when it tries to execute what seems to be a Windows ndk-clean command
org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:UsersTishuAppDataLocalAndroidandroid-ndk-r8e-windows-x86_64android-ndk-r8endk-build.cmd
I am not sure what triggers this command but it happens on this task: 'externalNativeBuildCleanDebug'
I have searched in my project for references to 'AppData' and found few in this file: project/.externalNativeBuilds/ndkbuild/debug/mips/ndkBuild_build_commands.txt
This file contains windows related information, starting with
Executable : C:\Users\Tishu\AppData\Local\Android\android-ndk-r8e-windows-x86_64\android-ndk-r8e\ndk-build.cmd
Problem is I cannot find this file in Files or in Studio. The .externalNativeBuilds folder doesn't show. I have this is my build.gradle
externalNativeBuild {
ndkBuild {
path 'src/main/jni/Android.mk'
}
}
And the Android.mk file contains only
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_ALLOW_UNDEFINED_SYMBOLS=false
LOCAL_MODULE := jpgexif
LOCAL_SRC_FILES := JpgExif.c
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
include $(BUILD_SHARED_LIBRARY)
How do I disable this step, or update it to be relevant for my platform?
It sounds to me like either of these things have happened:
Someone checked the .externalNativeBuild directory into the repo, which they shouldn't have done. The build tools should generate that directory for you locally. If you can't see the directory in the file explorer, press Ctrl+H, or whatever the command is to show hidden files. Then delete the directory and trigger a gradle sync. Or just remove it from a terminal window.
Someone checked the local.properties file into the repo, and in it they set the ndk.dir property to a Windows path. Again, this file should probably not be part of your shared repository. If this is what happened you might be able to fix it by editing the file and specifying the correct NDK path for your machine, and then triggering a gradle sync.
I am getting this error: unable to lookup library path for, native render plugin support disabled when I run my app on android. I think I am building the shared libraries incorrectly.
I am looking to build the source files from this repo. I'll say my build process and perhaps someone can spot a step I'm missing or doing incorrect.
Following this guide, I came up with this:
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libhydrogen
LOCAL_SRC_FILES := ..\hydrogen.c
include $(BUILD_SHARED_LIBRARY)
Application.mk
APP_PLATFORM := android-16
APP_OPTIM := release
APP_MODULES := libhydrogen
Next I:
Placed these files in the jni folder.
Called ndk-build.
Copied the .so files from the \libs folder and placed them in their respective folders in Unity (i.e. Hydrogen\Plugins\Android\arm64-v8a).
Made sure their platforms and CPU architectures were correct.
Built my app.
Here is the c# wrapper I am using.
Calling Hydrogen.Library.Initialize(); is then giving me this error.
Here is the full logcat related to this error.
And in the case my build process manages to be correct, and the .so files are fine; what else might cause this to happen?
Edit: I am trying to build for armeabi-v7a and `x86. Here are the .so file details, maybe there is something there that is not right? I am unfamiliar with c and since I haven't heard of anyone building this library for android, I wonder: could there be anything within the c source file that is incompatible with the NDK build process?
Native libraries are loaded by the native linker of the system, in your case, the linux dynamic linker: ld.so (it changes names sometimes, so I used that name, as you can check the man page in the documentation with that name).
For that to happen, in general, you need to provide a LD_LIBRARY_PATH environment variable to the java virtual machine, so it can effectively dlopen(3) it.
Think how different can be your development system to your target one.... and you'll easily get to that.
It was a bug with Unity! For some reason when switching the project's target platform some of my files would get corrupted. Strangely, it only seems to happen in this one project, but in any case the (temporary) solution is to re-import the plugin folder whenever I switch platforms.
I want to use a existing native library from another Android project, so I just copied the NDK built library (libcalculate.so) to my new Android project. In my new Android project I created a folder libs/armeabi/ and put libcalculate.so there. There is no jni/ folder. My testing device has ARM architecture.
In my java code I load the library by:
static{
System.loadLibrary("calculate");
}
When I run my new android project, I got error:
java.lang.UnsatisfiedLinkError: ...
nativeLibraryDirectories=[/vendor/lib, /system/lib]]] couldn't find "libcalculate.so"
So, as error says, the copied native library is not in /verdor/lib or /system/lib , how to resolve this problem in my case?
(I unziped the apk package, under lib/ there is libcalculate.so)
====UPDATE=====
I also tried to create a jni/ folder under project root, and add an Android.mk file under jni/. The content of Android.mk is:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libcalculate
LOCAL_SRC_FILES := libcalculate.so
include $(PREBUILT_SHARED_LIBRARY)
Then, under project root, I executed ndk-build . After that, the armeabi/ and armeabi-v7a/ directories are generated by ndk-build (with libcalculate.so inside the folder).
Then I run my maven build the project successfully. In the final apk package, there are:
lib/armeabi/libcalculate.so
lib/armeabi-v7a/libcalculate.so
But when I run my app, the same error throw:
java.lang.UnsatisfiedLinkError: ...
nativeLibraryDirectories=[/vendor/lib, /system/lib]]] couldn't find "libcalculate.so"
To root cause (and maybe solve your issue in the same time), here is what you can do:
Remove the jni folder and all the .mk files. You don't need these nor the NDK if you aren't compiling anything.
Copy your libcalculate.so file inside <project>/libs/(armeabi|armeabi-v7a|x86|...) . When using Android Studio, it's <project>/app/src/main/jniLibs/(armeabi|armeabi-v7a|x86|...), but I see you're using eclipse.
Build your APK and open it as a zip file, to check that your libcalculate.so file is inside lib/(armeabi|armeabi-v7a|x86|...).
Remove and install your application
Run dumpsys package packages | grep yourpackagename to get the nativeLibraryPath or legacyNativeLibraryDir of your application.
Run ls on the nativeLibraryPath you had or on legacyNativeLibraryDir/armeabi, to check if your libcalculate.so is indeed there.
If it's there, check if it hasn't been altered from your original libcalculate.so file: is it compiled against the right architecture, does it contain the expected symbols, are there any missing dependencies. You can analyze libcalculate.so using readelf.
In order to check step 5-7, you can use my application instead of command lines and readelf: Native Libs Monitor
PS: It's easy to get confused on where .so files should be put or generated by default, here is a summary:
libs/CPU_ABI inside an eclipse project
jniLibs/CPU_ABI inside an Android Studio project
jni/CPU_ABI inside an AAR
lib/CPU_ABI inside the final APK
inside the app's nativeLibraryPath on a <5.0 device, and inside the app's legacyNativeLibraryDir/CPU_ARCH on a >=5.0 device.
Where CPU_ABI is any of: armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, mips, mips64. Depending on which architectures you're targeting and your libs have been compiled for.
Note also that libs aren't mixed between CPU_ABI directories: you need the full set of what you're using, a lib that is inside the armeabi folder will not be installed on a armeabi-v7a device if there are any libs inside the armeabi-v7a folder from the APK.
In gradle, after copying all files folders to libs/
jniLibs.srcDirs = ['libs']
Adding the above line to sourceSets in build.gradle file worked. Nothing else worked whatsoever.
In my case i must exclude compiling sources by gradle and set libs path
android {
...
sourceSets {
...
main.jni.srcDirs = []
main.jniLibs.srcDirs = ['libs']
}
....
The reason for this error is because there is a mismatch of the ABI between your app and the native library you linked against. Another words, your app and your .so is targeting different ABI.
if you create your app using latest Android Studio templates, its probably targeting the arm64-v8a but your .so may be targeting armeabi-v7a for example.
There is 2 way to solve this problem:
build your native libraries for each ABI your app support.
change your app to target older ABI that your .so built against.
Choice 2 is dirty but I think you probably have more interested in:
change your app's build.gradle
android {
defaultConfig {
...
ndk {
abiFilters 'armeabi-v7a'
}
}
}
Are you using gradle? If so put the .so file in <project>/src/main/jniLibs/armeabi/
I hope it helps.
For reference, I had this error message and the solution was that when you specify the library you miss the 'lib' off the front and the '.so' from the end.
So, if you have a file libmyfablib.so, you need to call:
System.loadLibrary("myfablib"); // this loads the file 'libmyfablib.so'
Having looked in the apk, installed/uninstalled and tried all kinds of complex solutions I couldn't see the simple problem that was right in front of my face!
This is an Android 8 update.
In earlier version of Android, to LoadLibrary native shared libraries (for access via JNI for example) I hard-wired my native code to iterate through a range of potential directory paths for the lib folder, based on the various apk installation/upgrade algorithms:
/data/data/<PackageName>/lib
/data/app-lib/<PackageName>-1/lib
/data/app-lib/<PackageName>-2/lib
/data/app/<PackageName>-1/lib
/data/app/<PackageName>-2/lib
This approach is hokey and will not work for Android 8; from https://developer.android.com/about/versions/oreo/android-8.0-changes.html
you'll see that as part of their "Security" changes you now need to use sourceDir:
"You can no longer assume that APKs reside in directories whose names end in -1 or -2. Apps should use sourceDir to get the directory, and not rely on the directory format directly."
Correction, sourceDir is not the way to find your native shared libraries; use something like. Tested for Android 4.4.4 --> 8.0
// Return Full path to the directory where native JNI libraries are stored.
private static String getNativeLibraryDir(Context context) {
ApplicationInfo appInfo = context.getApplicationInfo();
return appInfo.nativeLibraryDir;
}
Try to call your library after include PREBUILT_SHARED_LIBRARY section:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libcalculate
LOCAL_SRC_FILES := <PATH>/libcalculate.so
include $(PREBUILT_SHARED_LIBRARY)
#...
LOCAL_SHARED_LIBRARIES += libcalculate
Update:
If you will use this library in Java you need compile it as shared library
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libcalculate
LOCAL_SRC_FILES := <PATH>/libcalculate.so
include $(BUILD_SHARED_LIBRARY)
And you need deploy the library in the /vendor/lib directory.
You could just change ABI to use older builds:
defaultConfig {
...
ndk {
abiFilters 'armeabi-v7a'
}
...
}
You should also use deprecated NDK by adding this line to gradle.properties:
android.useDeprecatedNdk=true
actually, you can't just put a .so file in the /libs/armeabi/ and load it with System.loadLibrary. You need to create an Android.mk file and declare a prebuilt module where you specify your .so file as a source.
To do so, put your .so file and the Android.mk file in the jni folder.
Your Android.mk should look something like that:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libcalculate
LOCAL_SRC_FILES := libcalculate.so
include $(PREBUILT_SHARED_LIBRARY)
Source : Android NDK documentation about prebuilt
please add all suport
app/build.gradle
ndk {
moduleName "serial_port"
ldLibs "log", "z", "m"
abiFilters "arm64-v8a","armeabi", "armeabi-v7a", "x86","x86_64","mips","mips64"
}
app\src\jni\Application.mk
APP_ABI := arm64-v8a armeabi armeabi-v7a x86 x86_64 mips mips64
defaultConfig {
ndk {
abiFilters "armeabi-v7a", "x86", "armeabi", "mips"
}
}
Just add these line in build.gradle app level
In my experience, in an armeabi-v7a mobile, when both armeabi and armeabi-v7a directories are present in the apk, the .so files in armeabi directory won't be linked, although the .so files in armeabi WILL be linked in the same armeabi-v7a mobile, if armeabi-v7a is not present.
I am new to using an ndk and was trying to use some of the sample projects that came in the android ndk10d folder. For example the hello-jni sample project. I keep getting this error:
Error:Execution failed for task ':app:compileDebugNdk'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
C:\Users\Jonathon\android-ndk-r10d\ndk-build.cmd NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=C:\Users\Jonathon\AndroidStudioProjects\hello-jni2\app\build\intermediates\ndk\debug\Android.mk APP_PLATFORM=android-21 NDK_OUT=C:\Users\Jonathon\AndroidStudioProjects\hello-jni2\app\build\intermediates\ndk\debug\obj NDK_LIBS_OUT=C:\Users\Jonathon\AndroidStudioProjects\hello-jni2\app\build\intermediates\ndk\debug\lib APP_ABI=all
Error Code: 2 Output:
make.exe: *** No rule to make target `C:\Users\Jonathon\AndroidStudioProjects\hello-jni2\app\build\intermediates\ndk\debug\obj/local/arm64-v8a/objs/hello-jni/C_\Users\Jonathon\AndroidStudioProjects\hello-jni2\app\src\main\jni', needed by `C:\Users\Jonathon\AndroidStudioProjects\hello-jni2\app\build\intermediates\ndk\debug\obj/local/arm64-v8a/objs/hello-jni/C_\Users\Jonathon\AndroidStudioProjects\hello-jni2\app\src\main\jni\hello-jni.o'. Stop.
I have checked and the file: ndk-build.cmd is indeed in the location specified. When I try to open it command prompt says that it cannot find the application project directory. Please define the NDK_PROJECT_PATH variable to it
I re-installed and updated my whole environment from 0.8.9 to android studio 0.9.9 and now 1.01 and I get the same error. It seems it can't find the file or file directory and that must mean my configuration isn't right but I can't determine what to do to fix it.
local.properties
sdk.dir=C\:\\Users\\Jonathon\\AppData\\Local\\Android\\sdk
ndk.dir=C\:\\Users\\Jonathon\\android-ndk-r10d
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
Check out this video for building simple NDK projects with Android studio
https://www.youtube.com/watch?v=kFtxo7rr2HQ&list=UUkbLy9aj5IBXfS6WqLy5Qmw
Alternatively you can also download Intel Native Developer Experience tool that comes with the NDK plugin for Android Studio
You can remove the Android.mk file: it will be ignored as a new one is generated on the fly from your gradle configuration (build.gradle file). You can get more information on this from my article on NDK support in Android Studio.
The bug you're experiencing is this one: https://code.google.com/p/android/issues/detail?id=66937&
A simple workaround is to create a empty .c file next to hello-jni.c.
If you have only one .c (or .cpp) file add a dummy .c (or .cpp) file and it works.
I have an Android NDK project that builds fine in cygwin using ndk-build.
However, I wanted to have it build in eclipse, so I installed C/C++ Development tools into my ADT version of eclipse and added native support to the project in eclipse. However, after building, I get the following error:
fatal error: timer.h: No such file or directory
In my original Android.mk file, I have the following include that lets it work in cygwin:
LOCAL_C_INCLUDES := /cygdrive/c/ADT/includes/
I tried adding a similar include path (C:\ADT\includes) to Project->Properties->C/C++ General->Paths and Symbols, but still no luck. Any suggestions?
The fix was to use windows paths
LOCAL_C_INCLUDES := C:/ADT/includes/
Note that using the following works as well (per cpu2's answer)
LOCAL_CFLAGS := -IC:/ADT/includes/
Add -I/path/to/includes to your cflags.