The Android Framework

convertingtownSoftware and s/w Development

Nov 4, 2013 (4 years and 8 days ago)

457 views

The Android Framework

Linux

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 secur
ity 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. Thes
e 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 bufferi
ng 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 di
splay HTML content



OpenGL:

Used to render 2D or 3D graphics content to the screen

Android Runtime

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

Dalvik Virtual Machine

Dalvik is the process
Java V
irtual
M
achine 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 r
un .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 small
er. 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 machi
ne to be created simultaneousl
y
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
s
ettlement 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 manageme
nt

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.
T
elephony manager
i
s
also
used
to
provide
access voice calls in application
s
.



Location Manager:

Location management, using GPS or cell tower



Resource Manager:

Manage the various types of resources we use in our Application

Applications

Applications are the top layer in the A
ndroid architecture and this is
w
here app
s

fit. Sev
eral
standard applications come

pre
-
instal
led with every device, such as:



SMS client app



Dialer



Web browser



Contact manager

It is also possible
to write an app which replace
s

any existing system app. That is, you are
not limited in accessing any particular feature. You are practically limitless and can
so
whatever you want to do with android (as long as the user

of

an

app permits it).
So Android
open
s
endless opportunities
for

developer
s.



Embedded Linux Graphics

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 oft
en 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.

X only provides a protocol and graphics primitive definitions. It deliberately contains no
specification for u
ser interface design, such as buttons, menus, or window title bar styles.
Instead, application software


such as window managers (twm in X Windows), GUI widget
toolkits (GTK+) and desktop environments (GNOME), or application
-
specific graphical user
interf
aces


define and provide such details. As a result, there is no typical X interface and
several desktop environments have been popular among users.

But the typical desktop Linux "graphics stack" isn't well suited to embedded Linux
applications. As we ca
n 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 a
re notorious resource hogs (see table)

All that memory costs money, requires board space, and consumes power. Then too,
embedded s
ystems 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 appli
cations
range from hand
-
held consumer products like PDAs and cell phones, to medical instruments,
factory automation, and commercial airlines cockpit displays.

Dillo

--

Dillo is a very small (less than 300KB), fast, Open Source multi
-
platform web
browser t
hat's written completely in C and built on GTK+ libraries. Dillo's high efficiency and
minimal library dependencies make it quite suitable for embedded apps. Dillo can be teamed
up with an embedded webserver to completely eliminate the need for a window ma
nager in
an embedded device.


DirectFB

--

DirectFB is a thin library that provides developers with hardware graphics
acceleration, input device handling and abstraction, integrated windowing system with
support for translucent windows and multiple display
layers on top of the Linux Framebuffer
Device. It is a complete hardware abstraction layer with software fallbacks for every
graphics operation that is not supported by the underlying hardware.


The Familiar Project

--

this open source PDA Linux project, w
hich is an offshoot of the
activities at handhelds.org, has collected together all of the key components of a complete
Linux
-
based PDA computing platform. The Familiar distribution currently includes a
Blackbox
-
based window manager, Agenda Computing's Fltk
+ based PIM applications, an
embedded Python implementation, system configuration and settings backup utilities,
OpenSSH client and server, and a Debian
-
based ARM kernel.


FBUI

--

FBUI is a tiny GUI that resides inside the Linux kernel. The key concepts of

FBUI
are that firstly it is small; secondly that it is spartan, which is good; thirdly that it is just
another driver; and fourthly that drivers belong in the kernel, not in userspace.


GGI project

--

the "General Graphics Interface" project is dedicated
to development of
fast, stable, open
-
source cross
-
platform multimedia API systems. Designed from the ground
up with environments such as embedded systems in mind, GGI is fast, clean, abstract,
dynamically modular and highly optimizeable.


GPE Palmtop Envir
onment

--

this project aims to provide a Free Software GUI
environment for palmtop/handheld computers running the GNU/Linux operating system.
GPE uses the X Window System, and the GTK+ widget toolkit.


GtkFB

--

beginning with version 2.0, GTK+ will support

rendering directly to the Linux
framebuffer instead of using the X Window System. This is good for embedded systems and
devices with limited resources, because it eliminates the overhead of an X server, while still
taking advantage of the power of GTK+ an
d the large base of existing programs.


handhelds.org PDA support

--

