Let\u2019s first take a look at Android from the bottom up. It encompasses an operating system (OS), middleware, an application framework, a toolset and an open source community. The OS consists of a set of Android-specific patches on top of a Linux kernel. These patches add the Android vision for low-memory, power-sensitive processors by modifying the kernel\u2019s memory management, power management and inter-process communication (aka, its binder). Unlike traditional Linux where processes slowly starve as memory runs low until the \u2018out of memory\u2019 (OOM) killer activates, the Android kernel adds further intelligence by categorizing processes with respect to user importance.<\/p>\n
Processes in the least important group are killed to keep a system responsive. For example, the foreground user interface (UI) is likely to be of highest priority, though you can of course set these priorities according to your specific product requirements. Android also introduces the notion of \u201cWakeLocks,\u201d which supply power to particular peripherals, such as LCDs and backlights, and turns them off when they\u2019re not needed. Finally, Android\u2019s IPC driver\u2014binder\u2014is added to the kernel. Binder is a rewritten (thus Apache v2 licensed) and trimmed-down version of OpenBinder that provides resource sharing and assignment, and process management during runtime. It is this lightweight processor focus that turns a desktop-centric Linux kernel into an attractive embedded OS.<\/p>\n
The three recurring themes in Android middleware are Apache licensing, library breadth and the Dalvik Virtual Machine (DVM). Android has gone to excessive lengths to place the entire user space stack under an Apache v2 license, speeding its commercial adoption rate amongst those apprehensive about working with the GNU General Public License. Apache-licensed software can be integrated into proprietary projects without imposing the source redistribution requirements of \u2018copyleft\u2019 licenses like GPL.<\/p>\n
Bionic is Android\u2019s C runtime library. It differs from the widely used \u2018glibc\u2019 in that it lacks features like full \u2018pthread\u2019 and \u2018SysV\u2019 support. If you already have large glibc-compatible C libraries, there may be migration pains in moving to bionic, so you may choose to continue using glibc. On the other hand, bionic uses the very liberal BSD licensing scheme and is considerably smaller and slightly faster than its counterpart.<\/p>\n
In addition to the C library, Android comes with libraries for both 2D and 3D graphics, Web technologies, databases, multimedia and more. Instead of receiving a Linux base port from the silicon vendor and either paying a third party for a complete development file system or painstakingly assembling one yourself, the Android base port already provides this level of system integration.<\/p>\n
Every Android application runs in its own DVM, which in turn leverages the Android kernel patches for memory and process management. Unlike traditional virtual machines (which stereotypically perform poorly), the DVM was designed like the rest of Android to reduce the memory footprint by stripping duplicate constants, linking inline functions and using an optimized DVM instruction set (as opposed to Java bytecode). The DVM is also register-based and this can help to reduce the number of instructions and increase bytecode efficiency. Finally, the DVM was specifically optimized for multiple instantiations as most modern devices should be able to run multiple applications simultaneously.<\/p>\n
Android\u2019s expansive API provides the app developer access to a variety of hardware resources without forcing him or her to worry about their exact implementation. In fact, the Android SDK comes with an ARM simulator that runs on an x86 host to allow application development without specific hardware. And since Android shares Java\u2019s syntax and practices, application developers are widely available. Once applications are created, they can be moved across hardware platforms (and vendors) with relative ease. This lends itself well to the creation of scalable low-end and high-end products.<\/p>\n
This is a complete system that is ready to deploy if you only need to use the functionality provided by Android. The model works well if you do not want to choose among the almost-infinite open source options (and dependencies) available in a traditional Linux stack, or have the time or energy to migrate your applications with the rapidly evolving open source software underneath. However, it is likely that you have legacy system code to support or require software resources that are not provided in the Android stack. The Android Native Development Kit (NDK) allows C or C++ code to be built into native libraries to be run in the DVM and to be packaged into Android application packages (*.apk) for device deployment.<\/p>\n
Closely associated with Android is the notion of an \u201cApp Store,\u201d but this does not necessarily imply an iTunes-like experience. Android devices can have their own custom app stores launched by the hardware manufacturer, such as AppsLib from media player specialist Archos. Depending on the design, you may want end-users to be able to install their own *.apk packages as they become available online. For example, a home automation system user could download a weather app or a shopping list app according to his or her fancy. In this way, a device\u2019s software is no longer limited by your resources, but open to thousands of other applications just as you would expect in a desktop environment.<\/p>\n
Android has built-in checks to verify the app can be supported by the version of the platform installed on the device. In a more closed system, the store concept can be used to simply and safely upgrade or add features to units deployed to the field, such as POS terminals needing an updated SKU database or extra data field in the GUI. Conversely, if a device is Google-approved, users can download applications directly from the Android Market, which provides a full mobile phone experience.<\/p>\n
For most applications, the basic Android look and feel is advantageous as users highly associate it with a strong brand. But how do you take advantage of Android here if you want or need to retain a custom look? Custom branding has already occurred in cell phones, such as the HTC Droid Eris, which sports HTC\u2019s custom Sense user interface (UI) overlay. One way to achieve such customization is by leveraging commercial UI engines, such as Mentor Graphic\u2019s Inflexion software. It includes GUI builders and smooth integration on top of Android\u2019s native interface.<\/p>\n
Thus far, we have primarily viewed Android as a close relative to Linux with several advantages. How does it fare compared to Windows CE?<\/p>\n
They both provide single-source tooling\u2014that is, you can get your development IDE, compiler and debug tools from a single vendor. Of course, that is not to say that more advanced options are not available from third parties, but the point is that you can get to production without additional tools.<\/p>\n
Both Android and CE also provide application frameworks that enable massive numbers of application developers and allow for faster development time as less time is spent on middleware.<\/p>\n
However, their primary differences favor Android. Cost\u2014you can\u2019t beat free, both in per-seat development costs and runtime royalties. Licensing\u2014were you hoping to modify and redistribute source code?<\/p>\n
Let\u2019s start customizing<\/strong><\/h3>\nIf Android sounds appealing, let\u2019s review what you need to get started. First and foremost, you need an Android base port and a development board. Texas Instruments\u2019 OMAP35x product generation is particularly suited for Android with its high-performance Cortex-A8 GPU, SGX vector graphics accelerator, and C64x+ DSP, coupled with low power performance (Figure 1, p. 27).<\/p>\n
![\"\"](\"\/edasource\/images\/72\/esd1004_ti1_medium.jpg\")
<\/a><\/div>\n\nFigure 1<\/span>
\nAndroid Software Stack on OMAP3530
\nSource: Texas Instruments<\/p>\n<\/div>\nThe OMAP35x family consists of four devices, with varying combinations of the SGX and DSP, thus allowing end-product scaling. For example, Android on an OMAP3503 can make use of ARM-side multimedia codecs, whereas an OMAP3530 can seamlessly utilize DSP codecs without changing any application level code. Similarly, an Android application on OMAP3525 can still render 3D OpenGLES graphics via ARM, whereas the flagship OMAP3530 would make use of the SGX vector graphics accelerator, again, hidden beneath the Android framework.<\/p>\n
Texas Instruments\u2019 OMAP35x family also includes a variety of development boards, ranging from TI\u2019s OMAP3530 Evaluation Module complete with a touch-screen LCD to the low-cost BeagleBoard at only $149 (Figure 2). The BeagleBoard has attracted a large community of developers with projects ranging from SDR to license plate recognition, available at beagleboard.org. An Android base port for OMAP35x is available at www.arowboat.org<\/a> and includes the complete source code as well as documentation to start your development. To recap, the full OMAP35x family is shown in Figure 3.<\/p>\n![\"\"](\"\/edasource\/images\/74\/esd1004_ti3_medium.jpg\")
<\/a><\/div>\n
![\"\"](\"\/edasource\/images\/72\/esd1004_ti1_large.jpg\")
<\/a><\/div>\nFigure 1<\/span> The OMAP35x family consists of four devices, with varying combinations of the SGX and DSP, thus allowing end-product scaling. For example, Android on an OMAP3503 can make use of ARM-side multimedia codecs, whereas an OMAP3530 can seamlessly utilize DSP codecs without changing any application level code. Similarly, an Android application on OMAP3525 can still render 3D OpenGLES graphics via ARM, whereas the flagship OMAP3530 would make use of the SGX vector graphics accelerator, again, hidden beneath the Android framework.<\/p>\n Texas Instruments\u2019 OMAP35x family also includes a variety of development boards, ranging from TI\u2019s OMAP3530 Evaluation Module complete with a touch-screen LCD to the low-cost BeagleBoard at only $149 (Figure 2). The BeagleBoard has attracted a large community of developers with projects ranging from SDR to license plate recognition, available at beagleboard.org. An Android base port for OMAP35x is available at www.arowboat.org<\/a> and includes the complete source code as well as documentation to start your development. To recap, the full OMAP35x family is shown in Figure 3.<\/p>\n
\nAndroid Software Stack on OMAP3530
\nSource: Texas Instruments<\/p>\n<\/div>\n<\/a><\/div>\n