The thing that I am trying to do is to use the android's openssl libraries so I would like to add the library at some other embedded applications and just keep the data encrypted. I tried this things on the cyanogen 7.1 platform by just adding:
LOCAL_C_INCLUDES += /external/openssl/include
LOCAL_SHARED_LIBRARIES += libssl libcrypto
in the Android.mk file of the current project and I was able to use all functions with a simple #include in the particular .c file.
Alas, all this does not work just as straightforward on cyanogen 9 and I am looking for some help. Could you please tell me if there is something changed in the build system or something else that I need to do?
For example I have errors of this kind:
undefined reference to EVP_get_cipherbyname'
undefined reference toOPENSSL_add_all_algorithms_noconf'.
I would just like to repeat that I port all the code and all the things that I did on cyanogen 7 (and worked flawlessly) to cyanogen 9 and I can not build the platform. I am sure that I have all the includes and everything is fine with the .h files. In my opinion, it is just the linking of the libraries that possibly could cause the problem.
Any help is greatly appreciated.
It seemed that you need to add both the C includes and the libssl and libcrypto libraries in all 3 implementations of the sqlite located in the Android.mk file. That would be one implementation of the sqlite used by the android applications, and two sqlite implementations that are generated in the android platform.
Related
I have an Android Studio project that uses NDK
and I can't get include paths to work.
let say I have app/src/main/jni/foo/bar/file.c
and it includes "my/lib/inc.h"
When I add
LOCAL_C_INCLUDES += /home/user/include/ (to app/src/main/jni/Android.mk)
where the folder "my" is located I still get file not found from ndk-build
If I add "my" to app/src/main/jni it works fine.
What am I missing?
Android studio is probably ignoring your Android.mk and generating its own.
At the present instant in time, the NDK isn't well supported by Android Studio, and although you will find various version-specific gradle rule modifications which have apparently worked for their authors, it may be easier build the NDK code yourself and merely let the packaging stage pickup the results.
I have code I compiled already, and wonder if I can use the resulting executable, which is in elf format as a library in an APK and how please.
#Gabe Sechan; thanks. I did build a JNI project. I am having some issues importing the code from my other project into JNI. I wonder if you can suggest the best way to import it. I can post my Android.mk file if you like. Basically, it seems that project finds the first file, and an associated header file. That file, in turn uses variables, which are defined in another file. But there is no include statement.
You know? I figured if I can use a JAR file as a library, perhaps I could use an executable also. I need to learn more.
# Chris Straton - Thanks. I did edit my post with a comment to address the toolchain issue. But then, I modified it. Regardless, What I stated was if I use the toolchain that is recommended by my target platform, then I should be able to run it on my phone right?
Further; I re-read your comment about ABI and libc compatibility. The two devices are tegra t132 and Samsung S-N900P. So libc should not be an issue since both devices run Android; right? As far as I know both have an arm chip. Is there anything else I need to look into?
Elf is an executable, not a library. What you want to do is get a .so file and link to it via JNI.
You could possibly run it as a command line program and interact with it via its stdin and stdout, but that would be clunky when you can just use it as an actual library.
I am building an Android native application that uses OpenAL Soft for Android. Everything builds nicely, resulting in two shared libraries in my libs folder: libdig.so (mine) and libopenal.so (the OpenAL library).
When I try to load libdig.so on the device (using System.loadLibrary( "dig" );), however, the link fails with the message:
java.lang.UnsatisfiedLinkError: dlopen failed: could not load library "libopenal.so.1" needed by "libdig.so"; caused by library "libopenal.so.1" not found
Now in some sense the problem is obvious. dlopen is looking for a dependency named libopenal.so.1, but the file actually on the system (copied there by ant install) is libopenal.so: with no .1.
In other words, the libopenal.so library is called just that everywhere, except that somehow, internally, libdig.so references it as libopenal.so.1.
Also relevant: When building libopenal, the actual shared library name is libopenal.so.1.13.0, with two symlinks: libopenal.so.1 and libopenal.so. But nowhere is the .1 version referenced: not in Application.mk, or Android.mk, not in the output libs/, or anywhere else.
Android.mk links the libraries thus:
include $(CLEAR_VARS)
LOCAL_MODULE := openal
LOCAL_SRC_FILES := ../../../Fresh/lib/openal-soft-android-master/libs/$(TARGET_ARCH_ABI)/libopenal.so
LOCAL_EXPORT_C_INCLUDES := $(BASE_PATH)/Fresh/lib/openal-soft-android-master/include
include $(PREBUILT_SHARED_LIBRARY)
...
LOCAL_SHARED_LIBRARIES += openal
Now, what is interesting is that if I literally delete the libopenal.so.1 symlink from my system, ndk-build will fail, complaining:
No rule to make target `openal-soft-android-master/libs/armeabi-v7a/libopenal.so', needed by `obj/local/armeabi-v7a/libopenal.so'.
This implies that internally, ndk-build is trying to reference the .1 symlink, even though it's never named and the output file will be libopenal.so.
I am not familiar enough with UNIX or Android development to really understand the purpose of the .1 symlink, so I don't know why there would be this secret reference to that file.
Has anyone encountered this problem? Or do you understand something deeper down about the compilation or management of shared libraries that would explain why libdig.so is referencing a (slightly) wrongly-named library, or how to change it?
I know this question is a couple of years old, but I recently ran into the exact same problem while re-porting my game to Android. This problem frustrated me, and I even tried Alex's link above, only to find I had the same problem. After spending days researching this problem, I came to the following conclusion based on a similar problem someone else had in a forum. The .1 at the end is generally a sign of either using a library that was not built for your target platform (in this case, Android, obviously) or an incorrectly built library altogether.
If you want a quick fix to get around this (without statically compiling OpenAL-Soft into your app while forcing your entire project to be subject to the LGPL), you can simply download some prebuilt libraries from SFML's github page here... that's what I did anyway. You don't have to replace the .a files if you don't need to. Builds for arm, armv7, x86 and mips are in their respective folders.
Hope this helps either the OP or someone else in the future.
The easiest way out would be to use the static library for OpenAL. You can find the prebuilt static libraries in the same ZIP file as the shared libraries.
using openal-soft distrib or git
edit openal-soft/build/CMakeFiles/openal.dir/link.txt
remove '-Wl,-soname,libopenal.so.1'
and rebuild the lib
I've looked thru a lot of material on Android NDK and STLport. I have complex app, java+native code, which loads STLport (a c++ standard library port). The original codebase had "APP_STL := stlport_static" in the Application.mk in the project's "jni" subdir. Causes ld to load the lib static. This caused many compile failures, in current SDK/NDK.
Tried to load as a dynamic lib, as per a suggestion. (In "../jni/Application.mk", set "APP_STL := stlport_shared") With this, I get a clean compile, and load, and the app runs flawlessly on the Android armeabi-v7a emulator, if I disable checkJNI on the "dalvik" virtual machine.
But once I enable checkJNI, I get an "unsatisfiedLinkError" on the libapplication.so, which looks like it might result from STLport being dynamically loaded. So, I want to load STLport in static mode (logcat reports this after several other libs successfully loaded). During the build, compile is ok, but I am getting two multiple definition errors, specifically: "multiple definition of 'vtable for std::bad_exception' " and of 'std::exception::~exception()'. (I have also tried using "gnustl_static").
I am using gcc version 4.3.0 and make version 3.81, command line mode, and small wrapper around build-ndk, for android ndk-r9c, with a build target version of android-8, "ant" to build the .apk file, and so on.
Someone who has more familiarity with Android than me (I am a complete noob) might have seen this before. If so, please advise. Thanx. - Rus
It's definitely possible to use stlport_static with NDK r9c. What object files are mentioned with multiple definition errors? Maybe, you are using some prebuilt libraries? Maybe, the gcc version 4.3 is problematic? Why don't you use the default (gcc 4.8)?
With that, the NDK document explicitly encourages use of shared STL, but you must not forget to call System.loadLibrary() in correct order:
System.loadLibrary("stlport_shared");
System.loadLibrary("Rusfuture");
My Android application (game) uses native C++ code for certain operations. That is, I use the Android NDK. The native C++ code is compiled for armeabi only (to the default, armeabi-v5).
The last time I built my c++ code into nativestuff.so was a few months ago, in another computer (Windows 7 + cygwin, because cygwin is recommended for compiling with Android NDK).
I just installed the NDK on my current PC (Windows 7), along with the newest cygwin, and rebuilt the c++ code for my app.
To my surprise, it generates an .so file of 14KB, while the previous .so file was 37KB. Note that the c++ source files are exactly the same (they haven't changed for a year), my project is under version control, so I'm 100% sure.
I tested the c++ functionality in the game, and it works exactly as before, without any bugs.
My C++ files use only cstring.h and jni.h as includes. My Android.mk is as follows:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := nativestuff
LOCAL_SRC_FILES := nativestuff.cpp
include $(BUILD_SHARED_LIBRARY)
Any idea why the drastic change in .so filesize?
(I added the linux tag as well to this question, because maybe it's a general thing so I want to make sure that linux gurus also check it.)
Run objdump -x file.so on both versions. This will list all the sections and their sizes. That should give you a clue as to where the problem lies. (i.e. is there a new .debug section that's 23KB long? Maybe debug mode got enabled.)
If your code sections are radically different, compare the output of objdump -d file.so. Maybe your compiler automatically inlined more code, which saved a lot of space.
If another section is new/different, post the output in another SO question.
Maybe the previous .so was generated with debugging information.
(compiled with gcc -g option)
You may try one thing: use the command size executable-name. That will give you size of the different areas of your executable code. If the previous build is available do the same to that. You may get an idea where the change is.