You know a company is making a success of something when their name becomes used as a general term. Google is now a verb, and a synonym for searching the Internet. But the team that has been at the Googleplex in the last few years don’t want to stop there. They seem to have a determination to take over the world, or at least the connected bits of it. Gmail, Google Docs and the Chrome browser are well established. The Chrome OS is a new kind of OS, where a notebook computer uses HTML5 to run all its apps in the cloud – residing on servers somewhere or other – owned, presumably, by Google. Even things like printing will be through the net to internet-attached printers (although thin clients and a central server were being heavily touted some years ago.) Chrome OS is in beta at the moment, and several manufacturers are working on machines that meet the Chrome OS specification.

Google, so far, has only defined a Chrome machine: it has yet to come up with its own brand of hardware. In TV, Google TV is at the moment running mainly on Sony and Logitech hardware and there is no Google labelled box. However, Google is selling an own-brand phone, using the same software platform for smart phones that it has provided, through the Open Handset Alliance, to, amongst others, Samsung, LG, HTC, Dell, Motorola and Sony Ericson. And it seems that the same platform has recently overtaken Symbian as the number one software for mobile phones. Analysts at Canalys have published their view of the Q4 2010 smart phone market, and their figures show Symbian shipping in 31 million phones while Android was in 32.9 million. (And Canalys estimates that there were 300 million smart phones shipped in 2010.)

The Google platform is Android, and details of version 3.0 (code name Honeycomb) have recently been announced. (Someone in Google obviously has a sweet tooth, with previous versions called Gingerbread, Éclair, Donut and Cupcake.) And the announcement and demos of Honeycomb show Google aiming it not just at smart phones, but also at tablets — a head-on challenge to Apple’s iPad.

Now you may have noticed that I have carefully avoided using the term operating system when talking about Android. This is because, when I spoke to Colin Walls at Mentor and asked, “Why do we need a new Operating System?” he pointed out that Android runs on top of Linux, rather like Windows, in its earliest incarnations, ran on top of DOS (for those of you who can remember Windows before Version 3.1). But having made the point, it is fair to say that most of the Mentor literature, and virtually every other writer on the topic, calls it the Android OS.

Mentor is pushing Android as a platform “beyond the mobile phone.” Specifically, the company sees it as useful not just for tablets and TVs, but also for application areas such as medicine. In this and other embedded applications, there are often two sets of processing demands: the need for the detailed real-time control of the hardware, normally linked with the need to process a data stream, and the need for a rich human machine interface to provide unambiguous control. Increasingly, these two tasks are handled by two operating systems, either running on separate processors, on separate cores of a multicore processor, or on virtualized instances of a single processor. In this case, an RTOS is dedicated to managing the system functionality while a different OS handles the user interface and other communication with the rest of the world. This role is, Mentor argues, something for which Android is well suited.

Android is freely available for download as open source software and is distributed under BSD or Apache 2.0 licenses, which have fewer restrictions on revealing code changes than the GPL. It is built in a series of layers.  At the bottom is the Linux kernel. This looks after a load of the grunt work of memory management, power management, and some aspects of interfacing and communication, with drivers for keypad, WiFi, audio etc.

The next layer up is a collection of libraries. The libc C library, written in a Google-specific flavour of C called Bionic, provides functions for other libraries and applications. Alongside are multimedia and graphics libraries, SQLite database, OpenSSL and WebKit, with a Java engine for HTML pages. Also in this level is the core of Android, the Android Runtime, which has core libraries and the Dalvik Virtual Machine. DalvikVM uses a register-based architecture, as opposed to the JVM’s stack-based approach. (While there are theoretical arguments about which is the best architectural approach, a different architecture may also be interpreted as an attempt to avoid possible legal issues with Sun, the company behind Java. However, now that Oracle has acquired Sun, it has been aggressive over “protecting” the IP in Java and has filed suit against Google, alleging multiple patent infringements.)

With a different architecture, Dalvik uses its own byte code, converted from standard JavaVM byte code by a special compiler called DEX. Since Android runs only on Linux, it can couple Dalvik and Linux tightly. Each Android application runs in its own instance of the DalvikVM.

Climbing up, the next layer is the Android Application Framework. This manages both applications in Android and the system functions and resources with a set of Java-based services and systems. It also allows applications to share functionality.

And at the top we have Android Applications (apps), which are loaded into Android as a package (.apk) containing both the DalvikVM byte code and metadata for the services in the Application framework.

Developers creating Apps for Android have the Android Market, a non-exclusive central resource hosted by Google, where they can post free apps or charge for them, subject to a Market Programme Policy that bars, for example, pornography. (As, unlike Apple, anyone can post Android apps wherever they like, if you really want porn on your Android phone, there are 8,450,000 results in a Google search.)

The Linux underpinning makes it easier to port Android to a range of platforms. Widely available for ARM, as we saw last week it is now available for Power Architecture with a port that involved Mentor. So back to the initial question – why is Mentor interested in Android?

Mainly because it is going to be very widely used in embedded applications. It is relatively small, relatively fast software that provides a straightforward way of adding interfacing and communications to products or, when real time and extensive data stream processing are not issues, to support the entire application. It also has the advantage of implementing the “Write once, run many” paradigm, making apps easily portable across implementations. An example might be an in-car infotainment system. Android already has touch-screen control and all the communication interfacing that you need for talking to the car communications bus. Mobile phones already support satellite positioning, maps and radio reception. Adding automotive-specific applications would allow a manufacturer to create a family of Android-based devices with different levels of sophistication.

Mentor already offers Android consulting and implementation services, making it easier for companies to gain the advantage of Android without a massive investment in learning. A typical change might be to add the ability to drive larger screens than the standard sizes already supported. And the company has also created Inflexion UI for Android, a toolkit that allows developers to very rapidly create sophisticated user interfaces, including complex 3D images and animations and families of variants on a basic theme.

Mentor is not the only company that sees Android as a future revenue stream. In just the last week, Enea, the Sweden-based service company, launched an Android Competence Centre. This will work with companies who want to extend Android, either through support and consulting or through full-scale project development. Empress, a US based developer of embedded databases, announced a software development kit for implementing its database on Android. And analyst company VDC reported strong evidence of Android spreading through the embedded application space.

In a slightly different area, NXP and Giesecke & Devrient announced Near Field Communication (NFC) for mobile handsets running Android, with a handset using NFC due in Q2 2011. This will bring to fruition the use of NFC and cell phones for mobile payments, access control, and data sharing.

And these are in addition to existing resources, from Google, from a dedicated Android web site, and from the Open Handset Alliance. ARM has a valuable Android portal/resource centre on the company’s web site.

The momentum is building behind Android.  It is not a holy grail (although doubtless we will see religious wars between Androids and Microsofties and others). It is an interesting and powerful alternative to consider when thinking about the software for your next embedded product.