NAME : SHARANRAJ A/L SUGUMARAN

MATRIC NO : WEK100063

ANDROID OPERATING SYSTEM

HISTORY

Foundation

Android, Inc. was founded in Palo Alto, California, United States in October, 2003 by Andy Rubin (co-founder of Danger), Rich Miner (co-founder of Wildfire Communications, Inc.), Nick Sears (once VP at T-Mobile), and Chris White (headed design and interface development atWebTV to develop, in Rubin's words "...smarter mobile devices that are more aware of its owner's location and preferences". Despite the obvious past accomplishments of the founders and early employees, Android Inc. operated secretly, revealing only that it was working on software for mobile phones.

That same year, Rubin ran out of cash. Steve Perlman brought him $10,000 in cash in an envelope and refused a stake in the company.

Acquisition by Google

Google acquired Android Inc. in August 2005, making Android Inc. a wholly owned subsidiary of Google Inc. Key employees of Android Inc., including Andy Rubin, Rich Miner and Chris White, stayed at the company after the acquisition.

Not much was known about Android Inc. at the time of the acquisition, but many assumed that Google was planning to enter the mobile phone market with this move.

Post-acquisition development

At Google, the team led by Rubin developed a mobile device platform powered by the Linux kernel. Google marketed the platform to handset makers and carriers on the premise of providing a flexible, upgradable system. Google had lined up a series of hardware component and software partners and signaled to carriers that it was open to various degrees of cooperation on their part.

Speculation about Google's intention to enter the mobile communications market continued to build through December 2006. Reports from the BBC and The Wall Street Journal noted that Google wanted its search and applications on mobile phones and it was working hard to deliver that. Print and online media outlets soon reported rumors that Google was developing a Google-branded handset. Some speculated that as Google was defining technical specifications, it was showing prototypes to cell phone manufacturers and network operators.

In September 2007, InformationWeek covered an Evalueserve study reporting that Google had filed several patent applications in the area of mobile telephony.

Android has seen a number of updates since its original release, each fixing bugs and adding new features. Each version is named, in alphabetical order, after a dessert.

Recent releases

2.3 Gingerbread refined the user interface, improved the soft keyboard and copy/paste features, improved gaming performance, SIP support (VoIP calls), and added support for Near Field Communication. Android 2.3 Gingerbread is the latest Android version that is available to phones.

3.0 Honeycomb was a tablet-oriented release which supports larger screen devices and introduces many new user interface features, and supports multicore processors and hardware acceleration for graphics.The Honeycomb SDK has been released and the first device featuring this version, the Motorola Xoom tablet, went on sale in February 2011.

3.1 Honeycomb was announced at the 2011 Google I/O on 10 May 2011. One feature focuses on allowing Honeycomb devices to directly transfer content from USB devices.

3.2 Honeycomb released at July 15 2011, is "an incremental release that adds several new capabilities for users and developers". Highlights include optimization for a broader range of screen sizes; new "zoom-to-fill" screen compatibility mode; capability to load media files directly from the SD card; and an extended screen support API, providing developers with more precise control over the UI. Android 3.2 Honeycomb is the latest Android version that is available to tablets.[58] Huawei MediaPad is the first tablet to use this version

Future releases

4.0 Ice Cream Sandwich is said to be a combination of Gingerbread and Honeycomb into a "cohesive whole". In September 2011, Eric Schmidt stated that Ice Cream Sandwich "is being released in October/November."

ANDROID OS USER INTERFACE

ANDROID 2.3

The Android boot process from power on

Since mobile platforms and embedded systems has some differences compared to Desktop systems in how they initially start up and boot this post will discuss the initial boot stages of an Android phone in some detail. Since we have used the Beagle Board as reference in some previous examples any specifics here are related to a similar system.

Power on and boot ROM code execution

At power on the CPU will be in a state where no initializations have been done. Internal clocks are not set up and the only memory available is the internal RAM. When power supplies are stable the execution will start with the Boot ROM code. This is a small piece of code that is hardwired in the CPU ASIC. For more information on boot ROM and configurations study the initialization chapter inthe Omap 3530 TRM.

A. The Boot ROM code will detect the boot media using a system register that maps to some physical balls on the asic. This is to determine where to find the first stage of the boot loader.

B. Once the boot media sequence is established the boot ROM will try to load the first stage boot loader to internal RAM. Once the boot loader is in place the boot ROM code will perform a jump and execution continues in the boot loader.

2. The boot loaderThe boot loader is a special program separate from the Linux kernel that is used to set up initial memories and load the kernel to RAM. On desktop systems the boot loaders are programs like

GRUB and in embedded Linux  uBoot  is often the boot loader of choice. Device manufacturers often use their own proprietary boot loaders. The requirements on a boot loader for Linux running on an ARM system can be found in the Booting document under /Documentation/arm in the kernel source tree.

A. The first boot loader stage will detect and set up external RAM. B. Once external RAM is available and the system is ready the to run something more

significant the first stage will load the main boot loader and place it in external RAM. C. The second stage of the boot loader is the first major program that will run. This may

contain code to set up file systems, additional memory, network support and other things. On a mobile phone it may also be responsible for loading code for the modem CPU and setting up low level memory protections and security options.

D. Once the boot loader is done with any special tasks it will look for a Linux kernel to boot. It will load this from the boot media (or some other source depending on system configuration) and place it in the RAM. It will also place some boot parameters in memory for the kernel to read when it starts up.

E. Once the boot loader is done it will perform a jump to the Linux kernel, usually some decompression routine, and the kernel assumes system responsibility.

3. The Linux kernelThe Linux kernel starts up in a similar way on Android as on other systems. It will set up everything that is needed for the system to run. Initialize interrupt controllers, set up memory protections, caches and scheduling.

A. Once the memory management units and caches have been initialized the system will be able to use virtual memory and launch user space processes.

B. The kernel will look in the root file system for the init process (found under system/core/init in the Android open source tree) and launch it as the initial user space process.

4. The init processThe init process is the "grandmother" of all system processes. Every other process in the system will be launched from this process or one of its descendants.

5. Zygote and DalvikThe Zygote is launched by the init process and will basically just start executing and and initialize the Dalvik VM.

6. The system serverThe system server is the first java component to run in the system. It will start all the Android services such as telephony manager and bluetooth. Start up of each service is currently written directly into the run method of the system server. The system server source can be found in the file frameworks/base/services/java/com/android/server/SystemServer.java in the open source project.

7. Boot completedAdded this part to the post on 20090831 since it is very useful and something I should not have left out from the beginning. Once the System Server is up and running and the system boot has completed there is a standard broadcast action called ACTION_BOOT_COMPLETED. To start your own service, register an alarm or otherwise make your application perform some action after boot you should register to receive this broadcast intent.

The separate boot steps and possible places to add your own functionality are covered in more detail in separate posts.

ARCHITECHTURE OF ANDROID OS

LINUX KERNEL

POWER MANAGEMENT

Based on the standard Linux Power Management, Android has its own n component.

Application uses user space library to inform the framework about ut its constrains.

Constraints are implemented using lock mechanism.

BINDER

Driver to facilitate inter-process communication between applications and services.

A pool of threads is associated to each application to process incoming IPC

The driver performs mapping of object between two processes

“Binder Binder” ” process uses an object reference as an address in a process’ memory space

NATIVE LIBRARIES

Android “Libc Libc” ” implementation

A custom implementation, optimized for embedded use.

BSD license

Small size and fast code paths

Very fast custom thread implementation

Built Built--android in support for android--specific services (system properties, log capabilities)

Doesn ’t support some POSIX features

SURFACE MANAGER

Provides a system--wide surface “composer ” to render all the surfaces in a frame buffer.

Can combined 2D and 3D surfaces

Can use OpenGL ES and 2D hardware accelerator for its compositions

AUDIO MANAGER

Processes multiple audio streams into PCM audio out paths.

Handle several types of devices (headphone, ear piece,… …)

Redirects audio stream to the specified output

HARDWARE ABSTRACTION LIBRARIES

Defines the interface that Android requires hardware “drivers ” to implement.

Set of standardized APIs the developer will have to implement

Available for all the components a manufacturer can integrate on its Android platform

ANDROID RUNTIME

Dalvik Virtual Machine

An interpreter-only virtual machine (no JIT), register based.

Optimized for low memory requirements

Designed to allow multiple VM instances to run at one

Relying on underlying OS for process isolation, memory management and threading support

Executes Dalvik Executables (DEX) files which are zipped into an n Android Package (APK)

APPLICATION FRAMEWORK

"Activity Manager” handles application lifecycle

“Manager Package Manager” ” holds information about applications loaded in the system

“Manager Windows Manager” ” handles all the application related windows

“ View system” ” provides all the standard widgets to build an application

Hardware services provide access to lower--level hardware APIs:

Bluetooth, telephony, location,… …

Memory Management in   Android

Introduction about Android memory

Android

Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.

Android Memory

Android is a Linux based OS  with 2.6.x kernel, stripped down to handle most tasks pretty well. It uses native open source C libraries that have powered Linux machines for years. All the basic OS operations like I/O, memory management, and so on, are handled by the native stripped-down Linux kernel.

How to use memory for each application

Android’s process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.

Each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management to the Android run time, which stops and kills processes as necessary to manage resources.

Dalvik and the Android run time sit on top of a Linux kernel that handles low-level hardware interaction including drivers and memory management, while a set of APIs provides access to all of the under- lying services, features, and hardware.

Dalvik Virtual Machine Dalvik is a register-based virtual machine that’s been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.

Understanding Application Priority and Process States

The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s priority is equal to its highest-priority component.

Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports.

All Android applications will remain running and in memory until the system needs its resources for other applications.

It’s important to structure your application correctly to ensure that its priority is appropriate for the work it’s doing. If you don’t, your application could be killed while it’s in the middle of something important.

The following list details each of the application states shown in Figure , explaining how the state is determined by the application components comprising it:

Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive

by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.

Active processes include:

Activities in an “active” state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter.

Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.

Services that are executing an onStart, onCreate, or onDestroy event handler.

Visible Processes Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.

Started Service Processes Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.

Background Processes Processes hosting Activities that aren’t visible and that don’t have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat- tern to obtain resources for foreground processes.

Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when they’re re-launched. These processes are routinely killed as required.

How to use memory efficiently

Android manages opened applications which are running in the background, so officially you shouldn’t care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness’ in everyday performance. We can use advanced task killer/task manager and it does its job very well.

A. The Linux CPU scheduling algorithm

Linux employs a number of different methods for scheduling its processes and its algorithm is very nontraditional in the big picture. There are three scheduling schemes for Linux. Each process is assigned a scheduling scheme depending on the type of task it presents. Real time tasks will often run in the SCHED FIFO or SCHED RR scheme. All other tasks will run in SCHED NORMAL . SCHED NORMAL tasks are handled by a special algorithm and are preempted by SCHED RR and SCHED FIFO tasks. In a few words the algorithm behaves like a hybrid priority queue that rewards process which are not CPU-greedy. CPU time is divided up into epochs, which are equal slices of time in which the processes can run and use up some of their allotted time, or time slice. At the end of every epoch, each process’ remaining time slice is halved. More time is added proportional to the processes’ nice value, a value specified by the user or by the system’s default nice value. The interesting rollover time has a rewarding effect to I/O bound processes. Since I/O bound processes will likely spend a lot of time waiting, the scheduling algorithm rewards it by letting it keep some of its time slice. This way processes which are likely being used by the user are very responsive and will often preempt more non-interactive, CPU-bound processes like batch commands. SCHED RR tasks will preempt SCHED NORMAL tasks and are preempted by SCHED FIFO tasks. These tasks are scheduled according to round-robin rules within their own priority bracket. SCHED FIFO tasks behave quite like the name would suggest. Tasks in this queue are scheduled by priority and arrival time, will preempt any other processes trying to run, and will execute for as long as they please.

B. Android and file systems

Android makes use of a multiplicity of file system types, namely due to the expectation of external memory with unsure file system types. As a result Android relies on the standard Linux package to provide for file systems such as ext2 and ext3, vfat, and ntfs. Android itself uses the ya.s2 file system, which is not a part of the standard Linux kernel, as its primary file system. 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. To scale the method up for considerably large NAND devices, YAFFS has a tweak in the way that it addresses pages. 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.

SECURITY ARCHITECHTURE

Android is a privilege-separated operating system, in which each application runs with a distinct system identity (Linux user ID and group ID). Parts of the system are also separated into distinct identities. Linux thereby isolates applications from each other and from the system.

Additional finer-grained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data.

A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or e-mails), reading or writing another application's files, performing network access, keeping the device awake, etc.

