Android is out and it seems pretty well designed. This is the first of what’s hopefully going to be a series of articles covering Android from cosmix.org. It’s also going to be the least technical in nature as I haven’t had much time to play around with it and also because introductions should rarely be too technical, anyway. Before we start, take a few minutes to watch the following video. It will provide a pretty informative quick glance as to how applications look on Android prototypes.
Android is based on Linux 2.6 and is complemented by a Virtual Machine (Dalvik) and a number of Core Libraries written in Java and supported by a number of popular native open source libraries: OpenGL|ES, Webkit (the web browsing engine that originated in KDE and is now powering a number of browsers, most prominently Apple’s Safari and KDE’s Konqueror), FreeType (the open source font rasterisation engine), a Media Framework courtesy of PacketVideo, a library for SSL and many others.
At the same level as the native libraries are the Dalvik virtual machine and the Core Libraries and just above them are a number of libraries that form the Application Framework. The Core Libraries and Application Framework are written in Java and essentially expose the high-level API that developers can use to write their applications. In case you’re still wondering, applications in Android are written in Java.
From the video it should be clear that Android provides pretty sophisticated graphics capabilities. Android uses SGL and OpenGL|ES for its graphics needs. It also allows seamless integation of 3D and 2D graphics within an application.
In addition to graphics it exposes really interesting functionality to developers that leverages location, contact, network and content information. Applications in Android are decomposed into four major components: Activity (main UI activities, such as viewing a list of emails or reading an email message), IntentReceiver (notification registration and event triggering), Service (faceless tasks that run in background) and ContentProvider (share data with other applications). This decoupling seems very intuitive in terms of the application development model, but it also provides an excellent modularisation and extension mechanism for adding new functionality to the system and allowing interoperability between applications.
For example, the Location Manager allows geographical proximity triggers to be used by applications. You can leverage GPS or triangulation geographic location information within applications to notify the user when they are approaching their friends, a specific location or a location of a certain type (e.g. an ice cream shop or a hotel). Android also provides an XMPP service, and this seems to be the main way for Android devices to communicate with each other; devices can send text messages, geographic information, other presence data, even gaming data. Obviously a data connection (and preferably an unlimited data plan) are needed. I briefly mentioned events registration and triggering before (this is achieved through the Notification Manager in Android). Finally, Android provides a componetised GUI environment that allows easy combination of views and widgets to create the UI for a new Application. For example, as would be expected, Google provides a WebView and a MapView.
First thoughts
Regarding the performance of the software stack, there are still many questions to be answered. First of all, vanilla linux is not really known for its rich feature-set and suitability for such small devices, although it’s been in use in many of them for years. Neither is Java. Ironically, neither Symbian nor Windows Mobile have historically proven to be fast on most of the mobile devices out there. However, Symbian provides several features that take into account the limited processing power and memory available in mobile phones and smartphones. For example, Symbian’s EKA2 kernel is the only kernel that can allow for a single-chip phone (i.e., having the main CPU of a smartphone perform all the telephony functions too, something that requires excellent real-time response) although some commercial releases as found on mobile devices are far from ‘responsive’ from a user perspective. Linux already supports much of the memory management features that were only recently added to Symbian, such as demand paging, although it is more liberal in its memory and ‘disk’ use. Finally, Symbian has pretty aggressive power saving features that do not come as part of the vanilla linux kernel. It is to be expected that the OHA will be doing extensive work on supporting mobile devices on Android, given their capacity for development and the size of the consortium, so I am quite hopeful that Android will be, from a technical standpoint, close to the state of the art.
The use of Java for much of the Android stack immensely simplifies application development. Similar to Microsoft’s .net strategy, Java applications will not suffer from memory leaks (Symbian provides descriptors and a clean-up stack to tackle these). The performance of the applications on the demonstration video seemed decent and the componetisation of the application is an excellent mechanism for providing higher performance and minimise resource waste.
Developing for Android is free, in contrast to Symbian or Microsoft solutions. Symbian provides a free solution, the Express edition of the Carbide.c++ Eclipse-based IDE, which lacks a proper UI designer and crash debugger. Microsoft offers an SDK that also requires its commercial Visual Studio suite. By comparison, Android does not offer a UI designer in the early look SDK, but already offers a pretty solid open-source foundation for application development, itself built upon an open source infrastructure (Eclipse). I don’t think it will take long before the consortium and the open source community starts improving on the Android development tools.
The fact that the platform is completely free and open-source, but above all modular and customisable is certainly going to allow for much faster innovation over time. Hopefully there is going to be a good balance between commercial and free software availability and development effort on Android.
More information on the development process and architecture will be provided in a future article, as soon as I get the chance to work with it a bit more. In the mean time check out Engadget’s gallery of the Android UI showcasing some of the built-in applications.
For Google videos, presenting much of the above in some more detail check out the AndroidDevelopers channel on YouTube. If you’re a developer, you’ll probably be interested in getting the SDK and joining the Android Developers Google Group.