Operating Systems

(EE-3401/Computer Laboratory)

By Palash Parmar Roll No.-11104EN040 B.Tech Part-III Electrical Engineering

Abstract-This paper gives a brief study of two Operating System named Windows and Android, starting from its history, followed by its classification, its features, its working, and finally compared with other Operating System on various grounds. I. INTRODUCTION An operating system (commonly abbreviated OS and O/S) is the software component of a computer system that is responsible for the management and coordination of activities and the sharing of the resources of the computer. The operating system acts as a host for application programs that are run on the machine. As a host, one of the purposes of an operating system is to handle the details of the operation of the hardware. This relieves application programs from having to manage these details and makes it easier to write applications. Almost all computers, including hand-held computers, desktop computers, supercomputers, and even play station consoles, use an operating system of some type. Some of the oldest models may however use an embedded OS that may be contained on a compact disk or other storage device. Common contemporary operating systems include Microsoft Windows, Mac OS X, Linux and Solaris. Microsoft Windows has a significant majority of market share in the desktop and notebook computer markets, while servers generally run on Linux or other Unix-like systems. Embedded device markets are split amongst several operating systems. II. HISTORY OF WINDOWS In 1983, Microsoft announced the development of Windows, a graphical user interface (GUI) for its own operating system (MS-DOS). The product line has changed from a GUI product to a modern operating system over two families of design, each with its own codebase and default file system. The 3.x and 4.x family includes many versions of Windows advancing in 32-bit networking and 32-bit disk access. The development of Windows NT with newer kernel and improved architecture makes windows a great success. On 25 June 1998, Microsoft released Windows 98, includes new hardware drivers and the FAT32 file system which supports disk partitions that are larger than 2 GB.

On 25 August 2001, Microsoft released Windows XP. Windows XP uses the Windows NT 5.1 kernel, marking the entrance of the Windows NT core to the consumer market, to replace the aging 16/32-bit branch. Windows Vista was released on 8 November 2006 to business customers, consumer versions following on 30 January 2007. Windows Vista intended to have enhanced security by introducing a new restricted user mode called User Account Control, replacing the "administrator-by-default" philosophy of Windows XP. Vista also features new graphics features, the Windows Aero GUI, new applications. Windows 7 was released to manufacturing on 22 July 2009, and reached general retail availability on 22 October 2009. It was previously known by the codenames Blackcomb and Vienna. Windows 7 has the version number NT 6.1. Windows 7 ships in six editions: i. Starter ii. Home Basic iii. Home Premium iv. Professional v. Enterprise vi. Ultimate III. HARDWARE REQUIREMENT The minimum requirement of Windows 7 is: 1 GHz processor (32- or 64-bit) 1 GB of RAM (32-bit); 2 GB of RAM (64bit) 16 GB of available disk space (32-bit); 20 GB of available disk space (64-bit) DirectX 9 graphics device with WDDM 1.0 or higher driver

IV. DESIGN CONCEPT OF WINDOWS 7 Extensibility: The code must be written to comfortably grow and change as market requirements change. Portability: The system must be able to run on multiple hardware architectures and must be able to move with relative ease to new ones as market demands dictate. Reliability and Robustness: The system should protect itself from both internal malfunction and external tampering. Applications should not be able to harm the operating system or other applications.

Compatibility: Although Windows NT should extend existing technology, its user interface and APIs should be compatible with older versions of Windows and with MS-DOS. It should also interoperate well with other systems, such as UNIX, OS/2, and NetWare. Performance Within the constraints of the other design goals, the system should be as fast and responsive as possible on each hardware platform.

V. WINDOWS 7 ARCHITECTURE

Exchange Server, also include components that run as services. User applications, which can be one of the following types: Windows 32-bit or 64-bit, Windows 3.1 16-bit, MS-DOS 16-bit, or POSIX 32-bit or 64-bit. Note that 16-bit applications can be run only on 32-bit Windows. Environment subsystem server processes, which implement part of the support for the Operating system environment, or personality, presented to the user and programmer. Windows NT originally shipped with three environment subsystems: Windows, POSIX, and OS/2. However, the POSIX and OS/2 subsystems last shipped with Windows 2000. The Ultimate and Enterprise editions of Windows client as well as all of the server versions include support for an enhanced POSIX subsystem called Subsystem for Unix-based Applications (SUA).

