I have an .so file which I pulled from an Android APK (Not my app, so I don't have access to the source, just the library)
I want to use this shared object on my 32 bit Ubuntu machine, and call some functions from it (Preferably with Python) . Is it possible to convert an Android .so to a Linux .so?
Or is there any simple solution to accessing the functions in the .so without resorting to a hefty virtual machine or something?
Thanks
Most likely not. It's very probably the Android you pull it from is running on the ARM architecture, and therefore the .so library was compiled for that architecture.
Unless your desktop machine is also on the ARM architecture (it's most likely x86 and it would have to be specific such as ARMv7) the .so binary will be incompatible on your desktop.
Depending on what the .so library actually is, you may be able to grab the source code and compile it for your x86 machine.
Disclaimer: Even if you obtain a library compiled for the same architecture as your desktop (from x86 phone), there is no guarantee it will work. It may rely on other libraries provided only by Android, and this may be the start of a very deep rabbit hole.
Related
How to configure OpenCL environment for android platform either in windows or linux using any IDE? I want to make use of GPU using OpenCL for smartphone.
Android does not have official support for OpenCL and Google is openly hostile towards it, going to far as to remove unofficial drivers http://www.anandtech.com/show/7191/android-43-update-for-nexus-10-and-4-removes-unofficial-opencl-drivers . Even if your hardware still has OpenCL drivers you cannot distribute the app in Google Play, so it's practically useless.
For Android you are better off using Google's Renderscript (the reason why they hate OpenCL, they want their solution to be used) http://developer.android.com/guide/topics/renderscript/compute.html
You can write certain algorithms easily using Renderscript. It's basically like OpenCL but it has no concept of local memory and accessing thread id is not supported. But for things like simple image processing or particle simulation it's perfect.
If you must use OpenCL for some reason and your target hardware supports it just use adb pull to get the libOpenCL.so out of the phone, copy it to the ndk lib directory, and also place OpenCL include headers to the include path and you're good to go.
Basically, to develop OpenCL program/applications for Android, the followings are what you need:
Android SDK, Android NDK
Cygwin (if under windows)
OpenCL header file (could be downloaded from Khronos website)
OpenCL lib file. For different chip vendor, this library is located under different path. See here for details.
Develop OpenCL program in C/C++. compile with ndk-build to a shared library.
Develop your application using Android Studio. Use JNI to call your OpenCL-related functions from the native shared library.
I am working on a project in which I need to include NGSpice simulation library in an Android application and of course be able to use it.
I tried including the NGSpice windows DLL in my android application using SWIG and Android NDK, but it turned out that it is not even possible, so now I started to think about building NGSpice as a shared library for linux.
And now my question is, can I use the linux shared library for NGSpice as it is in my Android application, or does it need to built differently somehow to work on my Android application.
Thanks.
No. Android typically has two key differences from a traditional linux:
1) It uses the Bionic C library and dynamic linker, instead of a more traditional set such as glibc.
2) Android is typically run on an ARM or 32-bit x86 processor (or in rare cases MIPS), while your desktop Linux library might be either 64-bit or 32-bit x86 code.
If you build a .so compatible with the architecture of the machine and with bionic's system library functions and dynamic linker, then it should be workable.
Alternatively, if you have something for a compatible architecture but the wrong libc, it may be possible to write your own loader to get it into memory in working form on a secured device, or on a rooted device it is possible to run a more traditional linux userspace (typically Debian derived) in a chroot. But neither of these would be easy to integrate into an Android application - for the latter you'd almost definitely have to pass work over via interprocess communication, and that might prove easier in the former case as well.
Your only really endorsed solution is to rebuild the library from source, using either the ndk build system, or an ndk-generated "stand alone toolchain" and the library's current build system.
I'm trying to use an SDK (provided by a third party, not Android SDK) for Android (ARM) that implements functionality in native code, unfortunately what I'm trying to do requires a central server as well. All I have is the compiled .so file (and a jar that interfaces to it), I know this is a reach but is it possible to recompile it to run on a normal Linux (x64) box?
I figure it probably wont work cuz of differences between JNI and Android NDK interface but I thought I'd ask here before I throw in the towel on the idea.
First of all Android sdk contains .jar files only and no .so files.
The .so files to which .jar is linked to is already present in devices as a part of Android OS.
So for linux, compile the Android source code for x86 and you will get all the .so for x86.
Once you compile the android source code it also creates sdk for the respective architecture.
But I think .jar should be same for all architecture as java is architecture independent.
I can cross-compile any C/C++ application, statically link it Linux libraries and run it on Android. What was the need of an Android-ndk then? Android-ndk limits us to bionic which has a small subset of gnu libc. Isn't it a better idea to straightaway cross-compile applications and run them through Android shell? Is there any limitation to cross-compiling that I can't see? This URL : Can Linux apps be run in Android? answers my question to some extent but eventually leaves me confused and without clarity.
I think this is enough for Android-NDK
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change.
The NDK provides:
A set of tools and build files used to generate native code libraries
from C and C++ sources
A way to embed the corresponding native libraries into an application
package file (.apk) that can be deployed on Android devices
A set of native system headers and libraries that will be supported
in all future versions of the Android platform, starting from Android
1.5. Applications that use native activities must be run on Android 2.3 or later.
This thing you can not find in other cross-compilation with arm toolchain..
As mentioned in the link http://developer.android.com/sdk/ndk/index.html NDK is a companion for App development folk to create performance sensitive native code. NDK exposes some of the native implementation of Android which could not be found in the general Linux environments. Some of them include the Android/Bitmap, Android/nativeWindow etc. Using these Android natives applcation can speed up CPU intensive processes like some compression or decompression of images.
Even though the externally cross-compiled executables may run in the Android there no guarantee that versions of the standard library implementaions are the same. NDK provides a easier and Android compatible toolchain and other resources, using which is much easier to application developers than having to find a compatible cross-compiler for their usecase.
I am interested in building an open source project and it requires the GNU libraries GLIBC and GLIBM. If I were to cross-compile this under Linux (I am using Ubuntu 11.10 as the host) for a shared (.so), or even a static (.a) object, with the ARMv7-a neon architecture, using API-9, as a library to call with Java's JNI, to ultimately compile as an APK for distribution, what steps would one undertake to achieve this outcome?
Given I have tried the Google NDK toolchain (setting $PATH and $CC the hard and easy way according to the documentation), a variety of custom toolchains, the Code Sourcery toolchain and a toolchain suggested on the XDA forum using crosstool-ng, is it possible to achieve a shared object file that can be called from JNI and has access to the full GLIBC library on a non-rooted Android device?
I have searched for an answer to this and the closest I have come is to build GLIBC and GLIBM locally and copy the relevant object (.o) files and link manually using the NDK's arm-linux-androideabi-ld. The libc.so.6 file from Crosstool-ng and CodeSourcery will not work as the relocations fail (giving error unknown reloc type 19) when calling the library using Java's System.LoadLibarary(). My knowledge of relocations is not the best but from what I have read this would require changes to the /linux/elf.h header file, but I am not sure exactly where to go from there.
I believe from what I have read that it may be possible to make a static executable that has all dependencies resolved when linked but then it would not be possible to package this as an APK file as far as I'm aware.
Surely I can't be the first to want to compile C code against something other than Bionic for the Android platform? There are so many C projects that could be ported to Android and apparently GLIBC has been available on iPhone for quite a while.
Any low level C library has very tight ties with the OS itself. While Linux and Android may mostly be the same thing, they are not. Building against another C library will require said C library to be ported first.