Android's Features and Architecture

Android is not just another Linux distribution for mobile devices. While developing for Android, you're not all that likely to meet the Linux kernel itself. The developer-facing side of Android is a platform that abstracts away the underlying Linux kernel and is programmed via Java. From a high-level view, Android possesses several nice features:

• An application framework that provides a rich set of APIs for creating various types of applications. It also allows the reuse and replacement of components provided by the platform and third-party applications.
• The Dalvik virtual machine, which is responsible for running applications on Android.
• A set of graphics libraries for 2D and 3D programming.
• Media support for common audio, video, and image formats, such as Ogg Vorbis, MP3, MPEG-4, H.264, and PNG. There's even a specialized API for playing back sound effects, which will come in handy in your game development adventures.
• APIs for accessing peripherals such as the camera, Global Positioning System (GPS), compass, accelerometer, touchscreen, trackball, keyboard, controller, and joystick. Note that not all Android devices have all these peripherals—hardware fragmentation in action.

Of course, there's a lot more to Android than the few features just mentioned. But, for your game development needs, these features are the most relevant.

Android's architecture is composed of stacked groups of components, and each layer builds on the components in the layer below it. Figure 1–1 gives an overview of Android's major components.

Figure 1–1. Android architecture overview

The Kernel

Starting at the bottom of the stack, you can see that the Linux kernel provides the basic drivers for the hardware components. Additionally, the kernel is responsible for such mundane things as memory and process management, networking, and so on.

The Runtime and Dalvik

The Android runtime is built on top of the kernel, and it is responsible for spawning and running Android applications. Each Android application is run in its own process with its own Dalvik VM.

Dalvik runs programs in the DEX bytecode format. Usually, you transform common Java .class files into DEX format using a special tool called dx, which is provided by the software development kit (SDK). The DEX format is designed to have a smaller memory footprint compared to classic Java .class files. This is achieved through heavy compression, tables, and merging of multiple .class files.

The Dalvik virtual machine interfaces with the core libraries, which provide the basic functionality that is exposed to Java programs. The core libraries provide some, but not all, of the classes available in Java Standard Edition (SE) through the use of a subset of the Apache Harmony Java implementation. This also means that there's no Swing or Abstract Window Toolkit (AWT) available, nor any classes that can be found in Java Micro Edition (ME). However, with some care, you can still use many of the third-party libraries available for Java SE on Dalvik.

Before Android 2.2 (Froyo), all bytecode was interpreted. Froyo introduced a tracing JIT compiler, which compiles parts of the bytecode to machine code on the fly. This considerably increases the performance of computationally intensive applications. The JIT compiler can use CPU features specifically tailored for special computations, such as a dedicated Floating Point Unit (FPU). Nearly every new version of Android improves upon the JIT compiler and enhances performance, usually at the cost of memory consumption. This is a scalable solution, though, as new devices contain more and more RAM as standard fare.

Dalvik also has an integrated garbage collector (GC). It's a mark-and-sweep, nongenerational GC that has the tendency to drive developers a little crazy at times. With some attention to detail, though, you can peacefully coexist with the GC in your day-to-day game development. The latest Android release (2.3) has an improved concurrent GC, which relieves some of the pain. You'll get to investigate GC issues in more detail later in the book.

Each application running in an instance of the Dalvik VM has a total of at least 16MB of heap memory available. Newer devices, specifically tablets, have much higher heap limits to facilitate higher-resolution graphics. Still, with games it is easy to use up all of that memory, so you have to keep that in mind as you juggle your image and audio resources.

System Libraries

Besides the core libraries, which provide some Java SE functionality, there's also a set of native C/C++ libraries (second layer in Figure 1–1), which build the basis for the application framework (third layer in Figure 1–1). These system libraries are mostly responsible for the computationally heavy tasks that would not be as well suited to the Dalvik VM, such as graphics rendering, audio playback, and database access. The APIs are wrapped by Java classes in the application framework, which you'll exploit when you start writing your games. You'll use the following libraries in one form or another:

Skia Graphics Library (Skia): This 2D graphics software is used for rendering the UI of Android applications. You'll use it to draw your first 2D game.

OpenGL for Embedded Systems (OpenGL ES): This is the industry standard for hardware-accelerated graphics rendering. OpenGL ES 1.0 and 1.1 are exposed to Java on all versions of Android. OpenGL ES 2.0, which brings shaders to the table, is only supported with Android 2.2 (Froyo) onward. It should be mentioned that the Java bindings for OpenGL ES 2.0 in Froyo are incomplete and lack a few vital methods. Fortunately, these methods were added in version 2.3. Also, the emulator and some of the older devices, which still make up a small share of the market, do not support OpenGL ES 2.0. For your purposes, stick with OpenGL ES 1.0 and 1.1, to maximize compatibility and allow you to ease into the world of Android 3D programming.

OpenCore: This is a media playback and recording library for audio and video. It supports a good mix of formats such as Ogg Vorbis, MP3, H.264, MPEG-4, and so on. You'll mostly deal with the audio portion, which is not directly exposed to the Java side, but rather wrapped in a couple of classes and services.

FreeType: This is a library used to load and render bitmap and vector fonts, most notably the TrueType format. FreeType supports the Unicode standard, including right-to-left glyph rendering for Arabic and similar special text. Sadly, this is not entirely true for the Java side, which still does not support Arabic typography. As with OpenCore, FreeType is not directly exposed to the Java side, but is wrapped in a couple of convenient classes.

These system libraries cover a lot of ground for game developers and perform most of the heavy lifting. They are the reason why you can write your games in plain old Java.

The Application Framework

The application framework ties together the system libraries and the runtime, creating the user side of Android. The framework manages applications and provides an elaborate structure within which applications operate. Developers create applications for this framework via a set of Java APIs that cover such areas as UI programming, background services, notifications, resource management, peripheral access, and so on. All out-of-the-box core applications provided by Android, such as the mail client, are written with these APIs.

Applications, whether they are UIs or background services, can communicate their capabilities to other applications. This communication enables an application to reuse components of other applications. A simple example is an application that needs to take a photo and then perform some operations on it. The application queries the system for a component of another application that provides this service. The first application can then reuse the component (for example, a built-in camera application or photo gallery). This significantly lowers the burden on programmers and also enables you to customize myriad aspects of Android's behavior.

As a game developer, you will create UI applications within this framework. As such, you will be interested in an application's architecture and life cycle, as well as its interactions with the user. Background services usually play a small role in game development, which is why they will not be discussed in detail.