Site Map Site Map

Invitation Invitation

Invite Friends

Blogs Blogs

Android Lollipop

Welcome to Android 5.0 Lollipop—the largest and most ambitious release for Android yet!

This release is packed with new features for users and thousands of new APIs for developers. It extends Android even further, from phones, tablets, and wearables, to TVs and cars.

For a closer look at the new developer APIs, see the Android 5.0 API Overview. Or, read more about Android 5.0 for consumers

Material design

Android 5.0 brings Material design to Android and gives you an expanded UI toolkit for integrating the new design patterns easily in your apps.

New 3D views let you set a z-level to raise elements off of the view hierarchy and cast realtime shadows, even as they move.

Built-in activity transitions take the user seamlessly from one state to another with beautiful, animated motion. The material theme adds transitions for your activities, including the ability to use shared visual elements across activities.

To replay the movie, click on the device screen

Ripple animations are available for buttons, checkboxes, and other touch controls in your app.

You can also define vector drawables in XML and animate them in a variety of ways. Vector drawables scale without losing definition, so they are perfect for single-color in-app icons.

A new system-managed processing thread calledRenderThread keeps animations smooth even when there are delays in the main UI thread.

Performance focus

Android 5.0 provides a faster, smoother and more powerful computing experience.

Android now runs exclusively on the new ART runtime, built from the ground up to support a mix of ahead-of-time (AOT), just-in-time (JIT), and interpreted code. It’s supported on ARM, x86, and MIPS architectures and is fully 64-bit compatible.

ART improves app performance and responsiveness. Efficient garbage collection reduces the number and duration of pauses for GC events, which fit comfortably within the v-sync window so your app doesn’t skip frames. ART also dynamically moves memory to optimize performance for foreground uses.

Android 5.0 introduces platform support for 64-bit architectures—used by the Nexus 9's NVIDIA Tegra K1. Optimizations provide larger address space and improved performance for certain compute workloads. Apps written in the Java language run as 64-bit apps automatically—no modifications are needed. If your app uses native code, we’ve extended the NDK to support new ABIs for ARM v8, and x86-64, and MIPS-64.

Continuing the focus on smoother performance, Android 5.0 offers improved A/V sync. The audio and graphics pipelines have been instrumented for more accurate timestamps, enabling video apps and games to display smooth synchronized content.


Notifications in Android 5.0 are more visible, accessible, and configurable.

Varying notification details may appear on the lock screen if desired by the user. Users may elect to allow none, some, or all notification content to be shown on a secure lock screen.

Key notification alerts such as incoming calls appear in aheads-up notification—a small floating window that allows the user to respond or dismiss without leaving the current app.

You can now add new metadata to notifications to collect associated contacts (for ranking), category, and priority.

A new media notification template provides consistent media controls for notifications with up to 6 action buttons, including custom controls such as "thumbs up"—no more need for RemoteViews!

Your apps on the big screen

Android TV provides a complete TV platform for your app's big screen experience. Android TV is centered around a simplified home screen experience that allows users to discover content easily, with personalized recommendations and voice search.

With Android TV you can now create big, bold experiences for your app or game content and support interactions with game controllers and other input devices. To help you build cinematic, 10-foot UIs for television, Android provides aleanback UI framework in the v17 support library.

The Android TV Input Framework (TIF) allows TV apps to handle video streams from sources such as HDMI inputs, TV tuners, and IPTV receivers. It also enables live TV search and recommendations via metadata published by the TV Input and includes an HDMI-CEC Control Service to handle multiple devices with a single remote.

The TV Input Framework provides access to a wide variety of live TV input sources and brings them together in a single user interface for users to browse, view, and enjoy content. Building a TV input service for your content can help make your content more accessible on TV devices.

Document-centric apps

Android 5.0 introduces a redesigned Overview space (formerly called Recents) that’s more versatile and useful for multitasking.

New APIs allow you to show separate activities in your app as individual documents alongside other recent screens.

You can take advantage of concurrent documents to provide users instant access to more of your content or services. For example, you might use concurrent documents to represent files in a productivity app, player matches in a game, or chats in a messaging app.

Advanced connectivity

