A Seminar Report on:

Android OS
Prepared by : Ujjaval Jayantilal Vadvi
Roll. No.

: U13C0054

Class

: B.Tech IV (Computer Engineering) 7th Semester

Year

: 2016-17

Guided by : _Mr. BHAVESH GOHIL

Department of Computer Engineering

Sardar Vallabhbhai National Institute of Technology,
Surat -395007 (Gujarat), India

Sardar Vallabhbhai National Institute of Technology,

Surat -395007 (Gujarat), India

CERTIFICATE
This is to certify that the seminar report entitled Android OS
is prepared and presented by Mr. Ujjaval Jayantial Vadvi bearing
Roll No. : U13CO054, 4th

Year of B. Tech (Computer

Engineering) and his/her work is satisfactory.

GUIDE
(Prof Bhavesh
Gohil)

JURY(s)

HOD
COED

Index
Abstract....4
List of Images.......5
1. Introduction.....6
2. Android Architecture7
2.1 Levels of Android...7
2.2 Linux Kernel...8
2.3 Hardware Abstraction Layer...8
2.4 Libraries and Android Runtime...9
2.5 Android Framework10
3. Android vs Linux....11
3.1 Android vs Linux: Introduction...11
3.2 Android vs Linux: Core Differences...12
3.3 Dalvik Virtual Machine...13
3.4 The Dex File Format14
3.5 What is YAFFS?..............................................................................................15
4 Process and Power Management.16
4.1 Process Management: Principles..16
4.2 Process Management: Priority Hierarchy.16
4.3 Power Management..17

Abstract
This seminar is about Overviewing the latest Android Operating System. Analyze the Android OS
architecture and learning about the terms like YAFFS, Dalvik Virtual Machine and the Dex File Format. We
also will go through the process and power management of Android OS briefly

List of Figures

Figure 1 : Levels of Android N...7

Figure 2 : HAL......8
Figure 3 : Android Framework....10
Figure 4 : The Dex file format...13

Chapter 1
INTRODUCTION
Android is the flagship software of the Open Handset Alliance (OHA), established by Google with members
who are chip manufacturers, mobile handset makers, application developers or mobile carriers. Clockwise
development
Android was unveiled in 2007, along with the founding of the Open Handset Alliance a consortium of
hardware, software, and telecommunication companies devoted to advancing open standards for mobile
devices.

What is Android OS?

Android OS is an operating system that was developed by Google for use on mobile devices. This means
that it was designed for systems with little memory and a processor that isn't as fast as desktop processors.
While keeping the limitations in mind, Google's vision for Android is that it would have a robust set of
programming APIs and a very responsive UI. In order to facilitate this vision, they created an abstraction
layer, which allows application developers to be hardware agnostic in their design.

Android versions till date are as follows:Alpha(1.0), Beta(1.1), Cupcake(1.5), Donut(1.6), clair(2.0-2.1), Froyo(2.2-2.2.3), Gingerbread(2.3-2.3.7),
Honeycomb(3.0-3.2.6), Ice Cream Sandwich(4.0-4.0.4), Jelly bean(4.1-4.3.1), Kitkat(4.4-4.4.4),
Lollipop(5.0-5.1.1), Marshmallow(6.0-6.0.1), Nougat(7.0-7.1).

Chapter 2
Android architecture
2.1 Levels of Android Architecture

Fig 2.1:- levels of android architecture

