Should you think about using Android in your embedded product?

Originally developed as an OS for high end handsets, Android was introduced by Google in 2007. Since then, Google has updated Android's capabilities continually and, arguably, it is well on its way to becoming a general purpose computing platform. Android is one of a small number of open source mobile device OSs. Frankly, when it comes to mass market portable devices, the use of Android is pretty much a 'no brainer'. For other devices, the decision is less clear cut. Here are some of the plus points. • Android simplifies the process of designing and producing new products. You get a more professional product and quicker time to market. • Android gives you a sophisticated, highly capable embedded OS out of the box with an easy to use modern graphical user interface. • Android makes it easy to incorporate devices, sensors and software. • Android gives your product access to (potentially) hundreds of thousands of apps from developers around the world via the internet. • Anyone with the requisite software skills can develop and deploy their own apps. • Android is customisable, allowing both product and App developers to change its behaviour and appearance. • Android is written in common programming languages, which simplifies the process of finding engineers with the right skills. • Android is made available free of licences or royalties, although certain optional components may involve up front fees and royalties. Pointers Here are some pointers, based on Plextek's experience, that may help developers port Android to new hardware. Android is an embedded stack written in a mixture of Java and C++, running on top of a customised embedded Linux kernel written almost entirely in C. One might characterise it as the illegitimate offspring of Linux and Java. In order to port it to your hardware, you will need significant expertise in embedded OSs, as well as of languages. Until recently, Android has been restricted to running on ARM processors, although x86 ports with restricted capabilities did exist. Intel and Google have put a lot of effort into porting Android to the x86 architecture and Intel claims the x86 'Medfield' chipset delivers significant performance improvements over multicore ARM based devices. However, the limited number of benchmarks available suggest that performance and battery life are in the same ballpark as dual core ARM based products. Android's architecture is, to put it kindly, baroque. Functionality is generally spread across a range of subsystems. These are built from software modules, which are often split into separate processes, thereby incurring additional communication and scheduling overheads. Meanwhile, adding a new class of hardware to Android is complex, unless you can shoehorn it into an existing Java API. Android assumes a relatively capable hardware platform, with at least the following capabilities: high(ish) resolution colour graphical display; touchscreen, mouse or similar input device; high end processor, with at least a 2d hardware graphics accelerator; at least 512Mbyte of dram (1Gbyte or more is better); and at least 2Gbyte of non volatile storage (usually flash. You can get Android to run on less capable hardware, but ask yourself why you would want to do this. Other embedded operating systems, such as Windows CE, are designed to work on less capable hardware than Android requires and these may be more suitable for low end products, especially if they do not need a sophisticated interface. Android's power management scheme assumes a permanently on power supply (generally a rechargable battery) from which you can take as much current as you need. Android can take up to 60s to boot and several seconds to suspend itself to ram. Android apps can also prevent a suspend happening for arbitrarily long periods and this can have a massive impact on the amount of power the device uses. Android also takes a long time to shut itself down completely (typically up to 20s). You can simply turn off the power, but this risks losing system state information and, potentially, corrupting the file system. Care must also be taken to ensure that persistent file stores (generally formatted as Linux and FAT file systems) are not corrupted. Android source code is largely undocumented and what documentation exists is often out of date or wrong. You just have to work out for yourself what it's doing, or else hope that somebody has already done the same thing and put the information on the web. Android consists of approximately 250k files, split into around 200 Git repositories, which vary in size from a few Mbyte to more than 1Gbyte. While there is a command line tool (repo) and a collaborative Git based server (Gerrit) to manage all of this, they're not good – especially repo. You have to keep switching between Git and repo, because repo won't do some things and Git won't do others. Repo assumes you always want to commit all changes to a single branch in Gerrit – nobody would want to do that differently, would they? You can edit a config file to tell Gerrit which branch you want to use, but woe betide if you forget to change it before you push your latest changes up to Gerrit. Git branches in individual repositories do not get propagated into the Gerrit Git repository, although you have to create them in order to persuade repo/Gerrit to upload your changes. This is the worst of both worlds. Gerrit is finicky and tends to get upset if you do things in the wrong order. It can also be tricky to recover from simple mistakes. By contrast, there is a variety of Unix/Linux derived OSs available – some suitable for use in embedded products. In general, these are best for closed products, which don't allow the user to install apps. The main advantage of these systems is that, like Android, they are largely licence and royalty free. The choice of which specific OS to use must be made on a case by case basis. Patent issues apart, Android is royalty/licence free and Google charges manufacturers nothing to use it. It is widely deployed in a variety of products and has the largest market share of any embedded OS. In the end, the choice of an OS isn't simple and it's rarely a no brainer. For many software developers, Android is the best OS out there but it does have limitations and, for some products, another OS may prove a better choice. Alan Levy is a senior project consultant with Plextek.