Android 5.0 adds new APIs that allow apps to perform concurrent operations with Bluetooth Low Energy (BLE), allowing both scanning (central mode) and advertising (peripheral mode).

New multi-networking features allow apps to query available networks for available features such as whether they are Wi-Fi, cellular, metered, or provide certain network features. Then the app can request a connection and respond to connectivity loss or other network changes.

NFC APIs now allow apps to register an NFC application ID (AID) dynamically. They can also set the preferred card emulation service per active service and create an NDEF record containing UTF-8 text data.

High-performance graphics

Support for Khronos OpenGL ES 3.1 now provides games and other apps the highest-performance 2D and 3D graphics capabilities on supported devices.

OpenGL ES 3.1 adds compute shaders, stencil textures, accelerated visual effects, high quality ETC2/EAC texture compression, advanced texture rendering, standardized texture size and render-buffer formats, and more.

Gameloft's Rival Knights uses ASTC (Adaptive Scalable Texture Compression) from AEP and Compute Shaders from ES 3.1 to deliver HDR (High Dynamic Range) Bloom effects and provide more graphical detail.

Android 5.0 also introduces the Android Extension Pack (AEP), a set of OpenGL ES extensions that give you access to features like tessellation shaders, geometry shaders, ASTC texture compression, per-sample interpolation and shading, and other advanced rendering capabilities. With AEP you can deliver high-performance graphics across a range of GPUs.

More powerful audio

A new audio-capture design offers low-latency audio input. The new design includes: a fast capture thread that never blocks except during a read; fast track capture clients at native sample rate, channel count, and bit depth; and normal capture clients offer resampling, up/down channel mix, and up/down bit depth.

Multi-channel audio stream mixing allows professional audio apps to mix up to eight channels including 5.1 and 7.1 channels.

Apps can expose their media content and browse media from other apps, then request playback. Content is exposed through a queryable interface and does not need to reside on the device.

Apps have finer-grain control over text-to-speech synthesis through voice profiles that are associated with specific locales, quality and latency rating. New APIs also improve support for synthesis error checking, network synthesis, language discovery, and network fallback.

Android now includes support for standard USB audio peripherals, allowing users to connect USB headsets, speakers, microphones, or other high performance digital peripherals. Android 5.0 also adds support for Opus audio codecs.

New MediaSession APIs for controlling media playback now make it easier to provide consistent media controls across screens and other controllers.

Enhanced camera & video

Android 5.0 introduces all new camera APIs that let you capture raw formats such as YUV and Bayer RAW, and control parameters such as exposure time, ISO sensitivity, and frame duration on a per-frame basis. The new fully-synchronized camera pipeline allows you to capture uncompressed full-resolution YUV images at 30 FPS on supported devices.

Along with images, you can also capture metadata like noise models and optical information from the camera.

Apps sending video streams over the network can now take advantage of H.265 High Efficiency Video Coding (HEVC) for optimized encoding and decoding of video data.

Android 5.0 also adds support for multimedia tunneling to provide the best experience for ultra-high definition (4K) content and the ability to play compressed audio and video data together.

Users have a unified view of their personal and work apps, which are badged for easy identification.

Android in the workplace

To enable bring-your-own-device for enterprise environments, a new managed provisioning process creates a secure work profile on the device. In the launcher, apps are shown with a Work badge to indicate that the app and its data are administered inside of the work profile by an IT administrator.

Notifications for both the personal and work profile are visible in a unified view. The data for each profile is always kept separate and secure from each other, including when the same app is used by both profiles.

For company-owned devices, IT administrators can start with a new device and configure it with a device owner. Employers can issue these devices with a device owner app already installed that can configure global device settings.

Screen capturing and sharing

Android 5.0 lets you add screen capturing and screen sharing capabilities to your app.

With user permission, you can capture non-secure video from the display and deliver it over the network if you choose.

New types of sensors

In Android 5.0, a new tilt detector sensor helps improve activity recognition on supported devices, and a heart rate sensor reports the heart rate of the person touching the device.

New interaction composite sensors are now available to detect special interactions such as a wake up gesture, a pick upgesture, and a glance gesture.

Chromium WebView

