Difference between revisions of "An Overview of the Android Architecture (Android Studio)"

Revision as of 18:08, 14 April 2014

So far in this book, steps have been taken to set up an environment suitable for the development of Android applications using Android Studio. An initial step has also been taken into the process of application development through the creation of a simple Android Studio application project.

Before delving further into the practical matters of Android application development, however, it is important to gain an understanding of some of the more abstract concepts of both the Android SDK and Android development in general. Gaining a clear understanding of these concepts now will provide a sound foundation on which to build further knowledge. Starting with an overview of the Android architecture in this chapter, and continuing in the next few chapters of this book, the goal is to provide a detailed overview of the fundamentals of Android development.

The Android Software Stack

Android is structured in the form of a software stack comprising applications, an operating system, run-time environment, middleware, services and libraries. This architecture can, perhaps, best be represented visually as outlined in Figure 6-1. Each layer of the stack, and the corresponding elements within each layer, are tightly integrated and carefully tuned to provide the optimal application development and execution environment for mobile devices.

Figure 6-1

The remainder of this chapter will work through the different layers of the Android stack, starting at the bottom with the Linux Kernel.

The Linux Kernel

Positioned at the bottom of the Android software stack, the Linux Kernel provides a level of abstraction between the device hardware and the upper layers of the Android software stack. Based on Linux version 2.6, the kernel provides preemptive multitasking, low-level core system services such as memory, process and power management in addition to providing a network stack and device drivers for hardware such as the device display, Wi-Fi and audio.

The original Linux kernel was developed in 1991 by Linus Torvalds and was combined with a set of tools, utilities and compilers developed by Richard Stallman at the Free Software Foundation to create a full operating system referred to as GNU/Linux. Various Linux distributions have been derived from these basic underpinnings such as Ubuntu and Red Hat Enterprise Linux.

It is important to note, however, that Android only uses the Linux kernel. That said, it is worth noting that the Linux kernel was originally developed for use in traditional computers in the form of desktops and servers. In fact, Linux is now most widely deployed in mission critical enterprise server environments. It is a testament to both the power of today’s mobile devices and the efficiency and performance of the Linux kernel that we find this software at the heart of the Android software stack.

Android Runtime - Dalvik Virtual Machine

As previously noted, the Linux kernel provides a multitasking execution environment allowing multiple processes to execute concurrently. It would be easy to assume, therefore, that each Android application simply runs as a process directly on the Linux kernel. In fact, each application running on an Android device does so within its own instance of the Dalvik virtual machine (VM).

Running applications in virtual machines provides a number of advantages. Firstly, applications are essentially sandboxed, in that they cannot detrimentally interfere (intentionally or otherwise) with the operating system or other applications, nor can they directly access the device hardware. Secondly, this enforced level of abstraction makes applications platform neutral in that they are never tied to any specific hardware.

The Dalvik virtual machine was developed by Google and relies on the underlying Linux kernel for low-level functionality. It is more efficient than the standard Java VM in terms of memory usage, and specifically designed to allow multiple instances to run efficiently within the resource constraints of a mobile device.

In order to execute within a Dalvik VM, application code must be transformed from standard Java class files to the Dalvik executable (.dex) format, which has a 50% smaller memory footprint than standard Java bytecode. Standard Java class files can usually (though not always) be converted to Dex format using the dx tool included with the Android SDK.

Android Runtime – Core Libraries

The Android Core Libraries (also referred to as the Dalvik Libraries) fall into three main categories, each of which merits an individual description:

Dalvik VM Specific Libraries

This is a set of libraries used predominantly for interacting directly with an instance of the Dalvik VM and is unlikely to be used by most Android application developers.

Java Interoperability Libraries

Android applications are predominantly developed using the Java programming language. The Standard Java development environment includes a vast array of classes that are contained in the core Java runtime libraries. These libraries provide support for tasks such as string handling, networking and file manipulation (to name but a few) and are both familiar to, and widely used by Java developers regardless of platform.

The Java Interoperability Libraries are an open source implementation (based on the Apache Harmony project) of a subset of the Standard Java core libraries that have been adapted and transformed for use by applications running within a Dalvik VM.

Android Libraries

This category encompasses those Java-based libraries that are specific to Android development. Examples of libraries in this category include the application framework libraries in addition to those that facilitate user interface building, graphics drawing and database access.

