Applications for Android devices are written in Java. I also know of the existence of the NDK (Native Development Kit).
I have a library written in C++ that uses:
stl containers
c++ i/o (streams etc..)
memory allocation/deallocation using new etc...
Are all this things available to the programmer that want to use the NDK for C++ development?
I am confident that memory alloc and stl are there, but what about I/O from files? Can i use istream/ostream? I ask because i have programmed apps on Symbian and i had to use RFile and other classes (there was no support for fopen/fread etc).
Yes, low level I/O is possible. fopen/fread are available from the first NDK release.
istream/ostream are available since NDK r5 when STLport and GNU stl were added.
Related
I'm starting my first piece of Android programming, porting some libraries written in C and C++ to Android. I am not building an app, except for testing the libraries: the product is the libraries, which will be supplied to my customers. The libraries are mathematical modelling, running on the device, and have no web or cloud interfaces: customers who want to run them in the cloud already do that, using the Linux or Windows builds.
My initial customer is using NDK 14b. I could use that, or I could use the latest NDK, 16b. If I compile C code with NDK 16b, a compatible instruction set and the same C++ run-time and target API version as my customer, will they be able to use static libraries that I've built in their NDK 14b app?
The other way around is also interesting: if I use NDK 14b, and another customer comes along who uses NDK 16b, will static libraries I've built with 14b work in their 16b-built app? I'd be targeting an equal or earlier API to them, and the same instruction set and C++ run-time.
Addendum, much later: Building .so libraries turned out to be so easy that I've never used anything else.
You kindof cannot target the same C++ runtime when you use a different NDK release. The STL versions do not change too much, but there is no contract of their stability.
Except from this remark, static lib from NDK r16 will cooperate correctly with r14 and vice versa, but the bigger the gap is, the more glitches you should expect to handle.
In general, NDK improvements involve bug fixing, so there is an incentive to use the latest release. But major progress is done in support of newer platform versions. This means that if your library will be linked into an app that targets Lollipop, the advantages of r16 will be less prominent.
Note that if you can ship your library as a linked shared library (so), your interdependency with the host app will be significantly less, and in my experience this improves stability and reduces clashes. If that is relevant, this way is also more secure.
I built a library(.so) that is being called from JNI code in some android app. The JNI code is built using NDK.
If I build the library using android tool-chain, the library works well when called from JNI code.
If I build the library using another tool-chain (used on the same ARM device for none android applications), the library crashes when called from JNI code.
why do we need to use android tool-chain (or NDK) for compiling c/c++ code running in the context of an android app? why not use other tool-chains?
You can use other toolchains, but it requires special care.
Maybe a good starter would be to learn the UBERTC and Linaro Wiki.
The main difference is that NDK compilers are tuned for bionic (Android variant of C runtime libraries). Originally, bionic was a modest subset of Linux runtime. On latest platforms, most of the gap is closed, but now there are many extensions that you probably need.
Also, Android dynamic linker may require (depending on target platform) a set of ELF flags that are automatically delivered by NDK binutils, like PIC, id, and others.
It is quite possible to use arm-linux toolchain to build a statically linked executable that will run on Android, but for a library that must play well on the JNI environment the effort is probably not worth it.
Note that NDK provides tools to create a standalone toolchain, which behaves very similar to other toolchains you may be familiar with. This approach makes it easy to adopt 3rd-party libraries with sophisticated build scripts.
Since 2 Years I am working as Android Application Developer. I generally use android SDK for all the Android Apps Development. Now I have a project which is an Android App in which I have to use SDK as well as NDK for App development (As per Client requirement).
But as I don't have any experience with NDK I don't know what is it. In some Blogs I have read that NDK development is based on c++.
Is it true that to work with NDK one must have the complete knowledge of c++ ?
Please Help !!
Use of NDK means you have to write portion of code in C/C++ just to achieve the speed. If it is client requirement then you have no option. But keep in mind that you should use NDK only when you feel you need better performance. And of course you must have some understanding of c/c++ to use NDK.
NDK
NDK is a set of tools to compile C code to shared lib,
which you could use in your app - and that's all.
Enables legacy code re-use between iOS and Android platforms
Good for implementing CPU intensive operations that don't
allocate much memory like signal processing, physics simulations.
SDK
SDK is the main development kit for Android apps - it contains tools for Java and resources (png, xml) compiling, packaging to apk file, installing, running and debugging them on a device, an emulator, documentation, etc.
Java has superior memory management model Superior threading model Better exception handling model Rich set of libraries Superior support for unicode characters.
Trying to port a Delphi library to Android. Free Pascal has Android/ARM support - a prebuilt compiler for Windows is available. However, Android NDK now supports MIPS and x86 as well. What's the status of support for those in FPC? For now, my project is more or less CPU agnostic - the native bits are built for all four supported architectures. Don't want to let go of that.
I'm not after the full cycle of Android development in Pascal - just an algorithm library that does no I/O. I tried translating it into C with p2c, but the translator chokes on the sources.
Should I just try and build cross-compiler for the relevant CPU with Linux, and then link against the NDK libraries?
EDIT: I've built the cross-compiler for Intel/Linux from the sources of the Android branch. It works, except you have to invoke ppcross386 to compile, not fpc. The latter, it seems, ignores the -Tlinux option and invokes the Intel/Win32 compiler.
EDIT2: with a small change to the makefile and sources, the MIPS cross-compiler builds. However, as building moves on to the cross-CPU RTL, it errors out almost right away.
EDIT, finally: support for Android/MIPSEL compilation target is available in the FPC trunk. Export the latest, build the crosscompiler, code away.
While support for MIPS ISA can be found here and there in the FP sources, it's not officially done yet. Waiting for the 2.7 release.
In the meantime, there's support for compiling to Java bytecode in the trunk, it's documented in the FP wiki. Maybe I can leverage that as a stopgap...
EDIT: Free Pascal over JVM works in general on Android, but its rules are somewhat different from regular Pascal. Otherwise correct Pascal conks out when compiled to JVM. So it's unfit for porting large bodies of legacy Pascal code that was not written with JVM in mind in the first place.
EDIT: I got my FPC project working on MIPS/Android, but my recipe is not fit for general consumption, because the scope of Pascal RTL usage in my project is very limited. It involves cross-compiling from Pascal to MIPS assembly (targeting MIPSEL/Linux, available in the FPC trunk), then feeding the generated assembly sources to the NDK build system, providing along a C/assembly reimplementation of a limited subset of Pascal RTL.
The whole body of Pascal RTL is big and scary. My solution, which involves reimplementing the Pascal RTL in C from scratch, is, well, the opposite of generally applicable.
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.