The initial release for Android 5.0 includes a version of Chromium for WebView based on the Chromium M37 release, adding support for WebRTCWebAudio, and WebGL.

Chromium M37 also includes native support for all of the Web Componentsspecifications: Custom Elements, Shadow DOM, HTML Imports, and Templates. This means you can use Polymer and its material design elements in a WebView without needing polyfills.

Although WebView has been based on Chromium since Android 4.4, the Chromium layer is now updatable from Google Play.

As new versions of Chromium become available, users can update from Google Play to ensure they get the latest enhancements and bug fixes for WebView, providing the latest web APIs and bug fixes for apps using WebView on Android 5.0 and higher.

Accessibility & input

New accessibility APIs can retrieve detailed information about the properties of windows on the screen that sighted users can interact with and define standard or customized input actions for UI elements.

New Input method editor (IME) APIs enable faster switching to other IMEs directly from the input method.

Tools for building battery-efficient apps

New job scheduling APIs allow you optimize battery life by deferring jobs for the system to run at a later time or under specified conditions, such as when the device is charging or connected to Wi-Fi.

A new dumpsys batterystats command generates battery usage statistics that you can use to understand system-wide power use and understand the impact of your app on the device battery. You can look at a history of power events, approximate power use per UID and system component, and more.

Battery Historian is a new tool to convert the statistics from dumpsys batterystats into a visualization for battery-related debugging. You can find it at

Android Technology

Table of Contents

Chapter 1

            1.1 Abstract -----------------------------------------------------------------------------------5


Chapter 2

2.1 Introduction ------------------------------------------------------------------------------6

Chapter 3

  1.  Features of Android OS ---------------------------------------------------------------7

Chapter 4

            4.1 Android Architecture -------------------------------------------------------------------8

                        4.1.1 Application Framework-----------------------------------------------------9

4.1.2 Libraries----------------------------------------------------------------------10

4.1.3 Android Runtime------------------------------------------------------------11

4.1.4 Linux Kernal-----------------------------------------------------------------12

Chapter 5

            5.1 Architecture for Secure Data storage-------------------------------------------------13

Chapter 6

            6.1 Execution Environment ----------------------------------------------------------------15

            6.2 The Dalvik Virtual Machine-----------------------------------------------------------19

Chapter 7

            7.1 Lifecycle of an Android Application -------------------------------------------------20

            7.2 Security and permissions in Android -------------------------------------------------22

            7.3 Development Tools----------------------------------------------------------------------23


Conclusion ---------------------------------------------------------------------------------------------25





Chapter 1



 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 free-software and open-source license.

                        Open - Android allows to access core mobile device functionality through standard API calls. All applications are equal - Android does not differentiate between the phone's basic and third-party 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.










Chapter 2


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 free-software and open-source license.


 Google Acquires Android Inc.

In July 2005, Google acquired Android Inc., a small startup company based in Palo Alto, CA. Android's co-founders who went to work at Google included Andy Rubin (co-founder of Danger), Rich Miner (co-founder of Wildfire Communications, Inc), Nick Sears (once VP at T-Mobile), and Chris White (one of the first engineers at WebTV). At the time, little was known about the functions of Android Inc. other than they made software for mobile phones.


2.1.2 Open Handset Alliance Founded

On 5 November 2007, the Open Handset Alliance, a consortium of several companies which include Google, HTC, Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel and NVIDIA, was unveiled with the goal to develop open standards for mobile devices. Along with the formation of the Open Handset Alliance, the OHA also unveiled their first product, Android, an open source mobile device platform based on the Linux operating system.

2.1.3 Hardware

Google has unveiled at least three prototypes for Android, at the Mobile World Congress on February 12, 2008. One prototype at the ARM booth displayed several basic Google applications. A 'd-pad' control zooming of items in the dock with a relatively quick response.



Chapter 3

3.1 Features of Android OS


  • Application framework enabling reuse and replacement of components
  • Dalvik virtual machine optimized for mobile devices
  • Integrated browser based on the open source WebKit engine
  • Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
  • SQLite for structured data storage
  • Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
  • GSM Telephony (hardware dependent)
  • Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
  • Camera, GPS, compass, and accelerometer (hardware dependent)
  • Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE



Chapter 4


