ndk
TRANSCRIPT
C/assembly C/C++ C/C++ Java
/ ART
Why NDK
Reusing existing code Also your own code
For performance critical apps Native code is generally faster that bytecode
To access low-level APIs
Native lets you access more physical memory “Java” heap is seriously limited per app in a Android
You are C++ freak
Let’s write some Java
Pre-NDK era
• JNI always have been there
• Native libraries always have been there
• You could bundle your .so if you are ROM vendor
• But you could not develop app that uses C/C++ code
What’s inside
• NDK is a toolchain – Contains cross-compiler for ARM, x86, MIPS
• NDK bundles native library into your app • Standardizes some native APIs
– libc (C library) headers – libm (math library) headers – JNI interface headers – libz (Zlib compression) headers – liblog (Android logging) header – OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers – libjnigraphics (Pixel buffer access) header (for Android 2.2 and above). – A Minimal set of headers for C++ support – OpenSL ES native audio libraries – Android native application APIS
How to begin
• You can develop on – Windows – Mac – Linux
• You need download and unzip the latest NDK • If Inside eclipse, set Preferences->Android->NDK
to mentioned directory • rclick on Android Project -> Android -> Add Native
Support
Let’s write some C
"escape hatch" for Java
• Technology that enables Java code running in a VM to call and be called by native applications
• Has C and C++ interfaces
• Has many of pitfalls: – Subtle errors in the use of JNI can destabilize the
entire MRE
– An application that relies on JNI loses the platform portability
– The JNI framework does not provide any automatic garbage collection for non-JVM memory resources
Let’s do some JNI
Type Mapping From Java->C
Native Type Java Language Type Description Type signature
unsigned char jboolean unsigned 8 bits Z
signed char jbyte signed 8 bits B
unsigned short jchar unsigned 16 bits C
short jshort signed 16 bits S
long jint signed 32 bits I
long long __int64
jlong signed 64 bits J
float jfloat 32 bits F
double jdouble 64 bits D
void V
"L fully-qualified-class ;"
Summarizing Build Process
Why not NDK
• Complexity • Significant part of the framework is not accessible
via NDK (at least currently) • There are better tooling for Java development
and debugging • Multiple architectures should be taken into
account • Ironically native code can perform worse in some
cases
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++
• Android programs are commonly written in Java and compiled to Java bytecode, which is then translated to Dalvik bytecode and stored in .dex (Dalvik EXecutable)
• Later the bytecode is executed under Managed Runtime Environment (MRE)
• Android Runtime (ART) is an MRE that replaced Dalvik VM beginning with Lollipop
• Native code executes inside a process that contains MRE (Dalvik VM or ART)
• (Dalvik) Bytecode executes under the control of the Runtime (Dalvik VM or ART)
References
• http://stackoverflow.com/questions/11992836/where-exactly-does-ndk-native-code-execute
• http://multi-core-dump.blogspot.co.il/2010/04/android-application-launch.html
• http://coltf.blogspot.co.il/p/android-os-processes-and-zygote.html
• https://groups.google.com/forum/#!topic/android-ndk/lcnwzszrESo