Recompile shared Android library for Linux - android

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.

Related

Can or how Android studio use c++ static library *.lib (compiled for windows)?

Our project needs a third party library from another company and it is not open source. They provided *.h and *.lib compiled for windows (linux as well), but no cpp.
I didn't think android could use it but I still have tried it in NDK because I have never touch android studio before.
There are many questions, but it all comes to the question, is it possible to use *.lib in android studio(or VS cross-compile) without the cpp of that library?
If the answer is no, I think the only option for us is to request the android version of the library (*.so and *.a files). Is this correct?

Can I build a shared library for Android (*.so) in Embarcadero C++Builder?

I am trying to create a shared library, using Embarcadero's C++Builder and RAD Studio 10.2. I created a C++Builder "Dynamic Linked Library" project. When I specify the target platforms to build for, the only options are 32-bit Windows, 64-bit Windows, and OS X. I need to be able to build the library for the Android (Linux) platform as well. How can I accomplish this?
At this time, RADStudio (including Delphi and C++Builder) does not support the creation of custom .so libraries for Android (only consuming them). Per the documentation, .so files can be created for Linux (and .dylib files for OSX/iOS) by creating a Delphi-style Package instead of a Dynamic-Link Library.
RADStudio-created Android apps are compiled as .so files (because they are based on the NDK, so the real app is just a small Java stub class that loads and executes the .so at runtime), but that is the extent of Embarcadero's .so generation on Android. Compiling custom .so libraries for Android is simply not supported yet.

Creating Android Library using QT

I tried searching for a solution but the only answers i found were the other way around (using the AAR inside QT).
I am developing an android app inside QT creator.
All is working fine. Now i need to make the core of this app as a library that can be distributed to android developer to be used in their code (like an AAR).
Is that possible to be done?
If so, how to do it and how to import it in other development tools (android studio/ eclipse ...)?
The easiest way is to compile your library using QtCreator and then send people the generated .so file with the header files. Then people can link with the .so file and use the header files to call the functions or instantiate the classes packaged in it.
Check this link to see how to build a library with QtCreator:
https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application
Note that you'll need to compile both armv7 and x86 targets and send both .so files if those two targets are needed.

How to use Android shared library in Ubuntu

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.

Install app on genymotion device ,meet:“INSTALL_FAILED_CPU_ABI_INCOMPATIBLE”

When I install my app on a genymotion simulater device,it can not be installed well,on console I got "INSTALL_FAILED_CPU_ABI_INCOMPATIBLE"
I trid another app,it installed fine.I do not know why.
The application (certainly a game) must be ARM only.
Genymotion is a x86 platform, so compile the application to target x86.
You may be able to install ARM support manually :
http://forum.xda-developers.com/showthread.php?t=2528952
If you are using IntelliJ it may be related to the project's default configuration. IntelliJ will assume, unless otherwise specified, that Native libraries will be stored in the Libs folder. This is usually where developer store their JAR libraries. IntelliJ build process will package up the JAR file into the Native file folder in the APK.
If you experiencing this problem, you can find a good How-to:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE Intellj
This helped to resolve the issue I had.
You might want to check out my answer here:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE on device using intellij
I know it's written for IntelliJ, but you could be running into a similar issue with Eclipse where it thinks that some normal Java files or jar libraries are native code and including it in the compiled APK. A quick way to find out is to open up the final APK (it's just a jar file, so most utilities should be able to decompress it) and make sure that the only things you see are META-INF, res, AndroidManifest.xml, classes.dex, and resources.arsc. It's possible that there are other valid files in a normal Java Android application, but in general if you see anything else in there, particularly a libs folder, it's probably the result of the compilation process thinking that those other things are native libraries (compiled C/C++ code using the JNI).
If this is the case, you'll need to configure Eclipse to not interpret the Java libraries you're using as native code. Now, I don't personally use Eclipse so I don't know where the proper settings would be, but based off of this answer, it looks like Eclipse automatically assumes that the libs folder in the root of your project contains native libraries. The easiest solution may be to move any Java libraries you are using into a different folder (such as libraries).
http://blog.iteedee.com/2014/02/android-install_failed_cpu_abi_incompatible-intellj/
The INSTALL_FAILED_CPU_ABI_INCOMPATIBLE error is generated when you attempt to install an android application on a device with an unsupported CPU architecture. This error is usually related to the native libraries that are not packaged up for the device’s CPU architecture (ie: x86, ARMv6, ARMv7, etc).
Now, if you have an application that doesn’t use any native libraries or *.so file you might be scratching your head on this one. If you use IntelliJ IDEA IDE for your android development it might be packaging all of your related .JAR file in to the Native Library file location in your APK.
The cause of the same problem was different in my case.
I had added some dependency jars in /libs directory of my Android app project. One of these jars had exported library in jar format; i.e. a jar within a jar file. I've noticed that the apk created using jars with such structure are incompatible with x86 based devices (don't know why).

Categories

Resources