Is there any way to determine what version of the NDK was used to compile an "aar" library? Either decompiling, or via code would be fine, just need to know.
I am trying to determine what version of the ndk one of my third party libraries was built using.
An "aar" file is not compiled with NDK, you probably mean one of the c++ libraries inside that file. There is no simple way, but you can rule out new ndk versions according to the library date.
Also, you might be able to find out by getting the compiler version - see if something like this can help: How to retrieve the GCC version used to compile a given ELF executable
Related
I have an Android project with lots of so files which are built by third party. I wonder if it is OK when they build these so files by different ndk versions. And how does android device know which ndk version should be used to run these so files?
The NDK version only determines which header files are available at compile time (eg "asset_manager.h").
These header files in turn define some required functions ("AAssetManager_openDir"), which -- if you use them -- will result in dynamic symbol dependencies in your final library.
A device with a given Android version contains libraries with all the dynamic symbols for the versions up to that NDK version.
So to answer your first question: it does not matter, everything should just work.
Suppose I have prebuilt OpenCV Android native libraries, such as this. How to find which version of NDK is used for building this?
I am curios about this because OpenCV 3.4.3 prebuilt Android libraries seems to incompatible (?) with NDK r18.
OpenCV library contained this information. Open the prebuilt library in Notepad++ and search for "General configuration for OpenCV".
Assuming it was built with a new enough version of the NDK (I don't remember exactly when we added this, but it's been a year or two), there's an ELF note baked into the binaries. Can use https://android.googlesource.com/platform/ndk/+/master/parse_elfnote.py to parse it. It'll show you something like the following:
$ python parse_elfnote.py $NDK/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++_shared.so
----------ABI INFO----------
ABI_ANDROID_API: 21
ABI_NDK_VERSION: r18
ABI_NDK_BUILD_NUMBER: 5002713
I've been working on an Android project which has several native C++ libraries. Compiling and debugging using Eclipse with ADT plugin works well. Obviously Android NDK uses arm-linux-gnueabi-gcc of some version to compile the native libraries.
Since I've been using NEON intrinsics heavily, I would like to try to compile the native libraries with ARM's official compiler armcc. I read everywhere that armcc is supposed to give better optimized code when using intrinsics. So I downloaded the trial version of DS-5 from ARM website, just to try and see whether there's really any speed difference.
The DS-5 seems to be just a modified version of Eclipse that uses the ARMCC toolchain, so I installed the ADT plugin. But when I compile using DS-5, it seems that the code is still generated using gcc rather than armcc.
Do you have any idea how to force DS-5 or Eclipse to build the Android native code using armcc? Or is it possible (and how) to build the static NDK libraries from command line and then replace the libraries in my project, so they get deployed to the testing phone?
ARM DS-5 Community Edition doesn't include ARM compiler (armcc).
If you could get hold of armcc best would be to separate your processing heavy algorithms to individual compilation units (separate C files), build them with armcc as you would do for any compilation unit. When you get the object files, convert them into an archive then use that in Android.mk as LOCAL_STATIC_LIBRARIES += <your_archive>.
You can't use armcc plainly to build Android compatible libraries mostly because of Bionic dependencies, I think.
You can use armcc to build Android compatible static libraries even though Android has a different C library (bionic). The key is the --library_interface flag for armcc. According to the documentation:
Use an option of the form --library_interface=aeabi_* when linking with an ABI-compliant C library. Options of the form --library_interface=aeabi_* ensure that the compiler does not generate calls to any optimized functions provided by the ARM C library.
In addition, there are a few more flags to ensure compatibility with the Android EABI resulting in the following command for an Android armeabi-v7a target:
armcc --library_interface=aeabi_clib --wchar32 --enum_is_int --no_hide_all --cpu=7-A --fpu=softvfp+vfpv3 -c -o libfunc.o libfunc.c
You can then use armar --create libfunc.a libfunc.o to create a static library that can be linked with the Android NDK as LOCAL_STATIC_LIBRARIES.
I have successfully tested this with Android NDK r10d on Android KitKat 4.4.2.
I want to cross compile a c++ library to the android plateform and this library depends on other libraries (those librairies are included yet in the android plateform).
Actually ,i have downloaded the android source code (android 4.1), i have also the library source code and i just don't know how to cross compile this library with it dependencies?
I would be thankfull if someone can tell me the right way to do it.
I believe that the easiest path is to set up the standalone toolchain using latest Android NDK, and build your library and all its dependencies with that toolchain. Here is an example: http://trac.osgeo.org/gdal/wiki/BuildingForAndroid
I need to run a newer version of openssl in my app than the one that comes in the OS. I was able to patch and android source to compile a newer version and then extract the shared library to use in my app.
I was then able to compile and link my native code that requires a function only in newer versions of openssl against my new shared library (the patch to a newer openssl worked).
I was also able to create a few jni functions that work as expected but as soon as I added in the function that is only in the newer openssl shared library local to the app I get an unsatisfied link error.
My assumption is that the system version of libcrypto and libssl are overriding my local versions in /libs/armeabi/libcrypto.so and /libs/armeabi/libssl.so .... how to I fix this?
The system already ships with a library known as libcrypto, and that will be picked before your library will. The easiest solution is to give your library a different name, and use that in your System.loadLibrary(...) call.
Update
As you pointed out, you will need to rebuild the library with the new name, in stead of just renaming the file.
Yes JNI is picking up the system versions. It didn't use your patched versions at all. On standalone JVM you would say -Djava.library.path=/libs/armeabi or modify environment variable LD_LIBRARY_PATH. On Android i guess you can either look up the system property java.library.path and put your libs in some known place (but before the folder where the system versions are) or actually modify the property - prepend the path to your local versions. I do have some experience with Android but not specifically with NDK.