4.1 Android Architecture


The following diagram shows the major components of Android  



Figure 1: Architecture of Android OS



4.1.1 Application Framework

Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

  ·        A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser

·        Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data

·        A Resource Manager, providing access to non-code resources such as localized strings, graphics, and lat files

·        A Notification Manager that enables all applications to display custom alerts in the status bar

·        An Activity Manager that manages the life cycle of applications and provides a common navigation backstack



4.1.2 Libraries

Android includes a set of C/C++ libraries used by various components of the Android system. These capabilities are exposed to developers through the Android application framework. Some of the core libraries are listed below:

·        System C library - a BSD-derived implementation of the standard C system library (libc), tuned for embedded Linux-based devices

·        Media Libraries - based on PacketVideo's Open CORE; the libraries support playback and recording of many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG

·        Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications

·        LibWebCore - a modern web browser engine which powers both the Android browser and an embeddable web view

·        SGL - the underlying 2D graphics engine

·        3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer

·        Free Type - bitmap and vector font rendering

SQLite - a powerful and lightweight relational database engine available to all applications.




4.1.3 Android Runtime

Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language. 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 register-based, 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.

At the same level there is Android Runtime, where the main component Dalvik Virtual Machine is located. It was designed specifically for Android running in limited environment, where the limited battery, CPU, memory and data storage are the main issues. Android gives an integrated tool “dx”, which converts generated byte code from .jar to .dex file, after this byte code becomes much more efficient to run on the small processors.


Figure 2: Conversion from .java to .dex file 

As the result, it is possible to have multiple instances of Dalvik virtual machine running on the single device at the same time. The Core libraries are written in Java language and contains of the collection classes, the utilities, IO and other tools.









4.1.4 Linux Kernal

Android Architecture is based on Linux 2.6 kernel. It helps to manage security, memory management, process management, network stack and other important issues. Therefore, the user should bring Linux in his mobile device as the main operating system and install all the drivers required in order to run it. Android provides the support for the Qualcomm MSM7K chipset family. For instance, the current kernel tree supports Qualcomm MSM 7200A chipsets, but in the second half of 2008 we should see mobile devices with stable version Qualcomm MSM 7200, which includes major features:


1. WCDMA/HSUPA and EGPRS network support

2. Bluetooth 1.2 and Wi-Fi support

3. Digital audio support for mp3 and other formats

4. Support for Linux and other third-party operating systems

5. Java hardware acceleration and support for Java applications

6. Qcamera up to 6.0 megapixels

7.  gpsOne – solution for GPS




Chapter 5

5.1 Architecture for Secure Data Storage






Figure 3 Android and Secure Local Data Storage


Secure data storage solution that could potentially be deployed on Android. It is as shown in the figure. However, many shortcomings of the design have been addressed. Additional security highlights will be presented at the end of the section.

Using figure 3, we have the following workflow:

  1. The user enters his credentials on the handset.
  2. The credentials are not sent to the SSO service over the network. Instead, the credentials are used as the passphrase to decrypt the local public/private key pair of the user. We define the public/private key pair to be of type RSA and of at least 4096 bits in size. Already we gain the advantage that the user’s password is not sent over the network.
  3. The private key is used to decrypt the symmetric cipher key. The symmetric cipher key is used to encrypt/decrypt any locally cached data. A strong symmetric cipher like 3DES is used.
  4. All data found in the local cache is encrypted with the symmetric cipher key defined in step #3.
  5. If the requested data is not locally cached or expired. We must communicate with the SSO service again to be able to receive fresh data from the Restful web services. However, unlike the architecture presented in section 2 of this document, we login to the SSO server using a hostile challenge based on the private key of the user. As such, we login with the SSO system using public/private key infrastructure. The user name and the password are never sent over the network. The SSO system can identify the user based on this challenge and returns a 496 bit alpha numeric token.
  6. The tokens generated by the SSO system are set to automatically expire after a given period of time.
  7. On reception of the SSO token. The Android background application can now communicate with any Restful web services that adhere to the same SSO federation. Public/private key infrastructure is once again used to setup a secure communication channel between the phone and the server. The certificates of the servers that host the web services are procured from the same certificate authority that shipped with the phone.
  8. On reception of a request, the SSO token is extracted from the request. The web service calls upon the SSO system to authorize the operation.
  9. On reception of the data, the symmetric cipher described in bullet #3 above is used to encrypt the data before it reaches any local persistent storehouse.
  10. Data is returned to the user facing application.


