The launch of T-Mobile 'G1' smart-phone in late 2008 introduced a new mobile platform to the world- Android. It is a free and open platform developed and promoted by Open handset Alliance (OHA). As a platform android provides a highly customizable software stack including – an operating system, middleware, a few key mobile applications and a software development kit for easy application development.
Android tries to bring the best of open source software to mobile market were closed source proprietary software is the choice of preference. Android uses Linux kernel as the base which brings in many benefits like highly customizable, easily portable, support for most hardware platforms, an active community etc. At the same time Android has chosen open source licenses (like Apache2, BSD etc) that don’t have copy-left conditions (like GPL) for all of the user space components. This, while ensuring that Android remains open to modifications & community contributions, relives the companies from the fear of loosing intellectual property rights.
Android aims to be highly customizable such that any component, including the core components, can be easily replaced as required. To this end, Android doesn't even different between the applications that are packaged with it, and those developed by third party developers. For example, iPhone developers doesn't have the facility for creating background process as part of their application and is a privilege only for built-in applications.
Android also gives high importance to extending & re-using existing applications instead of re-implementing the same features in multiple applications. Android comes with an 'Activity/Intent' mechanism which allows applications to easily embed or make use of functionality provided by other applications. For example, if an application needs dialer functionality it can either write its own using the Android API or achieve the same by sending an appropriate 'Intent' for making use of the feature from default dialer application.
Android makes adoption easier by including the key applications required on mobile phones readily available with the platform. Some of the applications provided by Android are Phone, Contacts, Browser, Camera, IM, media player etc. with source code for customization and adaptation like all other components.
To further the features on Android devices by encouraging third party/community application development, Android provides an SDK and market place for application development and deployment. The Android SDK provides both command line or GUI (using eclipse plug-in) based development and debugging and contains a number of handy tools. The SDK also contains an emulator with most of the features seen in a mobile phone, where the developers can test their applications. Android also allow testing and debugging on actual devices via USB port using Android Debug Bridge (ADB) tool provided with the SDK. And most importantly the SDK is well supplemented by good amount of online documentation which many times becomes bottleneck in free open source projects.
When these features of Android is clubbed with the support from major industry players part of the OHA (Google, T-Mobile, HTC, Qualcomm etc. to name a few), it seems all set for revolutionizing the mobile industry.
Like most other systems, Android has an eco-system around it which includes its promoters, OEMs/ODMs, community developers, applications developers, Android market place and the end users. Here we will take quick look into the major interactions between these entities.
The OHA maintains Android source code as a set of GIT (a Distributed Version Control System) repositories available to public. The source code can be accessed either using GIT tools directly or using a specific tool called 'repo' provided by Android itself. It is a set of wrapper scripts on top on native GIT tools to make working the huge set of Android GIT repositories easier.
The Android developer community can access source code as explained above and use it for testing, bug fixing, feature additions etc. The community developers can contribute to project by uploading the changes to the review server using the repo tool. Android has also made available an online code-review tool, Gerrit, for managing the review process. The changes will become part of the Android after the project owner reviews and approves the changes.
OEMs/ODMs who wish to use Android as a platform for their device obtains it from the public repositories or gets it directly from OHA with possible support. They customize the platform to suite their needs and deploys it. They may choose to keep the changes private to them or contribute it back to Android project. In Android platform the only component with a 'copy-left' license is the Linux kernel (GPLv2) and all other components uses licenses like Apache2/BSD which allows keeping the copyrights on modified work.
Android application developers can download the Android SDK and develop applications that run on phones/devices based on Android platform. The applications can be hosted in 'Android Market Place', an online store managed by the Android project itself, from where the end users can download it for use. There are also other third party maintained online stores where the Android applications can be hosted for distribution.
Finally there are telecom carriers or service providers who distribute Android based mobile phones and pushes updates to the users. When ever there are significant changes in the Android stack and ODMs have adapted it to their devices, the changes can be propagated to the end users through the carriers. As of now the only Android mobile device available is ‘T-Mobile G1’ and is available only in US with a lock-in to carrier.
Android kernel, a modified Linux-2.6.27 kernel, acts as the hardware abstraction layer for the platform and provides low level services like process management & scheduling, memory management, IPC etc for the upper layers. The Linux kernel has been modified to provide better power saving and hence extend the battery life which is critical for mobile applications. The kernel provides driver support for various devices to be used on the system. Android has added provisions for easily implementation of proprietary user space driver in a thin layer above the kernel to solve intellectual property issues.
Figure 1. Layers of Android Stack
On top of the kernel and thin layer of proprietary user space drivers is a set of core libraries written in C programming language. These provide services fundamental to the system and which is performance critical. Some of functionalities implemented in this layer include basic C library functions & wrapper functions for kernel system calls (libc), 2D/3D graphics engine, media codecs, webkit, SQLlite etc. Only platform developers can use these libraries to develop other components or applications using these libraries as none of these are exported to application developers. The main consumers of these services are Android runtime and some Java class libraries accessing the service through native interface (JNI).
The next layer is Android runtime which is responsible for executing and managing all applications running on the system. The runtime consists of a virtual machine called Dalvik, which executes an optimized form of Java byte code called Dex. All Android applications are written using Java language which is compiled to class files or jar files which are eventually converted to Dex format for execution in Android. The runtime also provides a set of core libraries which provides functionalities similar to Java class libraries. The main objective of this approach is to present the developer with the familiar and powerful Java API while able to execute them efficiently on resource constrained environment.
There is an application framework built on top of Android runtime and the native libraries, which provides the application developer visible programming model. This consists of components like window manager, activity manager, content providers, resource manager, telephony manager etc. The Android programming model introduces a few new concepts which are explained in a later section.
Finally we have the Android applications running on top of the provided application framework. Applications could be those which come bundled with the device or downloaded from the Android market place. On devices, like T-Mobile G1, which allows USB debugging, users can run and test their own applications.
Android introduces a few new terminologies and concepts to the Android application developer. Android supports application development using Java as the programming language. It also provides many of the core functionalities provided by the Java class libraries so that a Java application developer can easily start developing applications for Android platform. Though the interface to the application developer is similar to Java, behind the scenes things are not really Java or compatible with native Java. The Java applications written for android are converted to special format called 'Dex' at build time before packaged and run on an Android system by a special byte code interpreter Dalvik. Android provides a SDK consisting of both command line tools and an Eclipse plug-in (ADT) based GUI which hides most of these details from the applications developer. But following are few new concepts that an Android application developer needs to understand -
Android applications consist of compiled Java code in Dex format and any resource/data file required by the application archived in '.apk' file. The APK file is created automatically by the Android build and is the file actually downloaded to target devices. That is the physical part of Android of application and it is a bit similar to Jar files in java except that APK file has quite some features that is not found in normal Jar files.
Some of the logical components of an Android application are Activities & Intents, Services, Broadcast receivers, Content Providers etc.
Activities represent a visual interface to a user for a particular task. An application can consist of one or more activities which are activated using 'Intents'. 'Intents' are special messages passed between different activities and act as trigger for switching from one activity to another. 'Intents' can be considered as request for particular feature or functionality and can be generated by applications or framework itself. The activities that are part of an application and the 'Intents' which it can handle are defined in a manifest file that is part of the application APK file. The 'OnCreate' function of an activity class will be the usual starting point for the execution of application code.
Services are components of the application that doesn't have a visual user interface and runs in the background performing its tasks. It is possible to connect to a running service and communicate with it using interfaces exposed by it. A typical example is a media player service which allows connected clients to pause, stop or play music.
Another component that can be part of an application is Broadcast receivers. As the name suggests they respond to broadcast messages from the system or other applications. A broadcast receiver doesn’t have UI of its own but may trigger an activity by sending an 'Intent’ message. An example for broadcast message could be 'battery low' from the system.
Yet another important part of Android applications is Content providers. Content Providers allows applications to export its data to other applications in a simple and efficient manner. Content providers allow applications to work without the knowledge of actual form/source of the data.
Android has feature a called AIDL (Android Interface Definition Language) which allows the applications developers to specify methods of a class that needs to be exposed to other applications in a '.aidl' file. The Android platform will take care of generating the code for marshalling and communication between the two processes.
The Android comes with quite a number of handy tools for development and debugging and is difficult to give explanation for each. More details can be found at Android developer’s web site http://developer.android.com/.
Though Linux kernel serves as the base for Android platform, much of the components on top of it are not the usual counter parts from other popular Linux distributions. In fact the changes are so fundamental that none of the standard Linux applications or Libraries can be used inside Android without considerable changes. But these are things only for platform developers to worry about and Android have done a good job in hiding these details and presenting a familiar Java interface to application developers. (Even though every component of android is customizable or replaceable, the OEMs/ODMs/carriers mostly restrict changes to core components and allow only new application installation by end users). Much of the changes are as part of getting rid of unwanted/bulky features not relevant for mobile systems and getting a highly optimized platform for resource constrained systems. Quick glances to major changes follows -
At first we will check some of the changes made to adopt Linux-2.6.27 kernel for Android platform. Power management subsystem of the kernel has been modified for more aggressive power saving and introduces a new 'wakelock' mechanism which allows the user-space applications to tell its actual resource requirements to kernel. Another major change is shared memory based IPC mechanism called 'Binder' tailor designed for Android with less overheads and better performance. Another noticeable change is the usage of YAFFS as the flash file system instead of the JFFS which is part of the vanilla kernel. Android also added a few drivers like ashmem (anonymous shared memory), alarm (based on RTC), logger, low memory killer, debugger etc.
One of the most significant changes in Android is 'Bionic', a small, custom C library instead of the normal glibc used in normal Linux stacks. 'Bionic' is BSD C library modified to reduce the memory foot print and achieve faster execution on systems with limited resources. It lacks many of the glibc features like locales, wide character support etc and has its own miniature implementation of pthreads. Another reason for having Bionic is to completely avoid GPL (copy-left) licenses from user space. This is so one major problems for running standard Linux applications in Android platform as most of them will be based on glibc.
Another noticeable change is in the Android runtime – the component responsible for running android applications. Android applications are written using Java language and executed by Android runtime. But the Android runtime doesn't use the standard JVM or byte code, but its own virtual machine called 'Dalvik' and byte code known as 'Dex'. Dalvik tries to be lesser memory hungry VM suitable for mobile devices and Dex is designed to execute Java code with less power (I.e. less CPU/memory cycles). Android provides a tool called 'dx' as part of its SDK which can convert Java byte codes to Dex format for use on Android. The Android runtime includes core libraries that provides functionality similar to java class library but is taken from Apache harmony project. Here too, Android is trying to optimize the system for mobile devices by changing the internals and to reduce the impact on application developers.
Another section that contains major changes is graphics and user interface. Android doesn't support the Linux native graphics/windowing/UI framework. It comes with its own custom 2D graphics library and supports 3D using 'OpenGL ES' (embedded flavor of OpenGL) using 'skia' graphics engine on top of the kernel frame buffer driver. Application developers doesn't have to access to this native C/C++ libraries, but have to use the higher level graphical primitives implemented in Java.
Android also provides location/maps APIs not found on desktop Linux systems. This allows the developers to create location services/applications or to integrate location based services inside their applications. Another noticeable change is a webkit based browser instead of using any existing browsers. Android also adds support for media codecs, speech recognition, voice search etc that are more important on mobile platforms.
The first android device to come out in market is T-Mobile's G1 mobile phone. The device is based on Android-1.0 release and was available for purchase in US market by the end of 2008 and was later released in Europe. While T-Mobile and HTC is preparing for the second version of Android mobile, others like Motorola, Samsung etc are planning to roll out their own Android mobile phones.
Mean while OHA is further improving and extending Android and getting ready for 1.5 releases. This release, apart from the overall performance improvements, also provides new features like newer linux-2.6.27 kernel, on-screen keyboard, live folders, accelerometer based screen rotations etc. There is already an Android port available for MIPS architecture and news indicate Android Netbooks coming in market by 2010.
In general Android turns out to be a feature rich, reliable platform for deploying on small embedded systems, especially mobile phones. Even though early adoption rate is sluggish, it has got all the potential to evolve as the key player in the mobile market. With many OEMs considering Android as the platform for their Net-book devices, it can play a crucial role in convergence of mobile devices and Net-books. The Open Handset Alliance member covers a broad spectrum of technology which indicates possible adoption of Android on other embedded devices like GPS, set-top box etc. One of the challenges for Android will be ensure that community developers are not deterred by the lack of copy-left license and breaking the initial inertia for adoption.