Android: Mobile os Vs Desktop os
Mobile os Vs Desktop os Android was designed from the ground up as an operating system (OS) for mobile devices. Its built-in application and memory-management systems were engineered with battery life as one of the most critical concerns. The Android OS does not work like a desktop operating system. On a desktop OS, like Windows, Mac OS X, or Ubuntu Linux, the user is responsible for closing programs in order to keep a reasonable amount of memory available. On Android, this is not the case. The OS itself automatically removes programs from memory as memory is needed.
The OS may also preload applications into memory which it thinks might soon be needed. Under the Hood of Google Android The easiest way I can think of to visualize Android’s structure is by imagining a house with five rooms The house represents Android in general. The rooms inside, however, represent the five key features in Android’s structure: * Applications * The Application Framework * Libraries * Android Runtime * Linux Kernel. Now, imagine that each of these rooms hold a certain number of people. Each person represents an element of that room. Different rooms hold different amounts of people.
Applications This first room is a doozy. It’s “people” represent all the applications that you have in Android. Games, SMS a calendar, maps, a browser, and your contacts. All applications are written in Java ,so you can add or take away as many of these as you like. The Application Framework As a developer, you’ll have full acces to the APIs used by the core apps. Android is designed so that any application can publish its capabilities. In turn, any other application can use those capabilities, as well. It has some security constraints, as is expected, but still. That’s pretty awesome.
Along with all that, you get a Content Provider (which allows apps to share information), a Resource Manager (to help you with graphics, layout files, etc), a Notification Manager (which gives you those annoying status beeps and such), and an Acticity Manager (which manages the life cycle of your apps). All in all, when it comes to creating applications quickly and easily, Android has you covered. We’ll cover how to write an application in another article. So, you could say that the ‘people’ in this room are the managers and providers and etc. Believe me, there are a LOT.
Libraries Android has a set of core libraries off of which the applications run. As always, developers can directly access these. Some of the core libraries include FreeType, SQLite, LibWebCore, and SGL. Android Runtime You could say that the ‘Android runtime’ room is pretty exclusive– it only has two people: the Dalvik Virtual Machine and the core libraries (am I getting on your nerves with this ‘people’ thing yet? ). In Google Android, there’s a tool called ‘DX’. What this does is it executes files in ‘. dex’ format, which are specially for the Dalvik Virtual Machine.
This format is also created for minimal memory footprints, which makes it ideal for cell phones. The Dalvik Virtual Machine is written so it can run multiple prcesses quickly and smoothly. It relies on the Linux Kernel to do its magic. We’ll talk about that right after this. Linux Kernel Lastly, we have the Linux Kernel. This little room contains the Keypad, WiFi, Camera, and etc. drivers. The Linux Kernel holds all of Android’s internal structure together. It uses Linux 2. 6, and also acts like an abstraction layer between the hardware and the software. 6 FILE SYSTEM . 1 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. 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 random access 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 are 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. Wear levelling techniques are used to uniformly use whole sections and to optimize the total lifetime of the device. Bad block management (BBM) is also used to perform write verification and remapping to spare sectors in case of write failure. 6. 2 File system for NAND: YAFFS YAFFS (Yet Another Flash File System) was developed by Toby Churchill Ltd (TCL) as a reliable filing system with fast boot time for their flash memory devices.
They initially tried to modify existing flash file systems such as JFFS (used mainly for NOR) to add NAND support, but it turned out that the slow boot time and RAM consumption of existing flash file systems was unacceptable. This led them to develop a different flash file system especially for NAND according to its features and limitations to optimize performance and ensure robustness. Upon completion YAFFS performed better than existing flash file systems and can still be used with NOR, even though it is was specifically designed for NAND. YAFFS is the first flash file system specifically designed for NAND flash.
YAFFS includes the following features: • Journaling: a log-structured file system, which makes it robust to possible power failures. Note that YAFFS requires some RAM to maintain the data structure for its log. • Garbage collection: highly optimized and predictable garbage collection strategies that makes it high performance and deterministic under hard writing. Collection is executed when free space becomes low. • Lower memory requirement: it has a lower memory footprint than most other logstructured flash file systems, so it is more scalable. Flexibility: it uses a more general definition of NAND flash, is highly configurable and can be customized to work with various flash devices, different geometries, different error correction options, caching options, etc. • Portability: although YAFFS was originally designed for use with Linux, its modular design make it easy and portable to many operating systems. The file-system-specific code was kept separate from the main YAFFS file system code. The YAFFS Direct Interface (YDI) can hook up to other filesystems by applying a wrapper layer. Robustness: it is well tested and has been used in many products. Bad block handling and error correction mitigate the limitations of flash memory. We can conceptually treat YAFFS as an improved version of flash file system with following improvements: 1. YAFFS uses less run-time RAM. 2. YAFFS garbage collection is simpler and faster. 3. YAFFS uses a whole page per file for headers and provides no compression. 4. YAFFS can be used on NOR but, will not perform very well. Therefore, partition size can be a guideline to choose between YAFFS and JFFS.
For smaller partition sizes JFFS is better suited whereas for larger sizes YAFFS performs better. KERNAL MODIFICATIONS Android is based on the Linux, but does not use a standard Linux kernel. The kernel enhancements of Android include alarm driver, ashmem (Android shared memory driver), binder driver(Inter-Process Communication Interface), power management, low memory killer, kernel debugger and logger. All these kernel enhancements have been contributed back to the open source community under the GNU Public License (GPL) [8]. Here we list a summary of the most substantial components : alarm driver: provides timers to wake devices up from sleep * ashmem: allows applications to share memory and manages the sharing in kernel levels. * binder driver: facilitates inter-process communication since data can be shared by multiple applications through the use of shared memory. A service registered as an IPC service do not have to worry about different threads because binder will handle, monitor and manage them. Binder also takes care of synchronization between processes. * Power management: built on the top on standard Linux Power Management (PM) and take a more aggressive policy to manage and save power.
Android is hailed as “the first complete, open, and free mobile platform. ” Complete: The designers took a comprehensive approach when they developed the Android platform. They began with a secure operating system and built a robust software framework on top that allows for rich application development opportunities. Open: The Android platform is provided through open source licensing. Developers have unprecedented access to the handset features when developing applications. Free: Android applications are free to develop. There are no licensing or royalty fees to develop on the platform.
No required membership fees. No required testing fees. No required signing or certification fees. Android applications can be distributed and commercialized in a variety of ways. Android instead has its own Linux power extension, Power Manager 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 Wake Locks. 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 behaviour is shown in Figure 4 for the screen backlight. In addition to Wake Locks the Power.
