Call C++ executables insider Android - android

I am now porting a linux C++ library to Android using JNI. The library porting itself is very straightforward, and I have built a C++ library that can be invoked by Android via JNI. Now my problem is to verify that the library works well in Android environment as well. In the linux development environment, some unit-tests and regression tests are already available. So I was wondering whether I can test the library by taking advantage of all the available unit-test and regression test programs. For example, in linux I have the following binaries:
mylib.so
my_unit_test
my_regression_test
Then for Android, I will first built mylib_android.so. Then, can I build my_unit_test_android and my_regression_test_android for Android platform? If it possible, how can I invoke them in the Android simulator and the real device?I have little knowledge about Android, and any ideas will be appreciated.

Transform them to libraries with single function and write Android app that will use them.

Related

Qt on Android - does the C++ code run in the Dalvik virtual machine

I have heard it said that the C++ code runs "natively" on all platforms. By this I guess that what is being suggested is that the cross-platform ability of Qt is not using something like HTML 5.
But does this mean that on Android Qt code runs in the Dalvik virtual machine?
Android understands either Dalvik or the newer ART. Dalvik and ART both have the ability to link to C/C++ code through the Android NDK which is Android's take on JNI. QT for Android while being C++ based still requires a minimal amount of Java based initialization. What this means is that even if the C++ code runs natively (architecture dependent) to the underlying OS, it is still required to be presented through code that runs on the VM (Android specific) as the VM does not directly understand C++ but can link to it through it's own Java based framework which is the Android NDK.
Please check https://www.qt.io/blog/2013/07/23/anatomy-of-a-qt-5-for-android-application
At the very top of levels, a Qt for Android application consists of two parts:
The Qt application:
This is the cross-platform code and resources that you, as the app developer, manage yourself, and which are summarized by your qmake .pro file.
An Android application launcher:
This is generated for you by Qt Creator the first time you connect your project to a Qt for Android Kit.
So, Android application launcher should run in Dalvik VM. I can't sure if this works well with ART runtime of Android 5.0

C++ code Compatibility with Android

I have a c++ code which is needed to communicate with an OCR scanner. On Windows it works fine. However I need to integrate it with Android. My approach is to use the NDK and JNI. However the problem is that the c++ code is only compatible with Windows (There are endless dependencies on windows libraries). When I try to build it using the NDK, it fails.
Any suggestion regarding this? Should try to convert the code to a linux compatible one? OR is there another way?
Note: the code calls a dll library that contains the functions to communicate with the scanner.

Android-Ndk vs Cross-Compile? Both work, but what was the need of Android NDK then?

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.

can native only code run on android as standalone application

We want to migrate a huge complex native program to Android system ,running it as a background service accepting command sent from Java Program using JNI along with IPC. However, the Android NDK state following words:
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Does that mean we have no way to run an standalone native-only application on Android as a background service? The native code can only exist in the form of library that will be loaded to the virtual machine through JNI?
The NDK itself is only for creating libraries, though if you do some web searching you will find that there are at least two sets of wrapper scripts or instructions for (ab)using its toolchain to make standalone executables linked against android's bionic libc (something you would not get from a non-android arm toolchain).
The google folks do not encourage people to do this. Unfortunately, their vision of android only includes java applications, with optional native libraries in support - it does not include any "stable" means of installing or launching a native executable, in the sense that they warn the methods you might be able to use today may not continue to work in new versions. This is really too bad, as it means giving up a lot of the general-purpose-computer potential of the device.
Well, it can be done. But to be honest i've never tried it using the NDK, but i've managed to create native applications using the toolchains provided with the android source code.
Your phone (incase your talking about phones) should be rooted.

Porting C to Android using Android NDK

Has anyone used the Android NDK to port a Linux app? We have an SSL VPN solution at work which Openconnect (http://www.infradead.org/openconnect.html) works with, but there is currently no client (from Cisco or otherwise) on Android. Is using the Android NDK a feasible approach to get this to work?
Thank you in advance
The NDK is a good solution for porting C/C++ Apps. You need to do a thin java shell to pass over any input, init and exit the program.
If your C app requires STL or exceptions - there are modified versions of the NDK that support them.
The Android NDK is not for porting apps. It is for creating libraries that can be accessed from a standard Android Dalvik app via JNI.
So, if you have the source code to this project, and it results in a .so, and you can write a JNI wrapper for it, the NDK may be a solution for you. Considering the project you cite seems dependent upon scripts, I suspect that's not how it was set up for use.

Categories

Resources