Additional security notes:

1. The public/private key pair of the user is generated directly on the handset at install time. As such, the private key has never left the phone nor has it been transferred over any network.

2. The certificate of the user must at least be registered once in the SSO application. This could be done at install time of the handset application.

3. “Man-in-the-middle”38 attacks are not possible since the application is deployed with the CA certificate of the company that will be hosting the web services.

4. If the device is lost, all the locally cached data is completely unreadable. The symmetric key that encrypted this data is also unreadable. The public/private keys that are central to the security architecture are protected by a passphrase.

5. The passphrase is the weakest link in the chain. If the user enters an overly simple password, access could be gained to the private key and hence the locally cached data.

6. That being said, it would be possible to further extend this architecture to store the encrypted symmetric key on the server. This way, even if the passphrase of the private key is compromised, the locally cached data still cannot be accessed. This is because the encrypted strong symmetric cipher key is stored on the server. By the time the passphrase has been cracked, there has been ample time to report the stolen phone and revoke this key from this user account on the server. Furthermore, under this scheme, the key stored on the server is still encrypted. Even if this key is intercepted in transit it is useless without the user’s private key.

7. It is also possible to enforce a strong password policy directly from the handset application.

8. Even if this design is significantly more secure than the previous iteration, to the user, the experience is the same. The user must enter a username and password to prove his identify.

9. We could augment the architecture in yet another direction. The local caching system could also require an SSO token and subsequently request authorization from an SSO system. Such a design would prevent terminated employees, i.e., an Individual who already knows what the local credentials are, from accessing the locally cached data.


Chapter 6

6.1 Execution Environment


Figure 4 Regular Java Execution Process


Figure 5 Android Execution Environment


Figures 4 and 5 represent the regular Java and Android execution paths respectively. It is interesting to note here however is that the Android compilers do not operate on Java

language code. Instead, the Android translators work on the resulting Java bytecode emitted from a traditional Java compiler.

As such, it is possible to reuse existing Java libraries, even if the original source code is not available. Such libraries must meet stringent requirements however, they need to:

  1. adhere to the Java SE 5 dialect
  2. not use any Java classes or packages found in Java SE 5 not found in the Android platform
  3. not use any packages or classes specific to the Sun Microsystems platform
  4. still behave in a predictable manner under the Apache Harmony Java environment


Following these guidelines, it’s possible to integrate existing Java source code, packages and libraries piecemeal. Special care will be needed in the integration phase of such code but the potential savings offered by such integration far outweighs the cost of rewriting well-coded, well-documented and well-tested libraries ready for use. Furthermore, it is expected that has Apache Harmony matures, more and more compatibility issues will be resolved further increasing the pool of available Java code that will be able to execute unmodified under the Android platform.


6.2 The Dalvik Virtual Machine

The Dalvik Virtual Machine

The Dalvik virtual machine is an interpreter only machine optimized for use on low powered, low memory devices like phones. Notably, Dalvik does not make use of just in time (JIT) Compilation to improve the performance of an application at runtime. Furthermore, Dalvik is not a Java virtual machine. This is because Dalvik is unable to read Java bytecode34, instead it uses its own bytecode format called “dex”. Google claims this format allows battery power to be better-conserved at all different stages of execution of an application. This means that standard Java SE applications and libraries cannot be used directly on the Android Dalvik virtual machine.

Dalvik however stands at the center of the Android value proposition. Its low electrical power consumption, rich libraries, and unified, non-fragmented application programming interfaces make it stand out, or so Google hopes, over the fragmented ecosystem that is Java ME35 today.

Furthermore, since Dalvik uses the Java programming language but not the Java execution environment (JVM), Google is free to develop Android without the need to license or obtain certification from Sun Microsystems Inc, the legal owner of the Java trademark and brands.



Chapter 7

7.1 Lifecycle of an Android Application