If the observe in the system architecture diagram of Windows 7, there is a line dividing the user-mode and kernel-mode parts of the Windows operating system. The boxes above the line represent usermode processes, and the components below the line are kernel-mode operating system services. Usermode threads execute in a protected process address space (although while they are executing in kernel mode, they have access to system space). Thus, system support processes, service processes, user applications, and environment subsystems each have their own private process address space. The four basic types of user-mode processes are described as follows: Fixed (or hardwired) system support processes, such as the logon process and the Session Manager that are not Windows services. (That is, they are not started by the service control manager.) Service processes that host Windows services, such as the Task Scheduler and Print Spooler services. Services generally have the requirement that they run independently of user logons. Many Windows server applications, such as Microsoft SQL Server and Microsoft

The kernel-mode components of Windows include the following: The Windows executive contains the base operating system services, such as memory management, process and thread management, security, I/O, networking, and interprocess communication. The Windows kernel consists of low-level operating system functions, such as thread scheduling, interrupt and exception dispatching, and multiprocessor synchronization. It also provides a set of routines and basic objects that the rest of the executive uses to implement higher-level constructs. Device drivers include both hardware device drivers, which translate user I/O function calls into specific hardware device I/O requests, as well as non-hardware device drivers such as file system and network drivers. The hardware abstraction layer (HAL) is a layer of code that isolates the kernel, the device drivers, and the rest of the Windows executive from platform-specific hardware differences (such as differences between motherboards). VI. PROCESSES, THREADS, AND JOBS Each Windows process is represented by an executive process (EPROCESS) data structure.

Besides containing many attributes relating to a process, an PROCESS contains and points to a number of other related data structures. For each process that is executing a Win32 program, the Win32 subsystem process (Csrss) maintains a parallel structure called the CSR_PROCESS. Finally, the kernel-mode part of the Win32 subsystem (Win32k.sys) maintains a per-process data structure, W32PROCESS. The W32PROCESS structure is created the first time a thread calls a Windows USER or GDI function that is implemented in kernel mode. In the Windows security model, any process running with a token containing the debug privilege (such as an administrators account) can request any access right that it desires to any other process running on the machine. Protected processes can be created by any application; however, the operating system will allow a process to be protected only if the image file has been digitally signed with a special Windows Media Certificate. The various steps involved in creating a process in Windows 7 is described in a form of a flow chart below.

might be allowed or preferred to run on, a phenomenon called processor affinity. Processor affinity is defined based on a given processor group, which collects up to 64 processors. By default, threads can run only on any available processors within the processor group associated with the process (to maintain compatibility with older versions of Windows which supported only 64 processors), but developers can alter processor affinity by using the appropriate APIs or by setting an affinity mask in the image header, while users can use tools to change affinity at runtime or at process creation. However, although multiple threads in a process can be associated with different groups, a thread on its own can run only on the processors available within its assigned group. Additionally, developers can choose to create group-aware applications, which use extended scheduling APIs to associate logical processors on different groups with the affinity of their threads. Doing so converts the process into a multigroup process that can theoretically run its threads on any available processor within the machine. VII. SECURITY These are the core components and databases that implement Windows security: Security reference monitor (SRM) A component in the Windows executive (%SystemRoot%\System32\Ntoskrnl.exe) that is responsible for defining the access token data structure to represent a security context, performing security access checks on objects, manipulating privileges (user rights), and generating any resulting security audit messages. Local Security Authority subsystem (LSASS) A user-mode process running the image%SystemRoot%\System32\Lsass.exe that is responsible for the local system security policy (such as which users are allowed to log on to the machine, password policies, privileges granted to users and groups, and the system security auditing settings), user authentication, and sending security audit messages to the Event Log. The Local Security Authority service (Lsasrv %SystemRoot%\System32\Lsasrv.dll), a library that LSASS loads, implements most of this functionality. LSASS policy database A database that contains the local system security policy settings. This database is stored in the registry in an ACL-protected area under

