Top 10 drivers for embedded Android

There will be 115 Google Android phones on the market by the end of 2010, along with 50 non-phone Android devices, according to Jason Schwarz in his investment newsletter, Economic Weather Station. Whether these figures are accurate, the reality is that Android is beginning to move beyond its beginnings in the smartphone form factor to a broad range of embedded devices that span multiple industries and segments.

Why are product managers and chief technology executives making the move to this white-hot platform? Why is Android an attractive technology for such diverse needs as medical devices, set-top boxes, and automotive infotainment systems? There are at least 10 good reasons, five of which are business drivers and five technical drivers.

Business Drivers
Business requirements, especially in the context of technology available under an open-source license, can be compelling for both technology managers and corporate executives. This list is not meant to reflect all Android drivers but certainly some compelling reasons for choosing embedded Android.

1. Licensing: Embedded system development using open-source technology requires that the developer/seller understands the licenses for embedded software components. Android is very attractive because all core packages are open sourced under the terms of the Apache 2.0 license, which allows the usage of the source code for both commercial and free open-source applications. If your team creates a modified version of the source code, it may not have to be licensed under the terms of the original license.

2. Source code: Android provides a comprehensive set of source code, specifically created by the Android team, that leverages existing open-source projects to provide a complete and cohesive software stack. There are currently more than 200 separate Git trees in the public Android repository. Not only is there source for the core packages, but many hardware-component vendors have decided to provide source code for specific drivers. This source is also actively managed by a vibrant community. Clearly, this is a benefit for anybody wanting to optimize these components for a specific target.

Many existing embedded Linux development teams will also find the external packages, such as BlueZ, D-Bus, OpenSSL, and webkit, quite familiar because they are used by other open-source distributions. This reduces your team’s learning curve if you are new to Android and will help speed your development time.

3. Release cadence: Android has a relatively frequent cadence for major releases. Its heritage in the mobile world mandates a much more rapid release cycle, with multiple releases per year being quite common now. While Android seems to be settling in on a biannual release cycle, this rate of innovation can clearly benefit the Android adopter. With new feature support added quite frequently, you may have less to build by yourself and more options from which to select when building your project.

4. Ecosystem support: While the ARM architecture was the focus of most early Android product efforts, virtually all major embedded silicon providers have created and actively maintain an Android base port. These hardware providers are helping speed your time-to-market and are opening up their architectures for you to take advantage.

There is also a large developer community associated with Android, driving not only application layer content (more than 40,000 applications are available), but also Android middleware components, from both augmentation and optimization perspectives. This is critically important for the continued evolution of Android.

5. Documentation and training: The time it takes for your engineering team to become proficient in Android is not free. Clear, concise, up-to-date documentation is critical to get your team enabled. The Android community offers a wide variety of instruction content, videos (some user-created, some from commercial vendors), extensive blogs, and independent companies providing Android academies, best practices, and tutorials.Technical Drivers
This is not an exhaustive list, but it does name the top engineering-based reasons that are driving traditional embedded developers to use Android. It highlights the principal decision points that CTOs and vice presidents of engineering and product management are using to make a decision for Android.

6. Android Java and Dalvik virtual machine: The programming language associated with the upper and middle layers of a software stack is one of the in decision criteria for the technical evaluation of an embedded system stack. Java is a common programming language with a large pool of trained engineers from which to staff your project; and Android is based on the Java programming language, although it uses its own virtual machine, Dalvik. While your engineering team will have to invest in understanding the Android Java libraries and classes and its byte code structure, it is sufficiently similar to Java so that any Java programmer will be able to pick up the code and start working with it very quickly.

7. Hardware reference platforms: One result of the popularity of Android is the wide availability of hardware platforms for prototyping and benchmarking purposes. The primary options for Android hardware reference platforms are ARM-based Android development phones (using Qualcomm silicon), still useful for benchmarking performance of specific sets of libraries or the Android Compliance Test Suite; other hardware-based reference platforms, such as Texas Instruments’ Zoom and Beagleboard reference systems; and a new class of form-factor-approximate development devices for embedded Android system design, such as tablet-, automotive-, and set-top-box-based initiatives for systems-on-chip (SoCs) or boards.

8. Technical frameworks: Android offers new, developing technical frameworks to enable devices that might not be considered traditional smartphones. For example, some devices require larger screens than a traditional smartphone, or even multiple screens. Both Google and its partner community are investing in frameworks that enable specific application needs. Not all of these implementations are “standard Android” code, but through the partner community, embedded developers are getting the job done with Android.

9. NDK support: The NDK, or Native Development Kit, is a toolset to embed components that make use of native C/C++ code in Android applications. Certain types of applications have use cases and performance requirements that may exceed the capabilities of a Java/VM-based application development model. To mitigate these limitations, NDK support was added to the standard Android Software Development Kit, opening up a new way to create performance and graphics-sensitive applications. This can be a tremendous benefit to some developers but is not the panacea for all performance challenges.

10. Development and debug tools: Using open source development environments and debug tools allows an existing engineering department to rapidly switch to an Android development, especially if the previous experience base is in another embedded Linux-based development environment. Eclipse offers a dedicated plug-in for Android, the Android Development Tools (ADT) plug-in. This plug-in lets you set up new Android projects, create application-specific user experiences and user interfaces, add components, debug, and then export the .apks. From a debugging perspective, Linux developers will easily adopt to Android because GDB, the GNU debugger, is a common way to debug your Android code. JTAG-based debugging, assuming your hardware supports it, is also popular for both kernel and user space as well as boot loaders.

Android is rapidly gaining popularity as a foundation platform for both smartphones and embedded devices alike. Android’s key business and technical drivers are compelling, resulting in the Android engagement of many development teams, ranging from initial investigation to full product development. Android’s ultimate market acceptance will be based on how quickly teams can capitalize on these drivers to overcome their newness with the platform.

About the author
Christian Buerger is the Senior Director of Solutions at Wind River Systems. He is responsible for the overall product management of all Wind River Platforms for Android, Meego, GENIVI, LiMo, and associated Wind River authored test tools.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.