In most cases, every Android application runs in its own Linux process. This process is created for the application when some of its code needs to be run, and will remain running until it is no longer needed and the system needs to reclaim its memory for use by other applications.

An important and unusual feature of Android is that an application process's lifetime is not directly controlled by the application itself. Instead, it is determined by the system through a combination of the parts of the application that the system knows are running, how important these things are to the user, and how much overall memory is available in the system.

It is important that application developers understand how different application components (in particular Activity, Service, and IntentReceiver) impact the lifetime of the application's process. Not using these components correctly can result in the system killing the application's process while it is doing important work.

A common example of a process life-cycle bug is an IntentReceiver that starts a thread when it receives an Intent in its onReceiveIntent() method, and then returns from the function. Once it returns, the system considers that IntentReceiver to be no longer active, and thus its hosting process no longer needed (unless other application components are active in it). Thus, it may kill the process at any time to reclaim memory, terminating the spawned thread that is running in it. The solution to this problem is to start a Service from the IntentReceiver, so the system knows that there is still active work being done in the process.

To determine which processes should be killed when low on memory, Android places them into an "importance hierarchy" based on the components running in them and the state of those components. These are, in order of importance:

1.    A foreground process is one holding an Activity at the top of the screen that the user is interacting with (its onResume () method has been called) or an IntentReceiver that is currently running (its onReceiveIntent () method is executing). There will only ever be a few such processes in the system, and these will only be killed as a last resort if memory is so low that not even these processes can continue to run. Generally at this point the device has reached a memory paging state, so this action is required in order to keep the user interface responsive.

2.    A visible process is one holding an Activity that is visible to the user on-screen but not in the foreground (its onPause() method has been called). This may occur, for example, if the foreground activity has been displayed with a dialog appearance that allows the previous activity to be seen behind it. Such a process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.

3.    A service process is one holding a Service that has been started with the startService() method. Though these processes are not directly visible to the user, they are generally doing things that the user cares about (such as background mp3 playback or background network data upload or download), so the system will always keep such processes running unless there is not enough memory to retain all foreground and visible process.

4.    A background process is one holding an Activity that is not currently visible to the user (its onStop() method has been called). These processes have no direct impact on the user experience. Provided they implement their activity life cycle correctly (see Activity for more details), the system can kill such processes at any time to reclaim memory for one of the three previous processes types. Usually there are many of these processes running, so they are kept in an LRU list to ensure the process that was most recently seen by the user is the last to be killed when running low on memory.

5.    An empty process is one that doesn't hold any active application components. The only reason to keep such a process around is as a cache to improve startup time the next time a component of its application needs to run. As such, the system will often kill these processes in order to balance overall system resources between these empty cached processes and the underlying kernel caches.

When deciding how to classify a process, the system picks the most important level of all the components currently active in the process.



7.2 Security and Permissions in Android


Android is a multi-process system, where each application (and parts of the system) runs in its own process. Most security between applications and the system is enforced at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. Additional finer-grained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform.

Android mobile phone platform is going to be more secure than Apple’s iPhone or any other device in the long run. There are several solutions nowadays to protect Google phone from various attacks. One of them is security vendor McAfee, a member of Linux Mobile (LiMo) Foundation. This foundation joins particular companies to develop an open mobile-device software platform. Many of the companies listed in the LiMo Foundation have also become members of the Open Handset Alliance (OHA).

As a result, Linux secure coding practice should successfully be built into the Android development process. However, open platform has its own disadvantages, such as source code vulnerability for black-hat hackers. In parallel with great opportunities for mobile application developers, there is an expectation for exploitation and harm. Stealthy Trojans hidden in animated images, particular viruses passed from friend to friend, used for spying and identity theft, all these threats will be active for a long run.

Another solution for such attacks is SMobile Systems mobile package. Security Shield –an integrated application that includes anti-virus, anti-spam, firewall and other mobile protection is up and ready to run on the Android operating system. Currently, the main problem is availability for viruses to pose as an application and do things like dial phone numbers, send text messages or multi-media messages or make connections to the Internet during normal device use. It is possible for somebody to use the GPS feature to track a person’s location without their knowledge. Hence SMobile Systems is ready to notify and block these secure alerts. But the truth is that it is not possible to secure r mobile device or personal computer completely, as it connects to the internet. And neither the Android phone nor other devices will prove to be the exception.



