I have two Android projects, one is a shared library and one is my application's project. Both projects contain some Java and some native code. When I try and run my APK I receive the following error:
Error generating final archive: Found duplicate file for APK: lib/armeabi/libOEShared.so
My shared library is marked as a library project (Properties->Android->'Is Library') so that I am able to use it's Java code. This presumably copies libOEShared.so for me once.
In order to link my Applications native code with libOEShared I use the NDK Prebuilds feature. Here is my Android.mk:
#include shared library
include $(CLEAR_VARS)
LOCAL_MODULE := OEShared
LOCAL_SRC_FILES := ../../../Shared/OEShared/libs/armeabi/libOEShared.so
include $(PREBUILT_SHARED_LIBRARY)
#build App library
include $(CLEAR_VARS)
LOCAL_MODULE := OEApp
LOCAL_SRC_FILES := OEApp.cpp
LOCAL_LDLIBS := -llog -lGLESv2 -lz
LOCAL_SHARED_LIBRARIES := OEShared
include $(BUILD_SHARED_LIBRARY)
However, the NDK also copies libOEShared into my Application project's lib folder, resulting in two copies being present in the final APK.
How can I link my Application's native code to libOEShared without it being automatically duplicated?
Thank you for you time, this has caused me a lot of frustration so far.
Only linking is required here, instead of build. Linking can be done by using LOCAL_LD_LIBS flag. You can try this.
LOCAL_LDLIBS := -L$(LOCAL_PATH)/../../../Shared/OEShared/libs/$(TARGET_ARCH_ABI)/ \
-lOEShared
Related
I've been trying to perform some native library builds for my Android App. More specifically performing ndk-build, with the help of some prebuilt shared libraries. One of the modules (let's call it pyjni) depends on those prebuilt shared libraries. Therefore my Android.mk consists of two modules for the prebuilt and to-be-built libraries respectively, as recommended for android ndk development.
This is my Android.mk file for the App:
LOCAL_PATH := $(call my-dir)
TARGET_ARCH_ABI := armeabi-v7a
include $(CLEAR_VARS)
LOCAL_SRC_FILES := $(LOCAL_DIR)/libs/$(TARGET_ARCH_ABI)/libprebuilt.so
LOCAL_MODULE := prebuilt
include $(PREBUILT_SHARED_LIBRARY)
# Build libpyjni.so
include $(CLEAR_VARS)
LOCAL_MODULE := pyjni
LOCAL_SRC_FILES := pyjni.c
LOCAL_C_INCLUDES:= $(LOCAL_DIR)/include/$(TARGET_ARCH_ABI)/
LOCAL_SHARED_LIBRARIES := prebuilt
LOCAL_LDLIBS += -llog
include $(BUILD_SHARED_LIBRARY)
Build turns out fine. In fact, when examining the .APK both the pre-built and built shared libraries are packaged inside # lib/armeabi-v7a. So far so good.
However, when trying to load the built shared library as System.loadLibrary("pyjni") during the App execution, it crashes notifying the following error:
java.lang.UnsatisfiedLinkError: dlopen failed: library ".../app/build/intermediates/ndkBuild/debug/obj/local/armeabi-v7a/libprebuilt.so" not found.
I can succesfully load the prebuilt library using System.loadLibrary("prebuilt"). So at this point I suspect it is an issue on how the prebuilt shared library is being packaged or rather how LOCAL_SHARED_LIBRARIES is working. In the app's build.gradle file the sourceSets.main.jniLibs.srcDirs points to the directory where libprebuilt.so is placed. To avoid packaging issues with multiple instances of the prebuilt library file, the gradle file specifies
packagingOptions{
pickFirst 'lib/armeabi-v7a/libprebuilt.so'
}
At this point I'm confused with how the link created by LOCAL_SHARED_LIBRARIES is working on execution.
I am trying to use ceres solver with my android application, and there does not seem to be a lot of documentation about using them both together properly. I have followed the build instructions from the ceres solver website, as well as this helpful tutorial:
http://tech.sandyeggi.com/2013/10/using-ceres-solver-in-android-ndk.html
This has gotten me far and everything is linked properly, but when I try to compile the project I get an odd error:
/Users/Steven/Documents/ceres-solver-1.10.0/include/ceres/internal/port.h:39:35: fatal error: ceres/internal/config.h: No such file or directory
Sure enough that file does not exist. But the question is why? Is it something that is supposed to be auto-generated? or created my self?
I might be important, so here is my Android.mk:
LOCAL_PATH := $(call my-dir)
LOCAL_ALLOW_UNDEFINED_SYMBOLS := true
include $(CLEAR_VARS)
LOCAL_MODULE := ceres
LOCAL_SRC_FILES := libceres.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_C_INCLUDES += /Users/Steven/Documents/android-ndk-r10d/sources/cxx-stl/stlport/stlport
LOCAL_C_INCLUDES += /Users/Steven/Documents/eigen-eigen-36fd1ba04c12/eigen-eigen-36fd1ba04c12
LOCAL_C_INCLUDES += /Users/Steven/Documents/ceres-solver-1.10.0/include
LOCAL_C_INCLUDES += /Users/Steven/Documents/ceres-solver-1.10.0/internal/ceres/miniglog
LOCAL_MODULE := DrinkMateDeveloper
LOCAL_SRC_FILES := DrinkMateDeveloper.cpp
LOCAL_STATIC_LIBRARIES = ceres
include $(BUILD_SHARED_LIBRARY)
Questions like this are best asked on the ceres-solver mailinglist.
The config.h you are looking for exists in
ceres-solver-1.10.0/config/ceres/internal/config.h
as the documentation in that file indicates
Default (empty) configuration options for Ceres.
IMPORTANT: Most users of Ceres will not use this file, when compiling Ceres
with CMake, CMake will configure a new config.h with the currently
selected Ceres compile options and copy it into the source
directory before compilation. However, for some users of Ceres
who compile without CMake, this file ensures that Ceres will
compile, with the user either specifying manually the Ceres
compile options, or passing them directly through the compiler.
you are going to have to do your own compiler defines for the various variables that are defined in
https://ceres-solver.googlesource.com/ceres-solver/+/master/cmake/config.h.in?autodive=0%2F
I have an Android project written in C++ and have a problem in linking phase. The code is put in some static libraries which should be linked together.
I have found a lot of questions and answers on the net about this topic and most of them suggest to put my libraries to LOCAL_STATIC_LIBRARIES in the Android.mk file. But, if I do this, I found the content of LOCAL_STATIC_LIBRARIES is simply ignored: my libraries are not linked, and adding any dummy text here does not generate any error or warning message.
I tried it this way:
LOCAL_STATIC_LIBRARIES := MyLib.a
or with full path:
LOCAL_STATIC_LIBRARIES := $(LOCAL_PATH)/MyLib.a
none of them worked.
If I put my static libraries to LOCAL_LDLIBS then it is linked, but I got a warning message about non-system libraries are used, and probably the build will be wrong.
The content of my Android.mk file is:
LOCAL_LDLIBS := $(LOCAL_PATH)/MyLib.a ...
and I got this message:
Android NDK: WARNING:jni/Android.mk:myapp: non-system libraries in linker flags: jni/MyLib.a
Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK: current module
I could not find how to use LOCAL_STATIC_LIBRARIES right way, please help me!
I have android-ndk-r9 and android-sdk_r22.2.1 on a OpenSuSE x86 and using target=android-18
See JBL's answer here.
The LOCAL_STATIC_LIBRARIES variable does not work that way. First you need a section that defines the library you want to include:
include $(CLEAR_VARS)
LOCAL_PATH = .
LOCAL_MODULE := curl
LOCAL_EXPORT_C_INCLUDES := ../curl/include
LOCAL_SRC_FILES := ../curl/lib/libcurl.a
include $(PREBUILT_STATIC_LIBRARY)
THEN, you can include it using
include $(CLEAR_VARS)
LOCAL_MODULE = mylib
CFLAGS = ...
...
LOCAL_STATIC_LIBRARIES = curl
include $(BUILD_STATIC_LIBRARY)
Most probably the problem lies in that you are giving the extension of the library:
LOCAL_STATIC_LIBRARIES := MyLib.a
I think, it should be written as:
LOCAL_STATIC_LIBRARIES := MyLib
I've been stuck here for a week trying to build a 3rd party .so library along with my app into custom Android system. I followed http://www.maxters.net/2012/05/adding-prebuilt-shared-library-to-android-build-system/ and successfully add the .so lib as prebuilt shared library to Android Build System. Now I can see the .so lib at ../out/target/product/crespo4g/obj/lib/.
But the libraries in this directory are not going to be migrated to device when flashing. And my .so lib is not appeared at /data/data/my_app_name/lib either. So UnsatisfiedLinkError occurs when executing System.loadLibrary().
I thought there are three ways to solve this, but just don't know how to implement:
Maybe my app failed to indicate to compiler that my .so is along with my app as a whole, so the .so lib is not compiled into the system image with my app. But I did declare by "LOCAL_STATIC_LIBRARIES := libXX", anything wrong?
Is there a way to build my .so lib into /system/lib/? Where are the so libs under /system/lib/ derived from?
I am new to Android building, please help..
Thanks!
You might want to check you makefile against advice in this answer and this one as well as the advice in this groups thread
UPDATE
My original makefile was incorrect but this does work for me building ICS:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libmozglue
LOCAL_SRC_FILES := libmozglue.so
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_TAGS := optional
include $(BUILD_PREBUILT)
include $(CLEAR_VARS)
LOCAL_MODULE := libplugin-container
LOCAL_SRC_FILES := libplugin-container.so
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_TAGS := optional
include $(BUILD_PREBUILT)
where the above are the native libraries required by firefox for android that I include as a system app in my custom system build.
I have a program I am porting that links together multiple libraries when creating the executable. I have built all those libraries using the stand alone toolchain and using the standalone toolchain I am able to create an executable that works on an android device. So, it seems like the libraries I have built are functional. Now I am trying to incorporate those libraries with an app. So, in my android.mk I have something like this:
LOCAL_PATH := $(call my-dir)
ROOT_PATH := $(LOCAL_PATH)
include $(call all-subdir-makefiles)
include $(CLEAR_VARS)
LOCAL_PATH = $(ROOT_PATH)
LOCAL_MODULE := test-libs
LOCAL_STATIC_LIBRARIES := staticA
LOCAL_SHARED_LIBRARIES := sharedA sharedB sharedC sharedD
LOCAL_SRC_FILES := test-libs.c
include $(BUILD_SHARED_LIBRARY)
For each of the libraries, I have a Android.mk like this
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := sharedA
LOCAL_SRC_FILES := sharedA.so
include $(PREBUILT_SHARED_LIBRARY)
When I then build my project (in eclipse), I get this:
C:/ndk/android-ndk-r7b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.4.3/libgcc.a(unwind-arm.o): In function `__gnu_unwind_pr_common':
/cygdrive/c/ndk/android-ndk-r7b/build/core/build-binary.mk:314: recipe for target `obj/local/armeabi/libtest-libs.so' failed
/tmp/ndk-digit/src/build/../gcc/gcc-4.4.3/libgcc/../gcc/config/arm/unwind-arm.c:1237: undefined reference to `__cxa_call_unexpected'
Any thoughts on what is going wrong?
Also, the static library and one of the shared libraries have no dependencies on anything and if I only include them all is cool. One of my shared libraries only had a dependency on the static library. If I only include those, but when I include the others, which have dependencies on other shared libraries, this problem occurs.
Update 1: Ok it appears to be because the APP_STL setting in my Application.mk was being ignored. All I have in my Application.mk is:
APP_STL := gnustl_shared
If I copy over the libgnustl_shared.so and treat it like another prebuilt shared lib, my problem is gone. Any idea why the APP_STL is not working properly. Note, I could have screwed something up. I just upgraded to using 7b. Using gnustl_shared used to work for me with other apps. Rolling back to 7 doesn't fix it. I think I have messed something up in Eclipse. I use Eclipse (windows) with sequoyah.
It looks like the linker is giving you an error. What you should do is the following:
Add a LOCAL_LDLIBS under your LOCAL_MODULE := test-libs. Here you need to include all the libraries you link against when you compile your pre-compiled libraries. So for example:
LOCAL_LDLIBS := -lgnustl_shared -lgcc -llog -landroid -lstdc++
Basically you need to identify what library contains the function __cxa_call_unexpected. A quick google shows that it's probably in libstdc++. Make sure that you also link with this library when creating your pre-compiled libraries.
I'm thinking it might have something to do with exceptions support.
Are you using exceptions in your code and if so are you compiling with a runtime library that supports exceptions? (and compiling with exceptions on)?.
There is more on this in the CPLUSPLUS-SUPPORT and STANDALONE-TOOLCHAIN files in the ndk docs.
I've observed a similar problem when one of my projects which contains only C source files (*.c) references another project that contains a c++ file(*.cpp). Application.mk files for both projects had APP_STL := gnustl_shared in them. The ndk version is ndk7e.
The solution was adding an empty C++ file (dummy.cpp) to the project that contained only .c files. Supposedly ndk understood that this project should be linked against the gnustl_shared and the build succeeded.