[In this chapter from Apress' Beginning Android Games, you'll learn the basics of developing games for Android devices. Visit apress.com <http://www.apress.com/> to check out the full book and many more game development titles.]
As a kid of the early nineties, I naturally grew up with my trusty Nintendo Game Boy. I spent countless hours helping Mario rescue the princess, getting the highest score in Tetris, and racing my friends in RC Pro-Am via link cable. I took this awesome piece of hardware with me everywhere and every time I could. My passion for games made me want to create my own worlds and share them with my friends. I started programming on the PC, but soon found out that I couldn't transfer my little masterpieces to the Game Boy. I continued being an enthusiastic programmer, but over time my interest in actually playing video games faded. Also, my Game Boy broke . . .
Fast forward to 2010. Smartphones are becoming the new mobile gaming platforms of the era, competing with classic dedicated handheld systems such as the Nintendo DS or the Playstation Portable. That caught my interest again, and I started investigating which mobile platforms would be suitable for my development needs. Apple's iOS seemed like a good candidate to start coding games for. However, I quickly realized that the system was not open, that I'd be able to share my work with others only if Apple allowed it, and that I'd need a Mac to develop for the iOS. And then I found Android.
I immediately fell in love with Android. Its development environment works on all the major platforms, no strings attached. It has a vibrant developer community happy to help you with any problem you encounter as well as comprehensive documentation. I can share my games with anyone without having to pay a fee to do so, and if I want to monetize my work, I can easily publish my latest and greatest innovation to a global market with millions of users in a matter of minutes.
The only thing I was left with was actually figuring out how to write games for Android and how to transfer my PC game development knowledge to this new system. In the following chapters, I want to share my experience with you and get you started with Android game development. This is of course a rather selfish plan: I want to have more games to play on the go!
Let's start by getting to know our new friend: Android.
Fragmentation
The great flexibility of Android comes at a price: companies that opt to develop their
own user interfaces have to play catch-up with the fast pace at which new versions of Android are released. This can lead to handsets not older than a few months becoming outdated really fast as carriers and handset manufacturers refuse to create updates that incorporate the improvements of new Android versions. The big bogeyman called fragmentation is a result of this process.
Fragmentation has many faces. For the end user, it means being unable to install and
use certain applications and features because of being stuck on an old Android version. For developers, it means that some care has to be taken when creating applications that should work on all versions of Android. While applications written for earlier versions of Android will usually run fine on newer versions, the reverse is not true. Some features added in newer Android versions are of course not available on older versions, such as multi-touch support. Developers are thus forced to create separate code paths for different versions of Android.
But fear not. Although this sounds terrifying, it turns out that the measures that have to be taken are minimal. Most often, you can even completely forget about the whole issue and pretend there's only a single version of Android. As game developers, we're less concerned with differences in APIs and more concerned about hardware capabilities. This is a different form of fragmentation, which is also a problem for platforms such as iOS, albeit not as pronounced. Throughout this book, I will cover the relevant fragmentation issues that might get in your way while you develop your next game for Android.
Android's Features and Architecture
Android is not just another Linux distribution for mobile devices. While you develop 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 providing a rich set of APIs to create 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 our game development adventures.
- APIs for accessing peripherals such as the camera, Global Positioning System (GPS), compass, accelerometer, touch screen, trackball, and keyboard. Note that not all Android devices have all of these peripherals-hardware fragmentation in action.
There's of course a lot more to Android than the few features I just mentioned. For our game development needs, these features are the most relevant, though.
Android's architecture is composed of a stack of components, and each component 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 from 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 is responsible for spawning and running Android applications. Each Android application is run in its own process with its own Dalvik virtual machine.
Dalvik runs programs in the DEX bytecode format. Usually you transform common lava .class files to the DEX format via a special tool called dx that is provided by the software development kit. The DEX format is designed to have a smaller memory footprint compared to classic Java .class files. This is achieved by heavy compression, tables, and merging of multiple .class files.
The Dalvik virtual machine interfaces with the core libraries, which provide the basic functionality exposed to Java programs. The core libraries provide some but not all of the classes available in Java 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 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 introduces a tracing JIT compiler, which compiles parts of the bytecode to machine code on the fly. This increases the performance of computationally intensive applications considerably. The JIT compiler can use CPU features specifically tailored for special computations such as a dedicated Floating Point Unit (FPU).
Dalvik also has an integrated garbage collector (GC). It's a mark-and-sweep nongenerational GC that has the tendency to drive developers a tad bit mad at times.
With some attention to details, you can peacefully coexist with the GC in your day-today game development, though. The latest Android release (2.3) has an improved concurrent GC, which relieves some of the pain. We'll investigate GC issues in more detail later in the book.
Each application running in an instance of the Dalvik VM has a total of 16MB to 24MB of heap memory available. We'll have to keep that in mind as we juggle our image and audio resources.
