Introduction

Android is a mobile operating system developed by Google and is based upon a modified version of the Linux kernel. It was initially developed by Android Inc. (a firm purchased by Google) and later positioned in the Open Handset Alliance. Let me tell you more about open handset alliance. The Open Handset Alliance (OHA) is a business alliance of 78 firms for developing open standards for mobile devices. Member firms include Google, HTC, Dell, Intel. Motorola, Qualcomn, Texas Instruments, Samsung, LG, T-Mobile, Nvidia and Wind River Systems.


The OHA was established on 5 November 2007, led by Google with 34 members including mobile handset makers, application developers, some mobile carriers and chip makers. Android, the flagship software of the alliance, is based on an open source license and competes against mobile platforms from Apple, Microsoft, Nokia, Palm, Research In Motion, Symbian, and bada. At the same time as the announcement of the formation of the Open Handset Alliance on 5 November 2007, the OHA also unveiled Android, an open source mobile phone platform based on the Linux operating system.

Android has a large community of developers writing application programs ("apps") that extend the functionality of the devices. There are currently over 70,000 apps available for Android with some estimates saying 100,000 have been submitted, which makes it the second most popular mobile development environment. Developers write managed code in the Java language, controlling the device via Google-developed Java libraries.

Android OS usage share

• Android 2.1 (Eclair) - 41.7%
• Android 2.2 (Froyo) - 28.7%
• Android 1.6 (Donut) - 17.5%
• Android 1.5 (Cupcake) - 12.0%

According to Gartner analyst Ken Dulaney, Android is based on a clean room reversed-engineered version of Java, called Dalvik, which was developed without using any Sun technology or intellectual property. Oracle says Dalvik is a competitor to Java and infringes several of its patents, which are listed in the complaint, and its Java copyright. While officially claiming that "Android is not Java", Google at the same time calls the suit "attack on Java community", likely making difference between "official Java" and "Java in general".

What Will Drive Android Adoption?

Android is targeted primarily at developers, with Google and the OHA betting that the way to deliver better mobile software to consumers is by making it easier for developers to write it themselves.

As a development platform, Android is powerful and intuitive, letting developers who have never programmed for mobile devices create useful applications quickly and easily. It’s easy to see how innovative Android applications could create demand for the devices necessary to run them, particularly if developers write applications for Android because they can’t write them for other platforms.

Open access to the nuts and bolts of the underlying system is what’s always driven software development and platform adoption. The Internet’s inherent openness and neutrality have seen it become the platform for a multi-billion-dollar industry within 10 years of its inception. Before that, it was open systems like Linux and the powerful APIs provided as part of the Windows operating system that enabled the explosion in personal computers and the movement of computer programming from the arcane to the mainstream.

This openness and power ensure that anyone with the inclination can bring a vision to life at minimal cost. So far, that’s not been the case for mobile phones, and that’s why there are so few good mobile phone applications and fewer still available for free.

Basics: Android Applications

Applications in Android are a bit different from what you may be used to in the desktop and server environments. The differences are driven by a few key concepts unique to the mobile phone environment and unique to Google’s intentions for Android.

Limited resources

Mobile phones today are very powerful handheld computers, but they are still limited. The fundamental limitation of a mobile device is battery capacity. Every clock tick of the processor, every refresh of memory, every backlit pixel on the user’s screen takes energy from the battery. Battery size is limited, and users don’t like frequent battery charging. As a result, the computing resources are limited— clock rates are in the hundreds of MHz, memory is at best a few gigabytes, data storage is at best a few tens of gigabytes.

Mobile mashups

In the desktop Internet world, mashups make it very easy to create new applications by reusing the data and user interface elements provided by existing applications. Google Maps is a great example: you can easily create a web-based application that incorporates maps, satellite imagery, and traffic updates using just a few lines of JavaScript on your own web page. Android extends that concept to the mobile phone. In other mobile environments, applications are separate, and with the exception of browser-based applications, you are expected to code your applications separately from the other applications that are running on the handset. In Android you can easily create new applications that incorporate existing applications.

Interchangeable applications

In other mobile software environments, applications are coded to access data from specific data providers. If you need to send an email from a Windows Mobile application, for example, you code explicit references to Pocket Outlook’s email interface, and send the email that way. But what if the user wants to use another email client?

Android incorporates a fundamental mechanism (Intents) that is independent of specific application implementations. In an Android application, you don’t say you want to send email through a specific application; instead, you say you want to send an email through whatever application is available. The operating system takes care of figuring out what application can send emails, starts that application if needed, and connects your request so the email can be sent. The user can substitute different browsers, different MP3 players, or different email clients at will, and Android adapts automatically.

That is why android sounds exciting and has endless features to play with.

Understanding the Android Software Stack

So far I have discussed Android’s history and its optimization features. In this section, I would like to cover the development aspect of Android. 

