Comparison between Android & Linux OS

                                    A Survey on Android vs. Linux

INTRODUCTION

      Android  is an open source  mobile device operating system  developed by Google based on the Linux 2.6 kernel. The Linux kernel was chosen due to its proven driver model, existing drivers, 

memory  and process management, networking  support along with  other core operating system services [1]. In addition to the Linux kernel various libraries were added to the platform in order to 

support higher functionality. Many of these libraries  originate from open source projects; however the Android team created their own C library, for example, in order to resolve licensing conflicts. 

They also developed their own Java runtime engine, optimized for the limited resources available on a mobile platform called  the "Dalvik Virtual Machine."  Lastly, the application framework was created in order to provide the system libraries in a concise manner to the end-user applications. In this survey we  highlight the major differences between  a standard Linux operating system and 

Android. Particular emphasis is placed on the unique challenges present on the mobile  embedded devices and how these differences motivate Android's structure with respect to Linux.

TARGET ARCHITECTURE

      The Linux kernel supports many different target architectures. However only two are fully supported by Android at this time: x86 and ARM. The x86 architecture for Android is mainly targeted mainly at Mobile Internet Devices (MIDs) whereas the ARM platform is prevalent on mobile phones. These architectures are typically used for very different computer systems. The x86  platform is  used for general purpose  desktop/laptop/server  computing whereas  ARM is widely in use on mobile devices. A comparison of these two platforms provides strong insight 

into the fundamental differences between Linux and Android.

      Linux was initially created in 1991 as an open-source desktop operating system by Linus Torvalds. He created the Linux kernel since the MINIX operating system (an academic-oriented 

UNIX-like system) did not support the new 32-bit features of his Intel 80386 very well. The x86 family later came to dominate the desktop market and led to most personal computers using the 

x86 architecture today. Consequently much of the Linux kernel development today is focused on this family.

      Smart  phones  in comparison do not have one clear market leader. Nokia, Research in Motion (RIM), Apple, HTC and Samsung  all have a significant fraction of the  smart phone market [2]. Despite no one manufacturer dominating the smartphone segment, they  all primarily use one architecture, ARM. In fact as of 1996 98% of all mobile phones had at least one ARM microprocessor in them [3]. The widespread popularity of the ARM platform is largely 

due to its focus on power saving features. Unlike desktop systems, mobile phones rely on battery power for operation and therefore power consumption is a primary design factor.

      Among the most fundamental differences between these two architectures is their instruction design philosophy. The x86 family is primarily a CISC (Complicated Instruction Set Computer) design whereas ARM is a RISC (Reduced Instruction Set Computer) architecture. This results in more, simpler instructions being used by ARM processors when compared to an equivalent set of x86 operations. Memory is at a premium in embedded devices due to size, cost and power constraints. ARM makes up for this concern by offering a second 16-bit instruction set called Thumb which can be interleaved with regular 32-bit ARM instructions. This

additional instruction set can reduce code size by up to 30%, at the expense of some performance.

DALVIK VIRTUAL MACHINE

      Many of the top cell phone manufacturers such as Nokia, Motorola and Samsung include a mobile optimized version of the Java virtual machine called Java 2, Micro Edition (J2ME). In 

contrast to these vendors Android uses their own Dalvik Virtual Machine (See Figure 1). This development process is identical to the developer as a standard Java platform.  Application developers write their program in Java and compile java class files. However, instead of the class files being run on a J2ME virtual machine, the code is translated after compilation into a"Dex file" that can be run on the Dalvik machine. A tool called dx will convert and repack the 

class files in a Java .jar file into a single dex file with several shared constant pools. This is used to reduce the duplicated arguments and make the dex file more compact. The virtual machine itself is  optimized  to  perform well on mobile devices with a slow CPU, limited memory, nooperating system  swap space and  most importantly limited battery power  [15]. These constraints can be quite tight. For example, typically  the total system  memory  will be 

approximately 64M. High-level services  will consume roughly 44MB.  Then, the large system library will consume another 10MB. This leaves only 10MB for pure application code. The Dalvik VM is optimized for low memory compared to other standard VMs due to the following changes [16]:

• The VM was slimmed down to use less space. 

• Dalvik has no just-in-time compiler 

• The constant pool has been modified to use only 32-bit indexes to simplify the interpreter. 

