Ruslan explains in this lecture how to begin native development on Android platform.

1. Native Development Kit
…for Android OS
novikov.ruslan@gmail.com

2. C/assembly
C/C++
C/C++
Java
/ ART

3. 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

4. Let’s write some Java

5. 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

6. 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

7. 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

8. Let’s write some C

9. "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

10. Let’s do some JNI

11. 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 ;"

12. Summarizing Build Process

14. 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++

15. •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)

16. 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