At the core of the Android Platform is Linux kernel version 2.6, responsible for device drivers, resource access, power management, and other OS duties. The supplied device drivers include Display, Camera, Keypad, WiFi, Flash Memory, Audio, and IPC (interprocess communication).

Sitting at the next level, on top of the kernel, are a number of C/C++ libraries such as OpenGL, WebKit, FreeType, Secure Sockets Layer (SSL), the C runtime library (libc), SQLite, and Media.

The WebKit library is responsible for browser support.

Android GUI Architecture

The Android environment adds yet another Graphical User Interface (GUI) toolkit to the Java ecosphere, joining AWT, Swing, SWT, and J2ME (leaving aside the web UI toolkits). If you’ve worked with any of these, the Android framework will look familiar. Like them, it is single-threaded, event-driven, and built on a library of nestable components.
The Android UI framework is, like the other UI frameworks, organized around the common Model-View-Controller pattern illustrated in Figure. It provides structure and tools for building a Controller that handles user input (like key presses and screen taps) and a View that renders graphical information to the screen.


The Model
The Model is the guts of your application: what it actually does. It might be, for instance, the database of tunes on your device and the code for playing them. It might be your list of contacts and the code that places phone calls or sends IMs to them.

While a particular application’s View and Controller will necessarily reflect the Model they manipulate, a single Model might be used by several different applications. Think, for instance, of an MP3 player and an application that converts MP3 files into WAV files. For both applications, the Model includes the MP3 file format and codecs for it. The former application, however, has the familiar Stop, Start, and Pause controls, and plays the track. The latter may not produce any sound at all; instead, it will have controls for setting bitrate, etc. The Model is all about the data.

The View

The View is the application’s feedback to the user. It is the portion of the application responsible for rendering the display, sending audio to speakers, generating tactile feedback, and so on. The graphical portion of the Android UI framework’s View, is implemented as a tree of subclasses of the View class. Graphically, each of these objects represents a rectangular area on the screen that is completely within the rectangular area represented by its parent in the tree. The root of this tree is the application window.

The Controller

The Controller is the portion of an application that responds to external actions: a keystroke, a screen tap, an incoming call, etc. It is implemented as an event queue. Each external action is represented as a unique event in the queue. The framework removes each event from the queue in order and dispatches it.

UI Development in Android

UI development in Android is fun. It’s fun because the unattractive features in some other platforms are absent from Android. Swing, for example, has to support desktop applications as well as Java applets. Thus, the Java Foundation Classes (JFC) contains so much functionality that it’s frustrating to use and difficult to navigate. JavaServer Faces (JSF) is another example. JSF, a common framework used to build web applications, is actually built on top of JavaServer Pages (JSP) and servlets. So you have to know all of the underlying frameworks before you can begin working with JSF. Fortunately, this type of baggage carried by other platforms does not exist in Android. With Android, we have a simple framework with a limited set of out-of-the-box controls. The available screen area is generally limited. This, combined with the fact that the user usually wants to do one specific action, allows us to easily build a good user interface to deliver a good
user experience.

The Android SDK ships with a host of controls that you can use to build user interfaces for your application. Similar to other SDKs, the Android SDK provides text fields, buttons, lists, grids, and so on. In addition, Android also provides a collection of controls that are appropriate for mobile devices.

Signing and Publishing Your Application

Writing and running Android applications for your own amusement is all well and good, but the point of creating new applications is to share them with others, whether you charge money for them or give them away for free. Google has created Android Market just for that purpose. Anyone with a connected Android phone can open the Android Market application and immediately download any of hundreds (soon to be
thousands) of applications expressly designed for Android. These applications range from the very practical (Navigation, Timesheets, File Managers, etc.) to the downright silly (applications that make rude noises for the fun of it). There are a number of steps any application developer will go through in preparing and submitting an application to Android Market:

1. Thoroughly test the application—at least with the Android emulator, but also with as many actual Android devices as you can lay your hands on. There is no substitute for testing applications on real phones under real mobile network conditions to prove that they work as you intend. The last thing you want is thousands of people upset with you because your application doesn’t work the way they expect it to.

2. Decide whether you’d like to add an End User License Agreement (EULA) to your application. This is normal practice in the industry (it’s the “click to accept” license that you see when you download an application, even on desktops), and is strongly advised.

3. Create the icon and label you want displayed for your application in the Application Launcher, and attach them to your application.

4. Clean up the application for release: turn off debugging, get rid of any extraneous print or logging statements that you had in for debug, and take a final look at the code to clean it up.


5. Make sure you’ve included a version number and a version name in your manifest file, and of course, bump the version number if this is a new version of a previously released application.

6. Create a signing certificate, and, if needed, a Map API Key.

7. Recompile your application for release using Android Tools.

8. Sign your application using jarsigner and your signing certificate.

9. Retest your signed application to be sure no errors were entered during the process.