From what it seems to me, Google had launched this platform not because Google wants to make any profit by directly selling the platform but the key idea is to have the reach of google search beyond desktops to mobiles, PDAs and other similar devices. The benefit that it incurs to Google is pretty obvious, that is, Google Ads to each and every device using Android platform.
What Android Isn’t?
- It is not really another GNU/Linux distribution.
- It is not a desktop Operating System.
- It is not the holy grail to solve all your problems.
What Android is?
Android is a Linux Kernel based OS primarily targeted for small and memory limited devices.
Why Another OS specially Linux based when there are plenty of proprietary OS and flavors of embedded linux?
The trouble with proprietary Operating Systems / platforms:
The trouble with proprietary OS is that they are closed source and access to them is limited:). Until now if you really had to write an application for a device running a proprietary OS, then it would require you to have a hardware device + license to proprietary SDK which would provide tools for building, testing and packaging the apps and sometimes you would need to pay a royalty fees for your application to the OS/ Hardware vendor. Though this situation is changing and there are couple of platforms like Maemo, Moblin, Mobilinux, OpenMoko, BadaOS, most of which are based on open source software but currently there isn’t much thrust that is behind any of these projects.
Trouble with Open Source Operating Systems/ Platforms
As such there is no trouble with Embedded Linux based distributions but for an application developer, there isn’t a consistency that exists on Embedded Linux platforms. From the perspective of application developer, one could not be sure that a certain device, library or feature would be definitely present on the device for which he wants to write the application.
Trouble with Embedded platforms (Open or Closed)
There was no way an application developer could write an application for a particular device, without getting directly involved with the device / OS manufacturer. If someone had the idea of a device or an application for small consumer device, then to build such a device required buying very expensive embedded platforms, lot of software support, cross compilation toolchains, OS, customized bootloaders, customized kernel, Board support packages etc. Though some of the software components would come for free with the hardware, but the cost of the hardware was so enormous that it was virtually impossible for an individual to even make a prototype of an embedded device. The second problem was that there was no ecosystem in place until now which one could use to develop applications for embedded devices. Thus most device manufacturing companies ended up making complete software platforms for the device with required hardware, software features. There was no contribution or involvement from community in this cycle. This trend really got broken with Iphone where Apple opened up the application development platform to developers. Anyone who could own a Mac book and an Iphone, could now write an application and sell it in the market. Soon after the success of this model, now most platforms like Maemo, BadaOS etc. are trying to follow almost the same model.
The idea behind, Google acquiring Android Inc., the company which made Android, was to have a unified, open platform for mobiles phones, PDA, Nettops, MIDs etc. just like what IPhone offers but at the same time making it an Open Platform for developers and OEMs/ ODMs alike.
What Android offers?
Android Core OS:
- A modified Linux kernel
- Libraries for graphics, multimedia, data storage, font etc.
- Android Runtime consisting of Android Core libraries and a Java Virtual Machine
- An Application framework for rapid development; consistent look and feel, interaction and behavior of applications.
- Some basic applications
Android SDK and SDK tools:
- A comprehensive set of Java APIs for application development
- Packaging tool
- Java code Debugging Tools
- A QEMU based Emulator for running Android applications
- AVD Manager, an application to manage and create Android Virtual devices
- ADB, aka Android debugger for connecting and debugging Android Device.
- Cross Compiler and other related tools for ARMv5
- Headers, includes and libraries for building native libraries
- A build system to easily build native libraries for Android platform
- An Eclipse Plugin for rapid development of Android Apps in Eclipse
Java as default programming language
The default or the recommended way of writing apps on Android is using Java with Android provided Java APIs for most tasks. This model has probably been chosen so that there is a consistent way of writing, testing, debugging and deploying an Android application, along with the added benefit of having a consistent look and feel. There is no way one can simply port and install a C application with Main entry point to be run on the Android platform. Even for the apps that written in Java there is no main entry point.
Activity Based instead of Command Based Human <—> Device interaction
Android has abstracted out the way a User interacts with the Operating System in form of activities instead of making User -> Device interaction as file / document based. What that really means is that usually a User wants to do something with the device like making a phone call, editing a spreadsheet, adding contacts, etc. Android calls this as Activity and a user transitions from Activity to Activity.
Even with so many choices of embedded OS, the application development for a developer is not easy and most of the times developers end up solving lots of platform and systemic issues instead of focusing on application development. Android aims to solve this problem by providing an Open platform for device manufacturers and developers alike, with a comprehensive set of tools for application development, testing and debugging. It comes with all the good features of the Linux kernel with added open source packages which are useful and required in most devices. Access to h/w, devices and OS functionality is hidden to application developers behind the Android’s Java APIs. Overall the platform looks promising but there are two problems that concern most developers.
1. Performance issues as Android applications run on top of a Java Virtual Machine
2. Porting of existing native apps is not possible without rewriting them in Java
With Google’s backing, everyone seems to have an impression that Android will be ‘the’ OS for small and medium size devices. Surely with Google doing a lot of ‘right’ things, strong technical and management leadership, strong financial backing, everyone is bound to believe whatever move Google makes. Only the time and market dynamics will tell if Android is here to stay or not.