7.3 Development Tools

The Android SDK includes a variety of custom tools that help  develop mobile applications on the Android platform. The most important of these are the Android Emulator and the Android Development Tools plugin for Eclipse, but the SDK also includes a variety of other tools for debugging, packaging, and installing r applications on the emulator.

Android Emulator

A virtual mobile device that runs on computer use the emulator to design, debug, and test r applications in an actual Android run-time environment.

Android Development Tools Plugin for the Eclipse IDE

The ADT plugin adds powerful extensions to the Eclipse integrated environment, making creating and debugging r Android applications easier and faster. If  use Eclipse, the ADT plugin gives  an incredible boost in developing Android applications:

       It gives access to other Android development tools from inside the Eclipse IDE. For example, ADT lets  access the many capabilities of the DDMS tool — taking screenshots, managing port-forwarding, setting breakpoints, and viewing thread and process information — directly from Eclipse.

       It provides a New Project Wizard, which helps quickly create and set up all of the basic files’ll need for a new Android application.

       It automates and simplifies the process of building r Android application.

       It provides an Android code editor that helps write valid XML for r Android manifest and resource files.

Dalvik Debug Monitor Service (ddms)

Integrated with Dalvik, the Android platform's custom VM, this tool lets manage processes on an emulator or device and assists in debugging.  can use it to kill processes, select a specific process to debug, generate trace data, view heap and thread information, take screenshots of the emulator or device, and more.

Android Debug Bridge (adb)

The adb tool lets install application's .apk files on an emulator or device and access the emulator or device from a command line.  can also use it to link a standard debugger to application code running on an Android emulator or device.

Android Asset Packaging Tool (aapt)

The aapt tool lets create .apk files containing the binaries and resources of Android applications.

Android Interface Description Language (aidl)

Aidl Lets generate code for an interprocess interface, such as what a service might use.


Included as a convenience, this tool lets access the SQLite data files created and used by Android applications.

Trace view

This tool produces graphical analysis views of trace log data that  can generate from r Android application.


Helps  create a disk image that  can use with the emulator, to simulate the presence of an external storage card (such as an SD card).


The dx tool rewrites .class bytecode into Android bytecode (stored in .dex files.)


A script that generates Ant build files that  can use to compile r Android applications. If  are developing on Eclipse with the ADT plugin,  won't need to use this script.








Android is a truly open, free development platform based on Linux and open source. Handset makers can use and customize the platform without paying a royalty.

A component-based architecture inspired by Internet mash-ups. Parts of one application can be used in another in ways not originally envisioned by the developer.  can even replace built-in components with  own improved versions. This will unleash a new round of creativity in the mobile space.

  • Android is open to all: industry, developers and users
  • Participating in many of the successful open source projects
  • Aims to be as easy to build for as the web.
  • Google Android is stepping into the next level of Mobile Internet





Android Application Development Tutorials

What is Android?:

Android is an open source and Linux-based Operating System for mobile devices such as smartphones and tablet computers. Android was developed by the Open Handset Alliance, led by Google, and other 84 companies.

Android offers a unified approach to application development for mobile devices which means developers need only develop for Android, and their applications should be able to run on different devices powered by Android.

Android applications are usually developed in the Java language using the Android Software Development Kit.

Once developed, Android applications can be packaged easily and sold out either through a store such as Google Play or the Amazon Appstore.

The versions of android ranges from A to K currently, such as Aestro, Blender, Cupcake, Donut, Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwitch,Jelly Bean and KitKat.

History of Android:

Initially, Andy Rubin founded Android Incorporation in Palo Alto, California, United States in October, 2003.

In 17th August 2005, Google acquired android Incorporation. Since then, it is in the subsidiary of Google Incorporation.

The first beta version of the Android Software Development Kit (SDK) was released by Google in 2007 where as the first commercial version, Android 1.0, was released in September 2008.

Platform Version

API Level



Android 4.4




Android 4.3




Android 4.2, 4.2.2




Android 4.1, 4.1.1




Android 4.0.3, 4.0.4




