You are on page 1of 6

Chapter 2.

The Stack
Stack Overview
Android operating system is like a cake consisting of various layers. Each layer has its own
characteristics and purpose. The layers are not cleanly separated but often seep into each
other.When you read through this, keep in mind that I am only concerned with the big picture
of the entire system and will get into the nitty-gritty details of particular parts of the system
later on. Figure 2.1, Android Stack shows the parts of the Android stack.
Figure 2.1. Android Stack

Linux
Android is built on top of Linux. Linux is a great operating system and a poster child of open
source. There are many good reasons for choosing Linux as the base of the Android stack.
Some of the main ones are portability, security, and features.

Portability
Linux is a portable platform relatively easy to compile on various hardware architectures.
What Linux brings to Android is a level of hardware abstractions. By basing Android on
Linux, we dont have to worry too much about underlying hardware features. Most of low
level parts of Linux have been written in fairly portable C code, which allows for third-parties
to port Android to variety of devices.

Security
Linux is a highly secure system, having been tried and tested through some very harsh
environments over the decades. Android heavily relies on Linux for security. All Android
applications run as separate linux processes with permissions set by the Linux system. As
such, Android passes a lot of security concerns to the underlying Linux system.

Features
Linux comes with a lot of very useful features. Android leverages many of them, such as
support for memory management, power management, and networking.

Native Libraries
Native libraries are C/C++ libraries often taken from the open source community in order to
provide necessary services to Android application layer. They include:

WebKit: a fast web rendering engine used by Safari, Chrome, and other browsers
SQLite: a full-featured SQL database

Apache Harmony: an open source implementation of Java

OpenGL: 3D graphics libraries

OpenSSL: the secure socket layer

and many others

While many of these libraries are taken as-is, one notable exception is Bionic. Bionic is
basically a rewritten version of Standard C Library. The reason for Bionic is two fold:

Technology: to make it purpose-built for tiny battery powered devices


License: to make it license-friendly to others who may want to adopt it and change it

Tip
GNU libc, the default C library for Linux, is licensed under GPL license which requires any
changes that you release publicly to be pushed back to open source community. As such, it
may not be the most business-friendly open source license in case when a company wants to
keep their derivative work proprietary. Bionic, on the other hand, is licensed under
Apache/MIT license which doesnt require derivative works to be open sourced.

Dalvik
Dalvik is a purpose-built virtual machine designed specifically for Android. It is developed
by Dan Bornstein and his team at Google.
While the Java virtual machine (VM) was designed to be a one-size-fits-all solution, the
Dalvik team felt they could do a better job by focusing strictly on mobile devices. They
looked at which of the constraints specific to a mobile environment are least likely to change
in the near future. One of these is battery life, and the other is processing power. Dalvik was
built from ground up to address those constraints.
Another side effect of replacing the Java VM with Dalvik VM is the licensing. While the Java
language, Java tools and Java libraries are free, the Java virtual machine is not. This was
more of an issue back in 2005 when the work on Dalvik started. Nowadays, there are open
source alternatives to Suns Java VM, namely OpenJDK and Apache Harmony projects.

By developing a truly open-source and license-friendly virtual machine, Android yet again
provides a full-featured platform that others are encouraged to adopt for variety of devices
without having to worry about the license.

Android and Java


Figure 2.2. Java versus Dalvik

In Java, you write your Java source file, you compile it into a Java byte code using Java
compiler and you run this byte code on the Java Virtual Machine. In Android things are
different. You still write the Java source file and you still compile it to Java byte code using
the same Java compiler. But at that point, you recompile it once again using Dalvik compiler
to Dalvik byte code. It is Dalvik byte code that is then executed on Dalvik virtual machine.

Important
It may sound like you have to do a lot more work with Android when it comes to Java.
However, all these compilation steps are automated by tools such as Eclipse or ant and you
never notice the additional steps.
You may wonder why not compile straight from Java into the Dalvik byte code. There are
couple of good reasons for that. Back in 2005 when work on Dalvik started, the Java
language was going through frequent changes. But the Java byte code was more or less set in
stone. So, the Android team chose to base Dalvik on Java byte code instead of Java source
code.