want to create your own unique Linux PDA
implementation? handhelds.org is for you! Early this year, Compaq created the Open
Handheld Program, an initiative designed to stimulate innovatio
n and research on handheld
devices that resulted from the company's "Itsy" pocket computer project. To support this
initiative, Compaq created handhelds.org
--

a vendor neutral website dedicated to open
source handheld development. Not surprisingly, Compaq
's iPAQ PDA is used as the base
platform for all these activities and, consequently, a iPAQ Linux port is available as freely
available open source software.


Matchbox



(
The Nokia 770 and N800 Linux based internet tablets use Matchbox window
manager as part of the Maemo platform used on the devices
)
.
A

small foot
-
print window
manager and associated applications, designed specifically for resource
-
constrained X11
-
enabled de
vices such as handheld computers, PDA's, set
-
top boxes, and consumer devices
where display size, storage, CPU bandwidth, and input mechanisms are limited. Matchbox
includes a window manager, a panel, a desktop, a shared utility library, and a number of
sma
ll panel applications.


Microwindows

--

an Open Source project aimed at bringing the features of modern
graphical windowing environments to smaller devices and platforms. Microwindows
applications can be built and tested on the Linux desktop, as well as cr
oss
-
compiled for the
target device.


NxZilla

(formerly nanozilla)
--

a set of libraries that allow Mozilla to be used with a NanoX
server from the Microwindows project.


OpenGL ES

--

a light
-
weight, royalty
-
free embedded graphics standard that provides
gr
aphics API profiles for a broad range of embedded systems and devices, including
handheld wireless devices, automotive and avionics displays, and multimedia consumer
devices such as advanced digital TVs, set
-
top boxes, and game consoles.


OpenGUI

--

a fast
, 32
-
bit, high
-
Level C/C++ graphics & windowing library/GUI built upon a
fast, low
-
level x86 asm graphics kernel. It is under LGPL license. OpenGUI provides 2D
drawing primitives and an event
-
driven windowing API for easy application development.


PicoGUI

--

small, portable client/server GUI designed to work on many types of hardware
including handheld computers. Like the X Window System, it has a flexible client
-
server
architecture. Unlike X, however, fonts, bitmaps, widgets, and anything else the applicat
ion
needs are built directly into the server. This sacrifices a small decrease in flexibility for an
increase in speed and a large decrease in size.


Qt/Embedded

--

provides a full graphics stack, from the hardware interface to a full GUI
too
l
kit. Although the API is identical to the popular Qt/X11 and Qt/Windows products,
Qt/Embedded is not based on X11 and therefore it has substantially reduced memory
requirements. Memory demands can be tuned to the range of 800 KB to 3 MB in ROM (Intel
x86).

Qt/Embedded is available as open source software, under the GNU General Public
License (GPL), or can be licensed on other terms from its originator, Trolltech.


Simple DirectMedia Layer

--

an open source cross
-
platform multimedia development
API/library
designed to provide fast access to the graphics framebuffer and audio device.
SDL is currently being applied to a number of Embedded Linux implementations such as
Microwindows.


Tiny
-
X

--

a small footprint X Window server implementation for embedded system
s. It was
developed by Keith Packard of the XFree86 Core Team, sponsored by SuSE. The goal was to
create something that would work well in a small memory footprint and, importantly, be
robust in near out
-
of
-
memory situations. Typical X servers based on Tin
y
-
X can fit in less
than 1MB on x86 CPUs. The project has since forked into several projects,
including

KDrive
,

SmallX
, and

Integrated Tiny
-
X
.



ViewML

--

a freely available, open source web browser targeted specifically at the
embedded Linux platform. Currently, ViewML along with it's interface requir
es 2.1 MB of
RAM, with a disk image of only 760K.


WML Browser

--

a project, sponsored by 5NINE to develop a browser which will allow any
wireless device to have WAP functionality.

It must support multiple protocol stacks (WAP
1.2.1, http), in differing environments, using differing input devices. The browser will work
with framebuffer graphics.
--

detai
ls


Xynth Windowing System

--

a free software project to build a portable, embedded client
-
server windowing system. The Xynth Windowing System, released under the GPL, offers a
lightweight GUI
-
capable windowing system usable in Linux
-
based embedded systems

and
devices, such as handhelds and set
-
top boxes.

details