Windows Scheduling: Windows implements a priority-driven, preemptive scheduling systemat least one of the highest priority runnable (ready) threads always runs, with the caveat that certain high-priority threads ready to run might be limited by the processors on which they

HKLM\SECURITY. It includes such information as what domains are entrusted to authenticate logon attempts, who has permission to access the system and how (interactive, network, and service logons), who is assigned which privileges, and what kind of security auditing is to be performed. The LSASS policy database also stores secrets that include logo n information used for cached domain logons and Windows service user-account logons. Security Accounts Manager (SAM) A service responsible for managing the database that contains the user names and groups defined on the local machine. The SAM service, which is implemented as %SystemRoot%\System32\Samsrv.dll, is loaded into the LSASS process. SAM database A database that contains the defined local users and groups, along with their passwords and other attributes. On domain controllers, the SAM does not store the domain defined users, but stores the systems administrator recovery account definition and password. This database is stored in the registry under HKLM\SAM. Active Directory A directory service that contains a database that stores information about objects in a domain. A domain is a collection of computers and their associated security groups that are managed as a single entity. Active Directory stores information about the objects in the domain, including users, groups, and computers. Password information and privileges for domain users and groups are stored in Active Directory, which is replicated across the computers that are designated as domain controllers of the domain. The Active Directory server, implemented as SystemRoot%\System32\Ntdsa.dll, runs in the LSASS process. Authentication packages These include dynamic-link libraries (DLLs) that run both in the context of the LSASS process and client processes, and implement Windows authentication policy. An authentication DLL is responsible for authenticating a user, by checking whether a given user name and password match, and if so, returning to the LSASS information detailing the users security identity, which LSASS uses to generate a token. Interactive logon manager (Winlogon) A user-mode process running %SystemRoot% \System32\Winlogon.exe that is responsible

for responding to the SAS and for managing interactive logon sessions. Winlogon creates a users first process when the user logs on, for example. Logon user interface (LogonUI) A usermode process running %SystemRoot%\System32 \LogonUI.exe that presents users with the user interface they can use to authenticate themselves on the system. LogonUI uses credential providers to query user credentials through various methods. Credential providers (CPs) In-process COM objects that run in the LogonUI process (started on demand by Winlogon when the SAS is performed) and used to obtain a users name and password, smartcard PIN, or biometric data (such as a fingerprint). The standard CPs are %SystemRoot%\System32\authui.dll and %SystemRoot%\System32 \SmartcardCredentialProvider.dll. Network logon service (Netlogon) A Windows service (%SystemRoot%\System32 \Netlogon.dll) that sets up the secure channel to a domain controller, over which security requests such as an interactive logon (if the domain controller is running Windows NT 4) or LAN Manager and NT LAN Manager (v1 and v2) authentication validationare sent. Netlogon is also used for Active Directory logons. Kernel Security Device Driver (KSecDD) A kernel-mode library of functions that implement the advanced local procedure call (ALPC) interfaces that other kernel mode security components, including the Encrypting File System (EFS), use to communicate with LSASS in user mode. KSecDD is located in %SystemRoot%\System32\Drivers\Ksecdd. sys. AppLocker A mechanism that allows administrators to specify which executable files, DLLs, and scripts can be used by specified users and groups. AppLocker consists of a driver (%SystemRoot%\System32\Drivers\AppId. sys) and a service (%SystemRoot%\System32 \AppIdSvc.dll) running in a SvcHost process.