A side effect of this is that in theory you could write Android applications in any other
language that compiles down to Java byte code. For example, you could use Python or Ruby.
I say in theory because in practice youd still need appropriate libraries that are part of the
SDK to be available. But it is likely that the open source community will come up with
solution to that in the future.
Another thing to keep in mind is that Android Java is a non-standard collection of Java
classes. Java typically ships in:

Java Standard Edition: used for development on basic desktop-type applications.


Java Enterprise Edition (aka J2EE or JavaEE): used for development of enterprise
applications.

Java Micro Edition (aka J2ME or JavaME): Java for mobile applications.

Androids Java set of libraries is closest to Java Standard Edition. The major difference is that
Java libraries for user interface (AWT and Swing) have been taken out and replaced with
Android-specific user interface libraries. Android also adds quite a few new features to
standard Java while supporting most of Javas standard features. So, you have most of your
favorite Java libraries at your disposal, plus many new ones.

App Framework
The application framework is a rich environment that provides numerous services to you, the
app developer, to get your job done. This is the part of the platform that is best documented
and extensively covered. That is because it is this layer that enables the mass-market of
developers to get creative and be empowered to create fantastic applications.
In application framework layer, you will find numerous Java libraries specifically built for
Android. You will also find many services (or managers) that provide the ecosystem of
capabilities your application can tap into, such as location, sensors, WiFi, telephony and so
on.
As you explore the Android application development, most of your focus will be on this part
of the stack. You will get to use many of the application framework components yourself.

Applications
And finally there are applications that you and other developers create. Applications are what
end users find valuable about Android. They can come pre-installed on the device or could be
downloaded from one of many Android markets.

The APK
An application is a single APK (application package) file. An APK file roughly has three
main components. It consists of all your Dalvik executable code (Java code compiled
automatically to Dalvik executable) plus all your resources (everything that is not code, such
as images, layouts, etc.). Additionally, it may contain some native code as well.

Dalvik executable: this is all your Java source code compiled down to Dalvik
executable. This is the code that runs your application.

Resources: resources are everything that is not code. Your application may contain
number of images, audio/video clips, as well as numerous XML files describing
layouts, language packs, and so on. Collectively, these items are resources.

Native libraries: optionally, your application may include some native code, such as
C/C++ libraries. These libraries could be packaged together with your APK file.

Application Signing
Android applications must be signed before they can be installed on a device. For
development purposes, well be signing applications with a debug key - a key that you
already have on your development platform. However, when you want to distribute your
application commercially, youll want to sign it with your own key. The details how to do that
are at Signing Your Application page. Well also discuss it in Going Live chapter.

App Distribution
One place Android is quite different than other platforms is the distribution of the apps. On
most other platforms, such as iPhone, a single vendor has the monopoly over the distribution
of applications. On Android, there can be many different Android stores or markets. Each one
can have its own set of policies with respect to what is allowed, how the revenue is split, and
so on. As such, Android is much more of a free market space with vendors competing for
business.
In practice, the biggest market currently is Android Market run by Google. It is unclear if
Googles motivation is to just seed the market space while other stores develop, or they will
strive to make it a profitable venture for them.
Applications can also be distributed via the web. When you download an APK file from a
website by using the Browser, the application represented by the APK file automatically gets
installed on your phone.
What about viruses, malware, spyware and other bad things?
With its decentralized application distribution system, it is certainly possible for an
unsuspecting user to download a malicious app and have it do bad things. There have been
reports of phishing attacks via fake banking apps.
So, Android leaves it to the market place to sort it out. Eventually, if you believe in free
market, there will be stores that are more reputable and those that are less so. For example,
Google polices its Android Market by removing malicious apps, such as the fake banking
apps. Google relies on users to report malicious apps. Other stores may choose to do more
proactive testing and raise the bar on what gets into the store in the first place.

Summary
In this chapter, you got a big picture overview of what Android operating system comprises
of and how various pieces fit together. You now understand what makes Android so complete,
open and attractive to developers.
In the next chapter, well look at how to setup your development environment so you can
quickly get up to speed. Well also look at a simple Hello World application and dissect it so
that you get the understanding of various pieces of an application.

You might also like