( fig from https://source.android.com/index.html)

Binder IPC :The Binder Inter-Process Communication (IPC) mechanism allows the application framework to cross
process boundaries and call into the Android system services code. This enables high level framework APIs
to interact with Android system services

2.2 Linux Kernal

From the name, a kernel is a core of the operating system, the linux kernel is the core of the Android
operating system.

Functions of the linux kernal:1. The Linux kernel provides preemptive multitasking, low-level core system services such as memory
management and process management.
2. It also look after the power management and suspend mode powers down all hardware except
memory.
3. It is the one to approach for optimized power management when the os is suspended idle.
4. It also looks after the power management of the binder ipc driver.
5. in addition it provides a network stack and device drivers for hardware such as the device display,
Wi-Fi and audio

2.3 Hardware Abstraction Layer

Hardware Abstraction Layer is the standard interface layer between the APIs and the hardware drivers of
the Android OS
It has two componensts:
1. Module :Hardware abstraction layer implementations are in shared library modules i.e (.so) files
The modules are all dynamically linked
2. Device :It abstracts the actual hardware of the system

Fig 2.2 HAL (fig from https://source.android.com/devices)

The Hardware Abstraction Layer Implement functionality without modify higher levels. The hardware
abstraction layer (HAL) defines a standard interface for hardware vendors to implement and allows Android
to be agnostic about lower-level driver implementations.
(.so file). It contains metadata such as the version, name, and author of the module, which helps Android
find and load it correctly.
An audio module can contain a primary audio device, a USB audio device, or a Bluetooth A2DP audio
device. A device is represented by the hw_device_t struct. Like a module, each type of device defines a
more-detailed version of the generic hw_device_t that contains function pointers for specific features of the
hardware.
Each hardware-specific HAL usually extends the generic hw_module_t struct with additional information
for that specific piece of hardware. For example in the camera HAL, the camera_module_t struct contains
a hw_module_t struct along with other camera-specific function pointers

2.4 Libraries and Android Runtime

Libraries contains frameworks for web browser (webkit), database (SQLite), multimedia etc
Android Runtime environment
1. Core libraries:
a) Dalvik VM Specific Libraries
b) Java Interoperability Libraries
c) Android Libraries
2. Android Runtime: the managed runtime used by applications and some system services on Android
Execute the Dalvik Executable format and Dex bytecode specification.
Ahead-of-time compiled runtime
Modern garbage collection
Development and debugging improvements (Support for sampling profiler;
more debugging features; improved diagnostic detail in exceptions and crash reports.

2.5 Android Framework

A set of services that collectively form the environment in which Android applications run and are managed;
toolkit for applications

Includes the following key services:

Activity Manager - Manages 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, layout
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 - Maintains information on the available applications on the device.
Telephony Manager Provides information about the telephony services available
Windows Manager - Performs window management
Location Manager Provides access to the location services; GPS, Android Network provider

Fig 2.3 Android Framework (fig from http://www.justtotaltech.co.uk/blog/popular-android-app-developmentframework)

Chapter 3
Android vs. Linux

3.1 Android vs. Linux: Introduction

An effort initiated by Google to develop an OS for mobile devices

It is based on Linux kernel
Device drivers, network stack, power management and other core OS features are taken from Linux
Libraries added to enable applications to control the hardware more efficiently
It have a different Java Runtime Engine specifically designed for limited resource in mobile devices

Is Android a Linux distribution?

The short answer is no. Android is based on the Linux kernel, but is not actually purely a Linux
distribution. A standard Linux distribution has a native windowing system, glibc and some standard
utilities. It does not have a layer of abstraction between the user applications and the libraries.

3.2 Android vs. Linux: Core Differences

Target Architecture
Android is designed for mobile devices (ARM ISA)
Linux for general purpose processors (x86 ISA)

Kernel Modifications
Android added alarm driver, power management wrapper, inter processor
communication interface, low memory killer, and kernel debugger and logger
Standard C Library
Android implements a custom implementation of C library which is proper for low memory

Android vs. Linux: Core Differences

Dalvik Virtual Machine:

A custom Java VM that simplifies the default Linux JVM
File System:
Android uses YAFFS (Yet Another Flash File System), Linux uses Ext, FAT, NTFS
Power Management:
Android is designed for saving battery in mobile devices. More about Android PM in the next Power
Management Section

3.3 Dalvik Virtual Machine

Given that the Android application runtime must support a diverse set of devices and that applications must
be sandboxed for security, performance, and reliability, a virtual machine seems like an obvious choice. But
a virtual machine-based runtime doesnt necessarily help you balance those requirements with the the
limited processor speed and limited RAM that characterizes most mobile devices.
So how did Google address all of these somewhat conflicting requirements? To summarize, their approach
for implementing an application runtime environment given these constraints is that every Android
application runs in its own process, with its own instance of the Dalvik virtual machine.

Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in
the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is registerbased, and runs classes compiled by a Java language compiler that have been transformed into the .dex
format by the included "dx" tool. The Dalvik VM relies on the Linux kernel for underlying functionality
such as threading and low-level memory management.3 Given every application runs in its own process
within its own virtual machine, not only must the running of multiple VMs be efficient but creation of new
VMs must be fast as well. The remainder of this paper surveys the major design choices of the Dalvik VM
that were influenced by the requirements outline previously, mainly the .dex file format

3.4 The Dex File Format

In standard Java environments, Java source code is compiled into Java bytecode, which is stored within .class files.
The .class files are read by the JVM at runtime. Each class in your Java code will result in one .class file. This means
that if you have, say, one .java source file that contains one public class, one static inner class, and three anonymous
classes, the compilation process (javac) will output 5 .class files.
On the Android platform, Java source code is still compiled into .class files. But after .class files are generated, the
dx tool is used to convert the .class files into a .dex, or Dalvik Executable, file. Whereas a .class file contains only
one class, a .dex file contains multiple classes. It is the .dex file that is executed on the Dalvik VM.
The .dex file has been optimized for memory usage and the design is primarily driven by sharing of data. The
following diagram contrasts the .class file format used by the JVM with the .dex file format used by the Dalvik VM

Fig 3.1 The Dex file format

(fig from http://techiezjunkyard-android.blogspot.in/2011/12/dalvik-virtual-machine-dvm_2269.html)

3.5 What is YAFFS ?

YAFFS is a file system optimized for NAND and NOR flash memory. At the time when it was developed,
file systems did exist for flash memory but most of them catered toward chips which were small enough to
use small block sizes. This was unsuitable for large NAND flash chips. YAFFS attempts to solve this by
abstracting storage to chunks which scale according to the page size.
We do not have sufficient capabilities to address pages individually, but we can address groups of four pages and
search for the desired page from there. The useful thing about this is that now we have the option of neglecting to
use RAM at all to augment our file system. We can pretty easily used some sort of indexed referencing scheme to
build a file from a string of chunk IDs, and any scanning for particular pages within that chunk will be a limited set of
a size equal to the number of chunks divided by the address size.

Chapter 4
Process and Power Management

4.1 Process Management : Principles

Two basic principles for Process Management:
1. Android OS tries to maintain an application process for as long as possible
2. Only kills process when out of memory.
Remove process to reclaim memory for more important/new processes
Process to be killed is based on priority level. Processes are placed in importance hierarchy

4.2 Process Management: Priority Hierarchy

Foreground process: A process that is required for what the user is currently doing
Visible process: A process that doesn't have any foreground components, but still can affect what the user
sees on screen
Service process: A process that is running a service. Started with startService() method
Background process: A process holding an activity that's not currently visible to the user (the activity's
onStop() method has been called)
Empty process: A process that doesn't hold any active application components. Only alive for caching
purposes

4.3 Power Management

Device goes to sleep when timeout
Process must obtain wakelock to keep the device awake
Different types of wakelocks
Partial_wake_lock
Screen_dim_wake_lock
Screen_bright_wake_lock
Full_wake_lock

Conclusion
We have seen how is the architecture of the Android OS. We have learnt how the linux kernel manages the
process and power related fuctions. We have seen how is Android OS is different of that of OS. Also we have
got the answer that Android is not purely a linux distribution.

Acknowledgement
I take this opportunity to express our deep sense of gratitude and indebtedness to our Project Guide,
Mr. Bhavesh N. Gohil, Assistant Professor in Computer Engineering Department, SVNIT,Surat for his
valuable guidance, useful comments and co-operation with kind and encouraging attitude at every point of
my seminar work.
I would also like to thank our Head of Department, Prof. D.R. Patel
Computer Engineering Department.
I am also thankful to SVNIT, Surat and its staff for providing this opportunity which helped us in gaining
sufficient knowledge and to make this Seminar Report.

References

1. http://show.docjava.com/posterous/file/2012/12/10222640-The_Dalvik_Virtual_Machine.pdf
2. http://students.mint.ua.edu/~pmkilgo/etc/android-os.pdf
3. Android Open Source Project, https://source.android.com/index.html
4. CMU Distributed System Slides, http://www.andrew.cmu.edu/course/95-702/slides/Android.pdf
5. Tutorialpoints, http://www.tutorialspoint.com/android/android_architecture.htm
6. Android App development, [online], http://rest-term.com/technote/index.php/Android
7. http://www.justtotaltech.co.uk/blog/popular-android-app-development-framework