A summary of some key core Android libraries available to the Android developer is as follows:

• android.app – Provides access to the application model and is the cornerstone of all Android applications.
• android.content – Facilitates content access, publishing and messaging between applications and application components.
• android.database – Used to access data published by content providers and includes SQLite database management classes.
• android.graphics – A low-level 2D graphics drawing API including colors, points, filters, rectangles and canvases.
• android.hardware – Presents an API providing access to hardware such as the accelerometer and light sensor.
• android.opengl – A Java interface to the OpenGL ES 3D graphics rendering API.
• android.os – Provides applications with access to standard operating system services including messages, system services and inter-process communication.
• android.media – Provides classes to enable playback of audio and video.
• android.net – A set of APIs providing access to the network stack. Includes android.net.wifi, which provides access to the device’s wireless stack.
• android.print – Includes a set of classes that enables content to be sent to configured printers from with Android applications.
• android.provider – A set of convenience classes that provide access to standard Android content provider databases such as those maintained by the calendar and contact applications.
• android.text – Used to render and manipulate text on a device display.
• android.util – A set of utility classes for performing tasks such as string and number conversion, XML handling and date and time manipulation.
• android.view – The fundamental building blocks of application user interfaces.
• android.widget - A rich collection of pre-built user interface components such as buttons, labels, list views, layout managers, radio buttons etc.
• android.webkit – A set of classes intended to allow web-browsing capabilities to be built into applications.

Having covered the Java-based core libraries in the Android runtime, it is now time to turn our attention to the C/C++ based libraries contained in this layer of the Android software stack.

C/C++ Libraries

The Android runtime core libraries outlined in the preceding section are Java-based and provide the primary APIs for developers writing Android applications. It is important to note, however, that the core libraries do not actually perform much of the actual work and are, in fact, essentially Java “wrappers” around a set of C/C++ based libraries. When making calls, for example, to the android.opengl library to draw 3D graphics on the device display, the library actually ultimately makes calls to the OpenGL ES C++ library which, in turn, works with the underlying Linux kernel to perform the drawing tasks. C/C++ libraries are included to fulfill a wide and diverse range of functions including 2D and 3D graphics drawing, Secure Sockets Layer (SSL) communication, SQLite database management, audio and video playback, bitmap and vector font rendering, display subsystem and graphic layer management and an implementation of the standard C system library (libc).

In practice, the typical Android application developer will access these libraries solely through the Java based Android core library APIs. In the event that direct access to these libraries is needed, this can be achieved using the Android Native Development Kit (NDK), the purpose of which is to call the native methods of non-Java programming languages (such as C and C++) from within Java code using the Java Native Interface (JNI).

Application Framework

The Application Framework is a set of services that collectively form the environment in which Android applications run and are managed. This framework implements the concept that Android applications are constructed from reusable, interchangeable and replaceable components. This concept is taken a step further in that an application is also able to publish its capabilities along with any corresponding data so that they can be found and reused by other applications.

The Android framework includes the following key services:

• Activity Manager – Controls all aspects of the application lifecycle and activity stack.
• Content Providers – Allows applications to publish and share data with other applications.
• Resource Manager – Provides access to non-code embedded resources such as strings, color settings and user interface layouts.
• Notifications Manager – Allows applications to display alerts and notifications to the user.
• View System – An extensible set of views used to create application user interfaces.
• Package Manager – The system by which applications are able to find out information about other applications currently installed on the device.
• Telephony Manager – Provides information to the application about the telelphony services available on the device such as status and subscriber information.
• Location Manager – Provides access to the location services allowing an application to receive updates about location changes.

Applications

Located at the top of the Android software stack are the applications. These comprise both the native applications provided with the particular Android implementation (for example web browser and email applications) and the third party applications installed by the user after purchasing the device.

Summary

A good Android development knowledge foundation requires an understanding of the overall architecture of Android. Android is implemented in the form of a software stack architecture consisting of a Linux kernel, a runtime environment and corresponding libraries, an application framework and a set of applications. Applications are predominantly written in Java and run within individual instances of the Dalvik virtual machine. The key goals of the Android architecture are performance and efficiency, both in application execution and in the implementation of reuse in application design.