VIII. MEMORY MANAGEMENT The maximum amount of physical memory currently supported by Windows ranges from 2 GB to 2,048 GB, depending on which version and edition of Windows you are running. Because the virtual address space might be larger or smaller than the physical memory on the machine, the memory manager has two primary tasks: Translating, or mapping, a processs virtual address space into physical memory so that when a thread running in the context of that process reads or writes to the virtual address space, the correct physical address is referenced. (The subset of a processs virtual address space that is physically resident is called the working set. Paging some of the contents of memory to disk when it becomes overcommittedthat is, when running threads or system code try to use more physical memory than is currently available and bringing the contents back into physical memory when needed. The Performance tab in the Windows Task Manager, shown in the following screen shot, displays basic system memory information. This information is a subset of the detailed memory information available through the performance counters. It includes data on both physical and virtual memory usage. Windows provides memory protection so that no user process can inadvertently or deliberately corrupt the address space of another process or of the operating system. Windows provides this protection in four primary ways. First, all system wide data structures and memory pools used by kernel-mode system components can be accessed only while in kernel mode Second, each process has a separate, private address space, protected from being accessed by any thread belonging to another process. Third, in addition to the implicit protection virtual-to-physical address translation offers, all processors supported by Windows provide some form of hardware-controlled memory protection (such as read/write, readonly, and so on); the exact details of such protection vary according to the processor. Finally, shared memory section objects have standard Windows access control lists (ACLs) that are checked when processes attempt to open them, thus limiting access of shared memory to those processes with the proper rights. IX. Cache Manager The cache manager has several key features: Supports all file system types (both local and network), thus removing the need for

each file system to implement its own cache management code Uses the memory manager to control which parts of which files are in physical memory (trading off demands for physical memory between user processes and the operating system) Caches data on a virtual block basis (offsets within a file)in contrast to many caching systems, which cache on a logical block basis (offsets within a disk volume) allowing for intelligent read-ahead and highspeed access to the cache without involving file system drivers (This method of caching, called fast I/O, is described later in this chapter.) Supports hints passed by applications at file open time (such as random versus sequential access, temporary file creation, and so on) Supports recoverable file systems (for example, those that use transaction logging) to recover data after a system failure X. File Systems

format for magnetooptical storage media, mainly DVD-ROM. UDF is included in the DVD specification and is more flexible than CDFS. The UDF file system format has the following traits: Directory and file names can be 254 ASCII or 127 Unicode characters long. Files can be sparse. (Sparse files are defined later in this chapter.) File sizes are specified with 64 bits. Support for access control lists (ACLs). Support for alternate data streams. FAT12, FAT16, and FAT32: Windows supports the FAT file system primarily for compatibility with other operating systems in multiboot systems, and as a format for flash drives or memory cards. The Windows FAT file system driver is implemented in %SystemRoot%\System32\Drivers\Fastfat.s ys. The name of each FAT format includes a number that indicates the number of bits that the particular format uses to identify clusters on a disk. FAT12s 12-bit cluster identifier limits a partition to storing a maximum of 212 (4,096) clusters. Windows permits cluster sizes from 512 bytes to 8 KB, which limits a FAT12 volume size to 32 MB. exFAT: Designed by Microsoft, the Extended File Allocation Table file system (exFAT, also called FAT64) is an improvement over the traditional FAT file systems and is specifically designed for flash drives. The main goal of exFAT is to provide some of the advanced functionality offered by NTFS, but without the metadata structure overhead and metadata logging that create write patterns not suited for many flash media devices. As the FAT64 name implies, the file size limit is increased to 264, allowing files up to 16 exabytes.This change is also matched by an increase in the maximum cluster size, which is currently implemented as 32 MB but can be as large as 2255 sectors. exFAT also adds a bitmap that tracks free clusters, which improves the performance of allocation and deletion operations. Finally, exFAT allows more than 1,000 files in a single directory. These characteristics result in increased scalability and support for large disk sizes.

Windows includes support for the following file system formats: CDFS:(%SystemRoot%\System32\Drivers\ Cdfs.sys), or CD-ROM file system, is a read-only file system driver that supports a superset of the ISO-9660 format as well as a superset of the Joliet disk format. While the ISO-9660 format is relatively simple and has limitations such as ASCII uppercase names with a maximum length of 32 characters, Joliet is more flexible and supports Unicode names of arbitrary length. If structures for both formats are present on a disk (to offer maximum compatibility), CDFS uses the Joliet format. CDFS has a couple of restrictions: A maximum file size of 4 GB A maximum of 65,535 directories CDFS is considered a legacy format because the industry has adopted the Universal Disk Format (UDF) as the standard for optical media. UDF: The Windows UDF file system implementation is OSTA (Optical Storage Technology Association) UDF- compliant. (UDF is a subset of the ISO-13346 format with extensions for formats such as CD-R and DVD-R/RW.) OSTA defined UDF in 1995 as a format to replace the ISO-9660

NTFS: The NTFS file system is the native file system format of Windows. NTFS uses 64-bit cluster numbers. This capacity gives NTFS the ability to address volumes of up to 16 exaclusters; however, Windows limits the size of an NTFS volume to that addressable with 32-bit clusters, which is slightly less than 256 TB (using 64-KB clusters). NTFS also supports 2321 files per volume. The NTFS format allows for files that are 16 exabytes in size, but the implementation limits the maximum file size to 16 TB.

File system drivers (FSDs) manage file system formats. Although FSDs run in kernel mode, they differ in a number of ways from standard kernelmode drivers. Perhaps most significant, they must register as an FSD with the I/O manager and they interact more extensively with the memory manager. For enhanced performance, file system drivers also usually rely on the services of the cache manager. Windows has two different types of file system drivers: Local FSDs manage volumes directly connected to the computer. Network FSDs allow users to access data volumes connected to remote computers. XI. BASIC WINDOWS COMMANDS dir: List of files in the directory. xcopy: Copy a file chkdsk: Check remaining disk space. mem: Check amount of memory available. tasklist: show tasks that are running in windows system. taskkill: To kill a particular task in windows system. The Graphical User interface of Windows 7 is very user friendly. It is easy to understand compared to other OS. There is a huge collection of software and games available in Windows OS. It is easy to find software for Windows OS.

ANDROID OS
I. INTRODUCTION AND HISTORY Android is a software stack for mobile devices that includes an operating system, middleware and key applications. Android is a software platform and operating system for mobile devices based on the Linux operating system and developed by Google and the Open Handset Alliance. It allows developers to write managed code in a Java-like language that utilizes Google-developed Java libraries, but does not support programs developed in native code. The unveiling of the Android platform on 5 November 2007 was announced with the founding of the Open Handset Alliance, a consortium of 34 hardware, software and telecom companies devoted to advancing open standards for mobile devices. When released in 2008, most of the Android platform will be made available under the Apache freesoftware and open-source license. Open - Android allows accessing core mobile device functionality through standard API calls. All applications are equal - Android does not differentiate between the phone's basic and thirdparty applications -- even the dialer or home screen can be replaced. Breaking down boundaries Combine information from the web with data on the phone -- such as contacts or geographic location -- to create new user experiences. Fast and easy development - The SDK contains what need to build and run Android applications, including a true device emulator and advanced debugging tools. II. ANDROID 4.4 HARDWARE REQUIREMENTS Android 4.4 OS require at least 512 MB of RAM, and a 32-bit ARMv7, MIPS or x86 architecture processor, together with an OpenGL ES 2.0 compatible graphics processing unit (GPU). Android supports OpenGL ES 1.1, 2.0 and 3.0. Some applications explicitly require certain version of the OpenGL ES, thus suitable GPU hardware is required to run such applications. Android devices incorporate many optional hardware components, including still or video cameras, GPS, hardware orientation sensors, dedicated gaming controls, accelerometers, gyroscopes, barometers, magnetometers, proximity sensors, pressure sensors, thermometers and touchscreens. Some hardware components are not required, but became standard in certain classes of devices, such as smartphones, and additional requirements apply if they are present. Some other

hardware was initially required, but those requirements have been relaxed or eliminated altogether. For example, as Android was developed initially as a phone OS, hardware such as microphones were required, while over time the phone function became optional. Android used to require an autofocus camera, which was relaxed to a fixed-focus camera if it is even present at all, since the camera was dropped as a requirement entirely when Android started to be used on set-top boxes.

III. ARCHITECTURE OF ANDROID

Figure 1 outlines the current (layered) Android Architecture. The modified Linux kernel operates as the HAL, and provides device driver, memory management, process management, as well as networking functionalities, respectively. The library layer is interfaced through Java (which deviates from the traditional Linux design). It is in this layer that the Android specific lib.c (Bionic) is located. The surface manager handles the user interface (UI) windows. The Android runtime layer holds the Dalvik Virtual Machine (DVM) and the core libraries (such as Java or IO). Most of the functionalities available in Android are provided via the core libraries. The application framework houses the API interface. In this layer, the activity manager governs the application life cycle. The content providers enable applications to either access data from other applications or to share their own data. The resource manager provides access to non-code resources (such as graphics), while the notification manager enables applications to display custom alerts. On top of the

application framework are the built-in, as well as the user applications, respectively. It has to be pointed out that a user application can replace a built-in application, and that each Android application runs in its own process space, within its own DVM instance. Most of these major Android components are further discussed (in more detail) in the next few sections of this report. Dalvik Virtual Machine Android based systems utilize their own virtual machine (VM), which is known as the Dalvik Virtual Machine (DVM). The DVM uses special byte-code, hence native Java byte-code cannot directly be executed on Android systems. The Android community provides a tool (dx) that allows converting Java class files into Dalvik executable (dex). The DVM implementation is highly optimized in order to perform as efficiently and as effectively as possible on mobile devices that are normally equipped with a rather modest (these days normally a dual, or quad) CPU subsystem, limited memory resources, no OS swap space, and limited battery capacity. The DVM has been implemented in a way that allows a device to execute multiple VMs in a rather efficient manner. It also has to be pointed out that the DVM relies on the modified Linux kernel for any potential threading and low-level memory management functionalities. With Android 2.2, some major changes to the JVM infrastructure were implemented. Up to version 2.2, the JVM was an actual interpreter, similar to the original JVM solution deployed with Java 1.0. While the Android solution always reflected a very efficient interpreter, it was still an interpreter and hence, no native code was generated. With the release of Android 2.2, a just-in-time (JIT) compiler was incorporated into the solution stack, which translates the Dalvik byte-code into much more efficient machine code (similar to a C compiler). Currently, Android version 4 (Ice Cream Sandwich) and 4.1/4.2 (Jelly Bean) is deployed on some devices. It has to be pointed out though that currently, only a few devices are actually running version 4.1/4.2 or 4.0, while most devices are still operating on older Android versions. Down the road, additional JIT and garbage collection (GC) features will be deployed with Android, further busting aggregate systems performance. IV. PROCESS AND KERNEL Five types of processes are distinguished in Android in order to control the behavior of the system and its running programs. The various types have different importance levels which are strictly ordered. The resulting importance hierarchy for process classes looks like this:

Foreground: A process that is running an Activity, a Service providing the Activity, a starting or stopping Service or a currently receiving Broadcast Receiver. Visible: If a process holds a paused but still visible Activity or a Service bound to a visible Activity and no foreground components, it is classified a visible process. Service: A process that executes an already started Service. Background: An Activity that is no longer visible is hold by a background process. Empty: These processes contain no active application components and exist only for caching purposes. If the system is running low on memory, the importance of a process becomes a crucial part in the systems decision which process gets killed to free memory. Therefore empty processes are killed most likely followed by background processes and so on. Usually only empty and background processes are killed so the user experience stays unaffected. The system is designed to leave everything untouched as long as possible that is associated with a visible component like an Activity. Processes can contain multiple threads, like it is usual on Linux based systems. Most Android applications consist of multiple threads to separate the UI from input handling and I/O operations or long running calculations, hence the underlying processes are multi-threaded. The threads used on application level are standard Java threads running in the Dalvik VM. V. SECURITY IN ANDROID The security model of Android heavily depends on the multi-user capabilities of the underlying Linux. Each application runs with its own unique user id and in its own process. All Dalvik applications run in a sandbox that by default prohibits e.g. Communication with other processes, access to others data, access to hardware features like GPS or camera and network access. Opposing to platforms with native binary executable, Android makes it easy to enforce a certain application behavior, as its application VM Dalvik directly controls code execution and resource access. Platforms like iOS, webOS, Symbian or MeeGo do not have this opportunity, thus their sandboxing systems are based on means on kernel-, filesystem- or process-level and some of these means are used by Android too. The basic sandbox denies all requests from an application unless the permissions are explicitly granted. The permissions are set up in the application manifest file with the <uses-permission> tag. That allows the system to ask the user or a package manager upfront at install time for the applications

10

wanted permissions. Once installed, an application can assume that all wanted permissions are granted. During the installation process, an application is assigned with a unique and permanent user id. This user id is used to enforce permissions on process and file system level. An application can explicitly share files by setting the file mode to be world readable or writeable, otherwise all files are private. If two applications should share the same processes or use the same user id, both of the applications have to be signed with the same certificate and ask for the same sharedUserId in their manifest files. The individual components of an application can also be restricted, to ensure that only certain sources are allowed to start an activity, a service or send a broadcast to the applications receiver. A service can enforce fine grained permissions with the Context.checkCallingPermission() method. Content providers can restrict overall read and write access as well as grant permissions on an URI basis. VI. POWER MANAGEMENT In the mobile device arena, power management is obviously paramount. That does not imply though that power management should be neglected on any other system. Hence, power management in any IT system, with any operating system, is considered a necessity due to the ever increasing power demand of todays computer systems. To illustrate, to reduce and manage power consumption, Linux based systems provide power-saving features such as clock gating, voltage scaling, activating sleep modes, or disabling memory cache. Each of these features reduces the system's power consumption (normally at the expense of an increased latency behavior). Most Linux based systems manage power consumption via the Advanced Configuration and Power Interface (ACPI). Android based systems provide their own power management infrastructure (labeled Power Manager) that was designed based on the premise that a processor should not consume any power if no applications or services actually require power. Android demands that applications and services request CPU resources via wake locks through the Android application framework and native Linux libraries. If there are no active wake locks, Android will shut down the processor. VII. STORAGE MEDIA & FILE SYSTEM When it comes to configuring and setting-up mobile devices, traditional hard drives are in general too big (size), too fragile, and consume too much power to be useful. In contrast, flash memory devices normally provide a (relative) fast read access behavior as well as better (kinetic) shock resistance compared to hard

drives. Fundamentally, two different types of flash memory devices are common, labeled as NAND and NOR based solutions. While in general, NOR based solutions provide low density, they are characterized as (relative) slow write and fast read components. On the other hand, NAND based solutions offer low cost, high density, and are labeled as (relative) fast write and slow read IO solutions. Some embedded systems are utilizing NAND flash devices for data storage, and NOR based components for the code (the execution environment). From a file system perspective, as of Android version 2.3, the (wellknown) Linux ext4 file system is being used. Prior to the ext4 file system, Android normally used YAFFS (yet another flash file system). The YAFFS solution is known as the first NAND optimized Linux flash file system. Some Android product providers (such as Archos with ext3 in Android 2.2) replaced the standard Archos file system with another file system solution of their choice. As of the writing of this report, the maximum size of any Android application equals to a low 2-digit MB number, which compared to actual Linux based systems, has to be considered as being very small. This implies that the memory and file system requirements (from a size perspective not from a data integrity perspective) are vastly different for Android based devices compared to most Linux systems. VIII. BASIC ANDROID COMMANDS Commands below are the ADB commands for Android system: Devices: Lists accessible devices. Push: Copies a local file to the device. Pull: Copies a remote file from the device. sync There are three cases here: 1. If no argument is passed, copies the local directories system and data if they differ from /system and /data on the target. 2. If either system or data is passed, syncs this directory with the associated partition on the device 3. Else, syncs the given folder install Installs the given Android package (apk) on the device uninstall Uninstalls the given package name from the device shell Runs a remote shell with a command line interface. If an argument is given, runs it as a command and prints out the result. reboot Reboots the device. bootloader and recovery arguments are available to select the operation mode you want to reboot to.

11

COMPARIRISON OF WINDOWS AND ANDROID The memory management of Windows is very vast as compared to Android. Though Windows is providing a large platform then Android, Android due to is less but efficient memory management makes it better then Windows. In terms of energy management, Android is better than Windows. Windows require large hardware resources that consume a lot of power. On the other hand, Android consumes very less power hence best for smartphones. As a work point of view, Windows is enabled with large file system, followed by good architecture and capable of doing most of task. On the other hand, though Android is handy, its work area is limited to certain size of applications like checking and editing documents, mail and accessing internet. There is no virtual memory associated with Android. Windows have virtual memory and paging files. Android is an open source software, which means that the code is freely available under the Apache License for modification and distribution by device manufacturers whereas Windows Phone is a series of proprietary software developed and marketed by Microsoft Corporation.

12