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.
Related
I want to release my SDK. but I have no idea Do I have some unknown problems if I compile the .so from different platforms (Mac or Window using same ndk version).
I think it is same between different platforms but I didn't have windows platform to confirm.
So Are the libraries different build from different platforms?
Bluntly, you should not believe that compilers produce the same code on the same input deterministically. Many do, but many do not. This is especially true when using optimization. (This situation is improving now the problem is recognized). The consequence of this is no matter what you build on you must only release the exact binary you have tested.
That said, you can totally build with the NDK on multiple platforms. Many of the large games studios use Windows and Macs for development, and production builds are done on Linux continuous integration systems, so this is done in practice all the time. You are far more likely to run into trouble with any extra tooling you have than the ndk itself.
You can safely mix Android binaries built on Mac and Windows, but please make sure you use the same NDK release and same parameters (most notably, same APP_STL).
You can send your native libraries built on Mac to Java developers who work on Windows. They don't even need NDK and don't care which release you were using (as long as it works).
As far as I know one can can write apps on Android and iOS in C/C++, instead of Java and Objective-C.
Since both C and C++ rely upon their Standard Libraries, where and how the C/C++ Standard Library is implemented in such OSes? Is it part of something bigger like e.g. the Android NDK? If it isn't, can I use a different implementation if needed?
There are several concepts at play here, I'm going to try to keep it brief. Android uses Bionic as its C library. It also lists different C++ libraries, however, they recommend you stick with libc++ (Clang) since they have stopped supporting libstdc++ (what they call gnustl) and STLPort is ancient. Now even though they call libstdc++ the system runtime, for libstdc++ in particular, the support library is called actually libsupc++. In order to have exception and RTTI support, you need to implement/build this, which doesn't seem to be the case for Android.
For Apple, it's a different story. XCode is the IDE (not the compiler!) On old versions of Mac, they shipped an ancient version of GCC. There was a transition period where they used llvm-gcc and symlinked gcc to clang. Now the latest version of XCode only supports LLVM/Clang. By default, Mac uses libc++, but you can select libstdc++ if you prefer. Keep in mind that although Clang tries to be as ABI-compatible with GCC as possible, it's probably not wise to mix libraries compiled by libc++/libstdc++.
Can you use a different C library in your toolchain? Not easily. You would need to port the C library of choice (i.e, Newlib) to the platform which is not trivial. Further, you would need to build a cross compiler toolchain that not only targets that system but also uses the new library. You will have to look into people who have already done this for you.
Now even if it was easy, there really isn't a good reason to. More often than not you only want to swap out selective parts of the library, like malloc. Android in particular can use jemalloc for example.
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.
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.