Android 4.0, 4.0.1, 4.0.2



Android 3.2




Android 3.1.x




Android 3.0.x




Android 2.3.4
Android 2.3.3




Android 2.3.2
Android 2.3.1
Android 2.3



Android 2.2.x




Android 2.1.x




Android 2.0.1



Android 2.0



Android 1.6




Android 1.5




Android 1.1




Android 1.0





Android Architecture:

Android operating system is a stack of software components which is roughly divided into five sections and four main layers as shown below in the architecture diagram.

Android Architecture

Linux kernel

At the bottom of the layers is Linux - Linux 2.6 with approximately 115 patches. This provides basic system functionality like process management, memory management, device management like camera, keypad, display etc. Also, the kernel handles all the things that Linux is really good at such as networking and a vast array of device drivers, which take the pain out of interfacing to peripheral hardware.


On top of Linux kernel there is a set of libraries including open-source Web browser engine WebKit, well known library libc, SQLite database which is a useful repository for storage and sharing of application data, libraries to play and record audio and video, SSL libraries responsible for Internet security etc.

Android Runtime

This is the third section of the architecture and available on the second layer from the bottom. This section provides a key component called Dalvik Virtual Machine which is a kind of Java Virtual Machine specially designed and optimized for Android.

The Dalvik VM makes use of Linux core features like memory management and multi-threading, which is intrinsic in the Java language. The Dalvik VM enables every Android application to run in its own process, with its own instance of the Dalvik virtual machine.

The Android runtime also provides a set of core libraries which enable Android application developers to write Android applications using standard Java programming language.

Application Framework

The Application Framework layer provides many higher-level services to applications in the form of Java classes. Application developers are allowed to make use of these services in their applications.


You will find all the Android application at the top layer. You will write your application to be installed on this layer only. Examples of such applications are Contacts Books, Browser, Games etc.

Android Application Components:

There are following four main components that can be used within an Android application:

Components Description
Activities They dictate the UI and handle the user interaction to the smartphone screen
Services They handle background processing associated with an application.
Broadcast Receivers They handle communication between Android OS and applications.
Content Providers They handle data and database management issues.

These components are loosely coupled by the application manifest file AndroidManifest.xml that describes each component of the application and how they interact.


An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. If an application has more than one activity, then one of them should be marked as the activity that is presented when the application is launched.

An activity is implemented as a subclass of Activity class as follows:

public class MainActivity extends Activity {



A service is a component that runs in the background to perform long-running operations. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity.

A service is implemented as a subclass of Service class as follows:

public class MyService extends Service {


Broadcast Receivers

Broadcast Receivers simply respond to broadcast messages from other applications or from the system. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.

A broadcast receiver is implemented as a subclass of BroadcastReceiver class and each message is broadcasted as an Intent object.

public class MyReceiver  extends  BroadcastReceiver {


Content Providers

A content provider component supplies data from one application to others on request. Such requests are handled by the methods of the ContentResolver class. The data may be stored in the file system, the database or somewhere else entirely.

A content provider is implemented as a subclass of ContentProvider class and must implement a standard set of APIs that enable other applications to perform transactions.

public class MyContentProvider extends  ContentProvider {



Android Activities:

An activity represents a single screen with a user interface. We can control and manage the resource through the life cycle methods of activity. It provides the details about the invocation of life cycle methods of activity.  Android system initiates its program with in an Activity starting with a call on onCreate() callback method. There is a sequence of callback methods that start up an activity and a sequence of callback methods that tear down an activity as shown in the Activity lifecycle diagram.

The Activity class defines the following callbacks i.e. events. You don't need to implement all the callbacks methods. However, it's important that you understand each one and implement those that ensure your app behaves the way users expect.

Callback Description
onCreate() This is the first callback and called when the activity is first created.
onStart() This callback is called when the activity becomes visible to the user.
onResume() This is called when the user starts interacting with the application.
onPause() The paused activity does not receive user input and cannot execute any code and called when the current activity is being paused and the previous activity is being resumed.
onStop() This callback is called when the activity is no longer visible.
onDestroy() This callback is called before the activity is destroyed by the system.
onRestart() This callback is called when the activity restarts after stopping it.