This again, is wrong. Android was made to run managed code from the beginning, it's designed around that very fact. Let me try to enlighten you. In Android, ev

This again, is wrong. Android was made to run managed code from the beginning, it's designed around that very fact. Let me try to enlighten you. In Android, every process spins up its own Dalvik VM. Yes, Dalvik VM, not Java VM, as Android doesn't run Java. The android development tools does contain a Java Bytecode to Dalvic Bytecode converter (dex), which is why JVM based languages run on Android, as long as you don't generate Java bytecode on the fly (which several dynamic languages do). Anyway, each process spins up it's own Dalvik VM, which get's to run your Application. There really isn't any exception to this, which means that even if you create a program using the NDK, you will still need to do some Java to set up an activity that in turn runs the native code. Because calling native code through a foreign function interface (FFI, known as JNI on the JVM) creates some overhead, Android does as little of this as possible. This is why most the UI API is implemended directly in Java/Dalvik-Bytecode, and only the low-level drawing API is in native code (or implemented directly in the VM, not certain). If you program an app using only the NDK, you therefore won't have access to the native UI API, meaning you will have to write glue-code to call the Java API, or use your own GUI API (like Qt). > Because of that brilliant idea to simply ignore what an OS provides, they have re-implemented everything its own, proper way - famous Strings, Calendar, UTF-32, you name it. Right... So normally, out of the box, you will have access to wchar, socket, time.h and math.h. You don't really re-implement this in the JVM, you write bindings to the low-level functions, and then write abstractions (UTF-16, Strings, DateTime ...) on top of that. The actual bindings are usually generated using Swing or something like that. > So, the developers of complex (read: real-world) apps such as FB have realized that this unnecessary Java layer can't be used for anything ... Hopefully, I've been able to explain why cutting out the Dalvik/Java layer brings more pain than it's worth. Most applications on Android are running on the Dalvik/Java VM. The exceptions are VMs (Like Xamarin.Android) and OpenGL applications, like games, which require more fine grained controll of memory allocations to avoid garbage collections in the middle of a render-loop. Just in case you are not convinced, here is Google's own warning on the use of the NDK for app development. "Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++." P.S: Facebook did use HTML/JS for their app for a while, but switched to the native SDK because the HTML-based app was to slow. The native SDK (Java) seems to suit them just fine. P.P.S: Check out this link to see why using the NDK is a pain in the . https://mflerackers.wordpress.com/2013/08/25/using-the-ndk-and-jni-to-build-android-applications/ https://mflerackers.wordpress.com/2013/08/25/using-the-ndk-a...