• It uses its own bytecode, not Java bytecode. 

FILE SYSTEM

Storage media: NAND

      Android uses the YAFFS flash file system, the first NAND  optimized  Linux  flash file system. For mobile devices, hard disks are too large in size, too fragile and consume too much 

power to be useful. In contrast, flash memory provides fast read access time and better kinetic shock resistance than hard disks. There are fundamentally two different types of flash memory 

based on their construction technique: NOR and NAND. NOR is low density, offers slow writes and fast reads. NAND is low cost, high density and offers fast writes and slow reads. Embedded 

systems are increasingly using NAND flash for storage and NOR for code and execution [21]. File systems for flash memory have to deal with these limitations in order to provide a robust file system.

Limitations

      Important limitations  of NAND memory include block erasure and memory wear. Block erasure means that when erasing any memory the whole block must be erased. NAND can be 

randomly accessed on a page basis during programming, but cannot offer arbitrary randomaccess rewrite or erase during normal operation. To overcome this limitation, memory segments 

are  marked to be removed or “dirty”. When the entire block is dirty, then it can  be erased. Memory wear means that there is a limited number of erase-write cycles in the flash memory

and at the end of its lifetime the data integrity of storage will deteriorate. 

Comparison with other file system

      A standard Linux system typically does not use flash memory, but rather magnetic disk drives. These drives are commonly formatted by default to use the latest version of the Ext file 

system. As of this writing, Ext3 is currently in widespread use and is presented here for comparison with the flash filesystem, YAFFS, in use on Android.

Ext3

      Third extended file system, commonly known as Ext3, is also a journaled file system used by the Linux kernel. It is more reliable than its predecessor, Ext2, through the use of journaling to 

facilitate fast reboots after  a  system crash. This means that Ext3 does not have to operate a whole file system check after an unclean shutdown, as was previously done using fsck. The main 

goal  of  Ext3 was to create a journaling file system  which is backward compatible with Ext2. Ext3 enhances its reliability by  using a  special API called the Journaling Block Device layer 

(JDB) to physically journal both metadata and data (when the level of journaling is configured as the "journal mode"). It also uses complete physical blocks to backup and store modified blocks 

instead of only recording spans of bytes.

POWER MANAGEMENT

     Power management  in operating systems is necessary due to the ever increasing power demand of modern desktop computers and especially laptops. In order to reduce wasted power,

multiple hardware power saving features are employed by Linux such as clock gating, voltage scaling, activating sleep modes and disabling memory cache. Each of these features reduces the 

system's power consumption at the expense of latency and/or performance. These tradeoffs on a Linux system are managed by either Advanced Power Management (APM) or Advanced Configuration and Power Interface (ACPI). APM is an older, simpler, BIOS based power management subsystem, which is still used on older systems. Newer systems use ACPI based 

management instead. ACPI is more operating-system centric  [25] than APM and also offers more features such as a tree structure for powering down devices so that subsystem componentsare not turned off before the subsystem itself.   In contrast with a standard Linux system, Android does not use APM, nor ACPI for power management. As shown in Figure 1, Android instead has its own  Linux power extension,PowerManager instead. The core power driver (Shown at the bottom of Figure 3 as "Power") was 

added to the Linux kernel in order to facilitate this functionality. This module provides low level drivers in order to control the peripherals supported by the Power Manager. These peripherals 

currently include: screen display and backlight, keyboard backlight and button backlight. Each peripheral's power is controlled through the use of WakeLocks. These locks are requested through the API whenever an application requires one of the managed peripherals to remain powered on (Each lock setting shown in Table 1). If no wake lock exists which "locks" the device, 

then it is powered off to conserve battery life. In the case of multiple power settings the transition is managed through the use of delays based on system activity. A sample of this behavior is shown in Figure 4 for the screen backlight. 

CONCLUSION

      In conclusion, we compared the major differences  between Android for mobile devices and Linux for desktop/laptops/servers systems. We have examined Android in a bottom-up fashion from its architecture to obtain an extensive overall understanding. We focused on the following general topics  to clarify the design details of Android: architecture, kerneldesign, standard C Library (including user threads), Java virtual machine, file system and 

power management. In order to  understand how Android  overcomes the hardware limitations  of a mobile device as a light-weight operating system, we depicted and summarized the key features of Android with a reasonable level-of-details in each topic.