By: Art Lee, Viosoft
Android is finding uses in more than just the mobile market. The coming expansion further into these markets will involve opportunities and risks and require resources beyond the intentions of Google.
As of Ice Cream Sandwich (ICS), Android as delivered by Google is a software platform largely targeted at the mobile handset and tablet market. The Google Android software development environment and programming interfaces (APIs) are geared toward enabling applications written for this market. For the non-mobile market, the challenges and opportunities begin with the breakaway intent to repurpose the Android platform for any consumer product that requires a touch-oriented user interface, high-performance multimedia recording and playback, and/or application portability. We will look at some of the challenges associated with these product scenarios as well as examine a case study of an approach developed by Viosoft to assist OEMs in this task.
Portability versus Performance
Applications written for traditional embedded devices are specific to the underlying hardware architecture and OS that host the platforms. In many cases, embedded applications need to be rewritten, or ported to a specific platform. This process, referred to as “re-targeting,” can significantly add to the costs of the development and testing of embedded software.
This is where the appeal of the Android platform’s application portability comes in. The concept of “write once, run many” suggests that the same application binaries, written for and tested on one Android platform of a given architecture, shall run identically on another Android platform of a different architecture. This is not a new concept but rather one that existed when James Gosling of (now defunct) Sun Microsystems gave birth to the Java programming language more than a decade ago. The generally interpretive nature of the language means that Java applications tend to run slower than those for compiled languages (C/C++).
Android leverages Java, but not entirely. To better understand this, let’s look more carefully at the Android Software stack (Figure 1). Android applications (in blue) are written in Java, but they rely on the application framework, associated libraries and runtime consisting of over fifteen million lines of some Java and mostly C/C++ code. The partition between Java and C/C++ language in the Android design is premised on performance, with “slower” code on the Java side, and “faster” code on the C/C++ side. Under this framework, the developer is presented with the option to 1) write a pure Java application that relies exclusively on the pre-established C/C++ “sandbox” for acceleration and achieve 100% portability, or 2) write a self-containing C/C++ application wrapped in Java that is specific to a given architecture. Given the current state of near homogeneity of Android around the ARM architecture, and the success of vendors like Rovio (Angry Bird) who have taken the latter approach, the Android developer market has spoken in favor of performance.
Recent releases of Android have added a Hardware Abstraction Layer (HAL) to address the needs of high-performance native applications. The Android HAL wraps the Linux kernel drivers to create a layer of abstraction for native applications to access location (GPS), Wi-Fi, 2D/3D graphics, audio/video and other hardware specific to a mobile use profile. While the Android HAL has helped to simplify hardware integration for OEMs and device manufacturers, it’s not clear how the HAL delineates from the abstraction of the Linux kernel itself, or how it will evolve to incorporate non-mobile use cases.
Android, in Embedded and beyond Google
In advocating the adoption of “Android beyond Google,” we envisage Android being ported for and integrated into products that do not meet the mobile use profile of smartphones or tablets, or necessarily use a CPU powered by the ARM architecture. Yet, these products still require and benefit from the touch GUI, application portability and multimedia capabilities and resources that Android provides. Printers, digital camcorders, set-top boxes and smart TVs are just a few examples of how Android can potentially be used outside of mobile.
One of the primary challenges in repurposing Android is the ability for applications to (inter) operate in and out of the Android runtime sandbox. Just as with Linux applications, native (C/C++) Android code often needs to access runtime libraries for string or math operations. On standard Linux desktops, these operations are provided as part of the GNU runtime environment (i.e., glibc and libm). For performance and footprint reasons, these are supplanted by the Bionic libraries in the Android runtime environment. While both Bionic and the GNU libraries are largely semantically and syntactically equivalent, they are not runtime compatible. This means that Linux application binaries cannot run in the Android sandbox, and vice versa. A second challenge adds to this incompatibility divide: most, if not all Linux applications have a graphical interface that relies on X11, whereas Android applications rely on the Android framework and HAL to render graphics. OEMs and developers must develop approaches to reconcile between Bionic and GNU libraries, and between X11 and the Android frame-buffer, as part of the strategy to benefit from embedding Android.
Integration Framework for Android
One such approach to reconcile between Android and legacy Linux applications is Viosoft’s Integration Framework for Android. Under this framework, applications are deployed under two separate containers—one hosting Android and the other X11-based Linux applications. Applications in the Linux container can be launched and controlled by the Android desktop, while maintaining full compatibility with existing legacy libraries and drivers. Figure 2 shows a high-level architectural diagram of the framework.
To verify the viability of this approach, we’ve implemented a full media center for Android on the AMD G-Series STB reference board. Before diving into the implementation details, let’s have a look at the hardware. The G-Series family combines two 64-bit x86 processors with a Graphics Processing Unit (GPU) that consists of 80 floating point engines. The STB reference platform that we used is clocked at 1.6 GHz, equipped with full HDMI /Component out, wireless and 10/100 Ethernet, 2 Gbyte of memory and a 320 Gbyte SATA drive. Utilizing the Integration Framework for Android, we were able to deploy a full port of Android 4.0 ICS, running simultaneously with other legacy Linux applications such as XBMC (Xbox Media Center) and the Open Office Suite.
Porting Android to the G-Series-based STB was straightforward. Most of the code pulled from the Android for x86 projects (http://www.android-x86.org/) built and ran out of the box, albeit at VESA resolution. Nonetheless, this baseline enables us to leverage all of the applicable resources of Android.
Our next step was to fine tune a variety of kernel drivers to take full advantage of the hardware capabilities of the STB, including full 1080p streaming/playback and networking support for both wired and wireless interfaces. Once this work was completed, we examined the X11 requirement by XBMC and Open Office and ensured that both the X11 server and Android graphics subsystem could share audio and video resources while executing out of two separate runtime containers. The Integration Framework for Android fundamentally acts as a bridge between the Android Application Framework and native Linux applications.
As shown in Figure 3, icons are displayed in the Android Desktop for both XBMC and Open Office (circled in red). These icons are used to launch the respective applications, putting the Android desktop in the background. The launched application then has direct and full access to the underlying resources necessary to render graphics and audio/video contents. At the same time, other Android services will continue to respond to stimuli in the background, and if necessary, relinquish control of the display to solicit input from the user. For example, an incoming Skype call would interrupt an XMBC movie playback, giving the user the option to pick up the call.
The end result is a surprisingly fluid and functional media experience, hosted by the modern look and feel of the Android front-end, while at the same time being fully capable of tapping into the large body of stable and functionally rich desktop Linux applications. The same environment can readily power a variety of real-world applications such as touch-based medical equipment products and user consoles for industrial control.
An exciting aspect of this work is in the potential to repurpose Android toward different use profiles that have needs for Android and native Linux application interoperability. The ability to reuse existing code while benefiting from some of Android’s modern capabilities can result in significant costs and time savings to OEMs.
An essential challenge often presented to developers by multi-faceted environments like the Integration Framework is the lack of debug visibility for application logic that straddles runtime or language boundaries. When a function call crosses over from Java into C/C++, developers are often at a loss in their ability to follow through the flow in the process of tracking down a program defect—making a multi-lingual debug environment an indispensable tool for such needs. Arriba for Android is the only tool of its kind to fully integrate mixed language, multicore and multidomain debugging for Android and Linux applications into a single environment. Arriba’s “run mode” debug feature yields complete transparency to all layers of the Android-based platform, making it practical for the developer to visualize the flow of the system in its entirety.
With this level of visibility and control, Arriba can dramatically reduce development time and costs associated with product development. Bundled with the Integration Framework for Android, Arriba offers the OEM a complete environment to rapidly develop and deploy Android-enabled products with higher reliability and significantly lower costs.
San Jose, CA.
© 2009 RTC Group, Inc., 905 Calle Amanecer, Suite 250, San Clemente, CA 92673