Android Internals and the Dalvik VM! Adam Champion, Andy Pyles, Boxuan Gu! Derived in part from presentations by Patrick Brady, Dan Bornstein, and Dan Morrill from Google (http://source.android.com/documentation)!
Introduction! Android internals (e.g., Linux kernel, libraries, etc.)! Dalvik Virtual Machine! Android application framework!
How everything fits together!
Android Internals - Linux Kernel! Android runs on the Linux 2.6.27 kernel -- but Android is not Linux!! o No GNU libc (discussed on next slide)! o No windowing system! Android extends Linux with custom IPC framework (Binder) and aggressive power management! o Binder is Google's lightweight IPC driver that uses shared memory for high performance, synch. process calls to maintain single-process programming model! o (Linux) Power management: shuts down CPU/screen to save battery power unless app requests that either CPU or both CPU and display stay on (wake locks)!
Android Internals - Native Libraries! Android uses these C/C++ libraries (among others):! o Bionic, Google's libc implementation optimized for embedded software platforms (BSD license)! o WebKit open-source browser engine (powers Safari)! o SQLite relational data store (stores all persistent data)! o Media framework (supports many A/V codecs)! o SurfaceFlinger graphics compositor to framebuffer! o AudioFlinger audio "compositor" to earpiece/headset/...! All these libraries sit atop the Hardware Abstraction Layer (HAL), where handset manufacturers provide native code for graphics, audio, GPS, etc.! o The HAL runs in user space, not kernel space! o Copes with non-standard interface specs, IP issues!
Android Internals - Runtime! Android's runtime runs atop these libraries. Comprises Dalvik VM and core libraries exposed via Java (JNI)! o Dalvik VM designed for!! App portability on different hardware implementations!! CPU/memory efficiency! o All Android apps run atop Dalvik! o Core libraries provide standard Java API for app developers, e.g.,!! Data structure!! File & network access!! Graphics! o They "plug in" to Dalvik!
Application Framework Terminology (1)! Android PacKage (APK) is a collection of components! o The APK file is a Zip file that contains source code files, resources (e.g., images, GUI layouts), etc.! o Components share databases, file space, prefs, etc.! o Each APK has an associated Linux process with a unique UID! o There's usually 1 thread per process! Terminology: Apps are characterized by Activities, Tasks, and Processes! o An Activity is a discrete chunk of functionality (concrete class that encapsulates some operation)! o A Task contains one or more Activities (a.k.a. an app)! o A Process is a Linux process!
Application Framework Terminology (2)! A process for a UID is launched "as needed"! o Binding to a Service or ContentProvider! o Launching an Activity! o Firing an IntentReceiver! Process runs until Android kills it to save memory! Each Activity has a managed lifecycle! o Started when requested! o Can lose focus or visibility if, e.g., a dialog box pops up, user launches another app! o Android nondeterministically kills Activity to free up memory!
Activity life cycle!
Android Application Security! As previously mentioned, each application has its own UID.! By default, an application has zero permissions. Must explicitly declare permissions in AndroidManifest.xml file! For instance, an app that monitors incoming SMS messages must put the following in that file:!! <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app..." > <uses-permission android:name="android.permission.receive_sms" /> </manifest> #! Each app must also be signed with a certificate for which the developer has the private key.!
Dalvik VM Overview! Motivation: VM must run with low memory, limited CPU power, no swap space, and while powered by a battery! While the Android SDK uses Java code, Java bytecode (.class files) and JAR archives are slightly bloated! Dalvik uses Dalvik EXecutable (.dex) custom bytecode to compress bytecode constants & data efficiently! Strategy: "Zygote" process launches at boot, maximizes shared memory! o Minimizes use of "dirty" heap memory by creating heap at boot, using shared memory as much as possible! o Zygote preloads common Android classes, libraries! o It listens for new processes and fork()s on demand! Garbage Collection - mark bits separated from object data!
Overview of Dalvik VM Compilation and Interpretation!
Dex overview! public static long sumarray(int[] arr) # { long sum = 0; # for (int i : arr) # { sum += i; }# return sum; }# #
.class bytecode output!! 25 bytes, 45 reads, 16 writes!! 0000: lconst_0# 0001: lstore_1 0002: aload_0 0003: astore_3 0004: aload_3 0005: arraylength# 0006: istore 04 0008: iconst_0# 0009: istore 05 000b: iload 05 // rl ws 000d: iload 04 // rl ws 000f: if_icmpge 0024 // rs rs 0012: aload_3 // rl ws 0013: iload 05 // rl ws 0015: iaload // rs rs ws 0016: istore 06 // rs wl 0018: lload_1 // rl rl ws 0019: iload 06 // rl ws# 001b: i2l // rs ws ws 001c: ladd // rs rs rs rs ws ws 001d: lstore_1 // rs rs wl wl // ws = write stack 001e: iinc 05, #+01 // rl wl 0021: goto 000b // rl = read local // wl = write local 0024: lload_1 0025: lreturn#
.dex bytecode output!! 18 bytes, 19 reads, 6 writes!! 0000: const-wide/16 v0, #long 0 0002: array-length v2, v8 0003: const/4 v3, #int 0 # 0004: move v7, v3 0005: move-wide v3, v0 0006: move v0, v7 0007: if-ge v0, v2, 0010 0009: aget v1, v8, v0 000b: int-to-long v5, v1 000c: add-long/2addr v3, v5 000d: add-int/lit8 v0, v0, #int 1 000f: goto 0007 0010: return-wide v3# #
Questions & Comments?!!! Thank you!!