GDK?

Probably some of you already noticed that there is a newly created folder gdk inside ./android since JB (API 16). Based on the fact that gdk is result of efforts to adopt llvm into Android, I'm not sure where to begin with. I'll start with Dalvik, DVM, NDK, and LLVM before jumping into the conclusion. Even though it's not populated until API 17, but the bottom line is supporting gdk can be a good sign that Android is now ready to adopt other than DVM. along with NDK.

Dalvik and DVM

Dalvik is just another yet virtual machine which is suitable for mobile computing environment (which requires lesser memory and cpu than usual). Android uses the Dalvik virtual machine with just-in-time compilation to run Dalvik dex (Dalvik Executable). This converting job is done with the tool called dx as follows:

• Converts class file into dex (Dalvik Executable) format.
• Includes every constants into the above dex file.
• Converts java bytecodes into DVM instruction sets
• Optimization (however, there are a lot of context of 'optimization' e.g. odex, dexopt

Compilation of dex is usually done in below ways:

• The VM does it "just in time". The output goes into a special dalvik-cache directory. This works on the desktop and engineering-only device builds where the permissions on the dalvik-cache directory are not restricted. On production devices, this is not allowed.
• The system installer does it when an application is first added. It has the privileges required to write to dalvik-cache.
• The build system does it ahead of time. The relevant jar or apk files are present, but the classes.dex is stripped out. The odex is stored next to the original zip archive, not in dalvik-cache, and is part of the system image.

Last not but least, there are derivation of DVM, which is called DTVM (Dalvik turbo virtual machine),and as of JB API 16, it is backward compatible with MIPS architecture. More on DTVM on MIPS.

NDK

However, DVM itself is sometimes not sufficient enough to do native-oriented application; e.g. Graphics, 3D rendering, etc. NDK is a tool that allows Android apps can run native-code. (e.g. C, C++) Main design for NDK is to tackle either computationally expensive operation (while not memory consuming), or kind of system attached operation (for example operation which requires a lot of context switching). Here is summary from NDK overview (./android/ndk/docs/OVERVIEW.html) :

• The Android VM allows your application's source code to call methods implemented in native code through the JNI.
• The Android NDK is a complement to the Android SDK.
• The Android NDK provides a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X and Windows (with Cygwin)
• The Android NDK provides a set of system headers corresponding to the list of stable native APIs supported by the Android platform. This corresponds to definitions that are guaranteed to be supported in all later releases of the platform.
• The Android NDK provides
• The Android NDK is NOT a good way to write generic native code that runs on Android devices. In particular, your applications should still be written in the Java programming language, handle Android system events appropriately to avoid the "Application Not Responding" dialog or deal with the Android application lifecycle.

So in a nutshell, NDK is an efforts of making Android more flexible by supporting certain level of native codes. And sometimes, yes sometimes, it can be much faster.

RenderScript

Renderscript is a component of the Android operating system for mobile devices. It is a low-level API for intensive computation using heterogeneous computing. It allows developers to maximize the performance of their applications at the cost of writing a greater amount of more complex code. Renderscript offers a high performance computation API at the native level that you write in C (C99 standard). Its main goal is mainly three: portability (Applications need to be able to run on a wide range of hardware without changes), performance (guarantee to provide 60fps, utilize advanced vector operations), usability. NDK is currently working as a agent to adopt RenderScript inside Android, however, NDK has somewhat limitation as below:

• The Android platform provides a very minimal C++ runtime support library (/system/lib/libstdc++) and corresponding headers for it in the NDK.
• By default, this 'system' runtime does not provide: Standard C++ Library support (except a few trivial headers), C++ exceptions support, RTTI support
• The only headers provided here are: cassert cctype cerrno cfloat climits cmath csetjmp csignal cstddef cstdint cstdio cstdlib cstring ctime cwchar stl_pair typeinfo utility

And LLVM is another solution to tackle the limitations of NDK.

LLVM

LLVM is not a virtual machine itself anymore; even though its name is VM, it started as a research project from UIUC. LLVM covers whole compiler infrastructures including C, C++, ActionScript, Ada, D, Fortran, GLSL, Haskell, Java bytecode, Objective-C, Python, Ruby, Rust, Scala, C#, and running.
In a nutshell, what LLVM does is optimization. It resides between compiler and IF (intermediate form), and produces optimized IF. This optimized IF can be converted and linked into machine-dependent assembly code. LLVM can also generate relocatable machine code at compile-time or link-time or even binary machine code at run-time. Although optimization of LLVM behaviors during link-time, run-time, compile-time is huge topic, it is beyond the cover of this post. But the bottom line is LLVM & Clang provides portability, usability and performance where above native-oriented operation need them. (as explained in RenderScript)

Clang

When we talks about LLVM, we cannot skip Clang. Clang is an LLVM native C, C++, Objective-C compiler, which aims to deliver fast compiles than classic compiler (e.g. gcc); And depends on architecture, and the nature of the complexity of the code, it can provide much faster speed for compilation. FYI, Apple populated use of Clang since Xcode 3.1 and iOS SDK as iOS is using Objective-C. Compare to gcc, Clang has below benefits:

• Compatible with gcc
• Lighter, more compact, and more modularized.
• Easier to debug
• Faster (in average)
• Supports LLVM
• Uses LLVM BSD license

So what is GDK?

In short, GDK is results of adopting LLVM inside Android platform. It provides faster, lighter, more compatible native-code operation inside Android platform.
You can find more details about GDK on below gerrit. It's not even surprised that llcm is also part of platform.

• https://android-review.googlesource.com/#/admin/projects/platform/gdk
• https://android-review.googlesource.com/#/admin/projects/toolchain/llvm

Links and references

• There is a nice presentation by KAndroid here
• Dalvik on Wiki.
• More on optimization of dex: here
• More on DTVM on MIPS
• Android RenderScript Google TechTalk
• RenderScript on AndroidDev
• NDK description on AndroidDev
• NDK Google group
• Homepage for LLVM
• LLVM blog
• LLVMlinux
• Clang on wiki
• Clang project