Andy Rubin

Back in 2002, Andy Rubin was the CEO of Danger, Inc - an 80 employee startup in Palo Alto which had just secured $48 million in venture capital. Danger then launched the Hiptop, a fashionable mobile device easily recognisable today as an early smartphone. For its time, it was revolutionary - a combination of cool style with such essentials as email and web browsing - and would raise the bar for the whole industry from that point on, including, ironically, Apple, where you'd have found Andy earlier on in his career.

Fast forward to 2005 and Andy, who owned the domain name android.com, used all the knowledge, experience and enthusiasm he had to start a new venture taking its name from his unused domain - Android. Google had been looking for exactly such a system and so bought the whole setup very quickly after its formation.

Java

There had been a great many standards implemented in the mobile handset industry before Android was launched. For handsets to be accepted in the marketplace, some such as SMS and bluetooth had to be implemented no matter what. After all, interoperability is what all communications devices are designed for. However there are still a great many things the creators can choose to do differently. Java was present on almost all new handsets when Android was announced but in its restricted J2ME MIDP format. The core operating systems were often proprietary C++ platforms, as that was what the hardware and software used in embedded system was geared up to. Java on these handsets was almost an afterthought, a service-upon-a-service that you often felt the manufacturers grudgingly had to install for their handsets to be accepted by the carriers. Of course they thought they'd leave java for the games and toys but use C++ for all the real stuff, arguing java still wasn't good enough for the job.

 

Linux

Each of the top handset manufacturers had designed their own proprietary operating system. The need for a common one, to avoid each of them re-inventing the wheel, was recognised and gave rise to Symbian. None of the major Symbian licencees dropped their own OS however, so this vision of one operating system to rule them all was never realised. In parallel, Linux was growing in maturity and popularity at an incredible rate. The LIMO consortium was created in response to modern hardware being able at last to support the speed, memory and power requirements of Linux on a handheld device.

 

Android = Java + Linux

Google used the best of the Linux know-how available, plus their own source-compatible implementation of java, called "Dalvik", as the foundation for Android. Furthermore they gave it away! True to their Open Source roots, the method of this upside-down business model isn't so strange when you realise they want to promote advertising throughout the entire internet, as that's what made them the business they are today. What better way than to own a platform which will be widely adopted - and what better way to guarantee that than to give it away?

An established user base can be a curse, a blessing, or both. Every decision relating to future change must balance the disruption caused to existing users with the benefits offered to them and new users. Legacy baggage can become so overwhelming that small incremental changes are no longer possible - it's time to start afresh using state-of-the-art techniques, encompassing and enhancing the best of what's gone before whilst ditching the worst.

 

Here's an insight into the Android architecture:

 

 

 

 

To create the eco-system needed to thrive, developers are needed. Google created the Android Marketplace, which itself blows away the existing app delivery systems, to simplify things considerably for the end user. It's important to realise just how how much resistance there is to users being asked to install software on their handsets the old way - they perceive it as cumbersome and too fiddly to bother with. That's if you can get them to even hear about your software in the first place. The industry used the term off-deck to describe the process of getting a user to do something away from the handset, or handset's default software, to install your app, such as visit a website or send an SMS. In contrast, on-deck systems are a breeze for the user - they see a list of available apps that they can load right after first powering on the handset. From then on, one click and it's theirs. Payment is also typically transparent; often a charge being made to their bill at the end of the month. So, having created the ideal on-deck system, content is required.

 

This video goes into further depth regarding Android internals:

 

 

 
 
With a software-only solution, Android can be used on every physical variation of a handset seen so far. Imagine a candybar numeric-only model, a flip screen version, superslim mp3 player or even an ultra low cost implementation sold by the checkouts at supermarkets. Its customisation abilities are pretty awesome too - expect to see a few handsets launched from companies you wouldn't normally expect to launch phones, for example Dell has been rumoured for a while now.