I would like to use a .jar file generated by SWIG in an Android application. What is the best way to deploy all of the underlying dll's with the Android application?
In a desktop environment, my PATH variable includes the folder containing these dll's.
DLL is a Windows technology. Android is not Windows. Android is based on Linux. You would be looking for .so libraries. More accurately, you will be looking for the C/C++ source code behind those libraries, so you can cross-compile them for Android chipsets (e.g., ARM). That will be accomplished via the Native Development Kit.
Related
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.
I am little bit confused with SDK path in qt for mobile. I know Qt is based on Android NDK (C++). Then why we need to set path of SDK in tools->options->device->android->sdk path. Is SDK is based on Java?
NDK is used to compile your C++ code.
But NDK is only able to generate .so files (libraries compiled from C++). SDK is needed to generate the apk that will contain the program's main entry point that will end up using the .so files compiled by the NDK.
I don't think (not sure) that any app can be deployed on an Android device without using the SDK. Anyway, even if that could be possible, the way QtCreator works, it needs the SDK to deploy your application correctly on the device.
I have a C++ application that uses Qt 4.8 and OpenCV 2.4.2. It is developped using Visual Studio. I have to migrate this application for Android and iOS.
Which is the plan to follow? I should make the minimal change to the existing code.
Unfortunately, there’s no easy answer to this. The fact that you’re using Qt is a great start, and using it as much as possible will go a long way towards making your code portable from Windows to other OSes.
I would look at upgrading first to Qt 5, as Qt introduced great support for both iOS and Android.
After that, the build chain is going to be your next obstacle. It looks like the Qt Visual Studio Add-in has an option to export a .pri file from the VC++ project, which would be a very handy starting point. Generate the .pri file and compare it to the project file created by QtCreator for an Android and iOS app, and try to copy the mobile-specific parts into your generated .pri file.
Other potential pitfalls are:
Visual C++ is a much more permissive compiler than gcc (Android) or Clang (iOS and Android)
Your app's dependencies must all be cross-platform as well. I’m sure OpenCV is, but it’s something to keep in mind
On iOS, all libraries must be linked statically
I am developing an app which uses a native library. I would like to test it using a non-android dependent framework like Robolectric.
The problem is, that the native functionality cannot be loaded using
System.loadLibrary("mylib");
because on Windows it looks for "mylib.dll", and I am only able to build libmylib.so which is not compatible with windows.
Is there a way to build a dll (it would be only used for testing purposes ofc)?
If you want to test your application on windows, then you need a *.dll. *.so files are unix "shared libraries" - same functionality as windows' dll.
You have to build your C++ sources with an IDE like Visual Studio, Code Blocks, or anything else that can build sources for windows.
In fact, when building with "ndk-build" for android, you are cross-compiling for an Unix system with an ARM architecture mostly.
When running on windows, you'll probably be on x86 / x86_64.
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.