Patrick Brady of Google's partner group provided a detailed technical tour of the internals of the Android platform during his recent talk at Google I/O 2008 titled "Anatomy and Physiology of an Android". Topics included Linux kernel enhancements, the Bionic library (Google's slimmed down version of libc), Android functional and runtime libraries, native servers, and more.
At its foundation, Android is based on Linux 2.6.4. Patrick said they would stay with that release until there was some reason to move. Google made a number of kernel enhancements for Android including: alarm, ashmem, binder, power management, low memory killer, kernel debugger, and logger. All the kernel enhancements have been contributed back to the community under the GNU Public License (GPL), so if you're interested in looking at the code you can find the source repository at http://git.android.com .
Google developed a custom library for the C compiler (libc) called Bionic. This was necessary for three main reasons:
- License: they wanted to keep GPL out of user-space. Bionic code uses the BSD license.
- Size: the library has to be loaded in each process, so it needs to be small. Bionic is about 200K, or half the size of glibc (the GNU version of libc).
- Speed: limited CPU power means it needs to be fast. Bionic has a small size and fast code paths, including a very fast and small custom pthread implementation.
Bionic has built-in support for important Android-specific services such as system properties and logging. It doesn't support certain POSIX features, like C++ exceptions and wide chars, which were not needed on Android. Thus it's not quite compatible with the gnu libc. All native code must be compiled against bionic, not glibc.
Android includes the WebKit browser engine, which Patrick described as "the best browser engine available today". They made a few enhancements to WebKit, including support for single column and adaptive view rendering, which were contributed back to the community.
Android's media framework is based on the PacketVideo OpenCORE platform. It can play standard video, audio, and still-frame formats. It has support for hardware / software codec plug-ins through a standard provided by the Khronos group. According to Google, even the Android emulator uses these codecs (as opposed to short-circuiting to the underlying operating system).
For a light-weight transactional data store, Android uses a public domain program called SQLite. This is the back end for most of the platform's data storage, including content providers for contacts, mms, sms, etc..
Surface flinger is a system-wide surface composer, handling all surface rendering to frame buffer device. It can combine 2d and 3d surfaces and surfaces from multiple applications. Surfaces are passed as buffers via binder interprocess (IPC) calls. It can use OpenGL ES and 2d hardware acceleration for its compositions. Surface flinger uses double-buffering using page-flips. System integrators can plug in hardware acceleration using a plug-in standard from Khronos.
Audio flinger manages all audio output devices. It processes multiple audio streams into PCM audio, and handles audio routing to various outputs (earpiece, speaker, Bluetooth).
Hardware abstraction libraries
There is a user space C/C++ library that provides an interface that Android requires hardware drivers to implement. It separates the Android platform logic from the hardware interface. The goal is to make porting onto real hardware easier.
[ For higher resolution pictures see my Google I/O photo set on flickr. ]
You may be wondering why Android needs another user-space HAL? Not all components have standardized kernel driver interfaces. Also, Linux kernel drivers are GPL which might expose proprietary IP. Handset manufacturers and chipset manufacturers told Google that they wanted the option to keep some things closed source, and GPL doesn't allow that.
The runtime sits on top of the system libraries and kernel. It provides the Dalvik virtual machine and core libraries.
Dalvik is Android's custom clean-room virtual machine implementation. It provides application portability and runtime consistency. Dalvik runs an optimized file format (.dex) containing Dalvik bytecode. Java .class / .jar files can be converted to .dex files at build time, allowing reuse of existing Java code.
Designed specifically for embedded environments, Dalvik supports multiple VM processes per device. It uses a highly CPU optimized bytecode interpreter, and it takes great pains to use runtime memory very efficiently. (Dan Bornstein gave a more detailed talk on Dalvik later in the conference.)
The core libraries consist of APIs for Java language programs. This provides powerful, simple, familiar development facilities for data structures, utilities, file access, network access, graphics, etc..
The application framework sits on top of the system libraries, core libraries, and Dalvik. This is where you'll find the core platform services, application lifecycle, package management, resource management, and more. (Dan Morrill gave a talk on this framework later in the conference.)
For the second part of the talk Patrick walked through the Android startup process, including standard Linux parts like init and the Android-specific parts like "zygote": a pre-warmed VM process that is forked for every new Dalvik process. See the on-line video of Patrick's presentation when it becomes available at the Google I/O web site if you want more details on this, since it's hard to convey in words.