Because Android sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox. Applications statically declare the permissions they require, and the Android system prompts the user for consent at the time the application is installed. Android has no mechanism for granting permissions dynamically (at run-time) because it complicates the user experience to the detriment of security.

The application sandbox does not depend on the technology used to build an application. In particular the Dalvik VM is not a security boundary, and any app can run native code (see the Android NDK). All types of applications — Java, native, and hybrid — are sandboxed in the same way and have the same degree of security from each other.

All Android applications (.apk files) must be signed with a certificate whose private key is held by their developer. This certificate identifies the author of the application. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates. The purpose of certificates in Android is to distinguish application authors. This allows the system to grant or deny applications access to signature-level permissions and to grant or deny an application's request to be given the same Linux identity as another application.

MY REVIEW

First of all I want to talk about the open environment of Android Operating System. This has its own pros and cons. The good thing about the open source of android is it gives developers more

freedom to innovate. Unlike Apple’s IOS, android application developers can invent their own application and upload it on android market without any restrictions. But, this openness also gives hackers an advantage. Hackers can easily hack these applications and ruin the operating system and Google cannot restrict hackers from creating malicious software and upload it to android market. This will affect many users that download the application.

Next, I want to about the advantage of memory management of Android. Compared to windows OS, Android’s memory management is better. Sometimes in windows OS, you want to close a process which is unperformant and eating up your main memory space but you cannot. In android, the memory management does automatically kill old processes to reclaim resources. If you close an application, the application will switch in the idle mode. The state of the current running activity will be saved to the system process. Then if you start some more apps the memory management detects automatically if the free memory is to less and terminates old process automatically. That’s the reason why android doesn’t need a swap file and users must not close applications. Throughout the termination of the app process we get more memory resources and can start the new activity. Android keeps a LRU (last recently used) list and starts killing the oldest unneeded process if memory needed.