The Android Framework

Here we have a simple diagram of the Android Framework. At the bottom we see (in red) the Linux kernel. Traditionally a Linux 2.6.x kernel with some additional architecture changes made by Google was used but since the launch of android 4.0 a Linux 3.x kernel is used.

Linux is used to interact with hardware via standard Linux drivers and provides a hardware abstraction layer to the rest of the framework. Linux also used to provide memory management, process management and security setting etc. As Linux runs on multiple devices, porting of android to new hardware remains relatively painless.

Libraries

The next layer is the Android’s native libraries. It is this layer that enables the device to handle different types of data. These libraries are written in C or C++ language and are specific for a particular hardware.

Some of the important native libraries include the following:

• 
  Surface Manager: It is used as a compositing window manager with off-screen buffering. Off-screen buffering means you can’t directly draw into the screen, but your drawings go to the off-screen buffer. There it is combined with other drawings and form the final screen the user will see. This off screen buffer is the reason behind the transparency of windows.
  

• 
  Media framework: Media framework provides different media codecs allowing the recording and playback of different media formats
  
• 
  SQLite: SQLite is the database engine used in android for data storage purposes
  
• 
  WebKit: It is the browser engine used to display HTML content
  
• 
  OpenGL: Used to render 2D or 3D graphics content to the screen
  

Android Runtime consists of Dalvik Virtual machine and Core Java libraries.

Dalvik is the process Java Virtual Machine in Google's Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers.

An app will typically be written in Java and compiled into Java Virtual Machine-compatible byte-code or “.class” files. Unlike the Oracle Java Virtual Machine, the Dalvik Virtual Machine doesn’t run .class files, instead it runs Dalvik Executable or “.dex” files. Much like an .exe in Microsoft Visual Studio, .dex files are built from .class file at the time of execution, using a “Just- In-Time” (JIT) compiler to convert the byte-code into machine code. This has been proven to provide higher efficiency in low resource environments. Also the Dalvik VM is register based while the Oracle JVM is stack based. Since the operands for instructions are largely implicit, the object code will tend to be smaller. This is important if you're going to be downloading the code over a slow network link.

Due to the virtual machine Android applications run in a sandbox, an isolated area of the system that does not have access to the rest of the system's resources, unless access permissions are explicitly granted by the user when the application is installed. Before installing an application, the Play Store displays all required permissions: a game may need to enable vibration or save data to an SD card, for example, but should not need to read SMS messages or access the phonebook. After reviewing these permissions, the user can choose to accept or refuse them, installing the application only if they accept.

The Dalvik VM also allows multiple instance of Virtual machine to be created simultaneously providing security, isolation, additional memory management and threading support.

Core Java Libraries

Android is based on Apache Harmony developed by the Apache Software Foundation, a clean room implementation of the Java class libraries. These are different from Java SE and Java ME libraries. However these libraries provide most of the functionalities defined in the Java SE libraries.

(Oracle recently sued Google for copyright infringement. Oracle where awarded an agreed settlement of £0 for a total of nine copied lines but lost the case).

Application Framework

These are the blocks that applications directly interact with. These programs manage the basic functions of a phone like resource management or voice call management for example.

Important blocks of Application framework are:

• 
  Activity Manager: Manages the activity life cycle of applications
  
• 
  Content Providers: Manage the data sharing between applications
  
• 
  Telephony Manager: Manages all voice calls. Telephony manager is also used to provide access voice calls in applications.
  
• 
  Location Manager: Location management, using GPS or cell tower
  
• 
  Resource Manager: Manage the various types of resources we use in our Application
  

Applications are the top layer in the Android architecture and this is where apps fit. Several standard applications come pre-installed with every device, such as:

• 
  SMS client app
  
• 
  Dialer
  
• 
  Web browser
  
• 
  Contact manager
  

When you install Linux on a desktop PC, you normally choose from among a few "standard" graphics support components. You'll likely use the X Window system as the display interface foundation (with associated Linux drivers to control the hardware) .

“But how does it work?”

X uses a client–server model: an X server communicates with various client programs. That is to say in X windows the users terminal acts as the server and the applications are the clients—this often confuses new X users, because the terms appear reversed. But X takes the perspective of the application, rather than that of the end-user: X provides display and I/O services to applications, so it is a server; applications use these services, thus they are clients.

X uses a client–server model: an X server communicates with various client programs. The server accepts requests for graphical output (windows) and sends back user input (from keyboard, mouse, or touch-screen). The server may function as:

• 
  An application displaying to a window of another display system
  
• 
  A system program controlling the video output of a PC
  
• 
  A dedicated piece of hardware.
  

But the typical desktop Linux "graphics stack" isn't well suited to embedded Linux applications. As we can see Embedded devices frequently have highly constrained resources and can afford neither the program storage space nor the memory footprint of desktop graphics software. For example, embedded devices may easily have as little as 2 to 16 MB of Flash disk from which to load programs, and 4 to 32 MB of RAM memory in which to run them. But the typical desktop graphics components are notorious resource hogs (see table)

All that memory costs money, requires board space, and consumes power. Then too, embedded systems frequently have unique needs that can't be met by desktop graphics system components. These include the requirement for a customized look and feel, control over what functions are available to users, speed of loading, unusual display or input device characteristics, etc.

To satisfy the demands of the rapidly emerging embedded Linux marketplace, a growing number of graphics support projects and products have sprung up. Targeted environments run the full gamut -- including fixed, portable, and mobile systems -- and the applications range from hand-held consumer products like PDAs and cell phones, to medical instruments, factory automation, and commercial airlines cockpit displays.