Real-time Android: real possibility, really really hard to do - or just plain impossible?
For several months I have been having conversations with embedded systems engineers about Google’s Android and the why’s, what’s, and how’s of using this Linux-based mobile software platform in embedded systems, particularly in applications requiring real-time and deterministic operation. I have been curious to find out: why all the interest in Android?
Part of this interest has to do with the historical relationship of mobile devices - and the Android platform - to embedded and real-time OSes, which strikes me as being analogous to the relationship between trucks and suburban utility vehicles (SUVs).
When SUVs were first conceived, they were designed by truck designers, built by truck workers on truck production lines, and used truck wheels, frames, and components. However, SUVs soon began to diverge, and developed their own unique characteristics. But there was enough shared history and similarity in design that SUVs became a target market for anyone who was in the truck business. Now, in turnabout fashion, truck designers are eyeing some of the SUV enhancements and design approaches and incorporating them back into trucks.
That pattern is mirrored in the recent history of mobile/embedded devices, particularly as it relates to Android smartphones and tablet devices. As distinct a platform as mobile devices have become, their beginnings were in the embedded space. The developers I met with who crowded into the Android classes at the Spring ESC DESIGN West thought they had a lot of embedded design expertise that would be useful in the small footprint, resource constrained mobile device segment as well.
More tantalizing is the reverse possibility - adapting Android for embedded applications. For another analogy it is useful to look back at the evolution of the X86-based PC platform. Before the introduction of the Microsoft OS-based IBM PC and its AT bus architecture, there were dozens of desktop computer vendors using technology derived from the embedded market that had existed for a decade before the PC's introduction. After the standardization on the AT/Windows platform, dozens of companies and engineers then reversed the flow by developing variations and extensions of the platform for use in embedded applications.
We are at that last stage with Android, with growing interest in creating a variation of that platform supporting real-time deterministic app development. But is this a realistic expectation? And if so, what will it take to get there? Or will it become yet another tantalizing but impossible dream?
The consensus of the developers with whom I've discussed this seems to be that without modification Android would not be a useful vehicle for supporting real-time deterministic embedded apps, no matter how broadly that term is defined. It's not only questionable whether Android can achieve even soft real-time deterministic responses to interrupts, but even if it can, how reliable it will be in doing so, especially when a design is heavily loaded with apps that demand – not merely politely request – access to the underlying hardware/software resources.
The challenges facing Android in embedded apps
The problems with Android seem to fall into two basic categories: the responses of the Linux kernel (Version 2.6) at the core of the platform, and the responses of the Android-optimized Dalvik Java virtual machine. There are also some concerns about the Java code wrapper that surrounds the Linux kernel and is the API through which most development is done.
Engineers I have talked to have assured me that taken individually, each is manageable. But together, they play havoc with the Android platform’s ability to achieve the real-time responsiveness and interrupt response times needed for hard-core industrial, automotive, and even some consumer apps.
That has not prevented some of you from trying, despite the fact that any Android application has multiple levels at which interrupt responses can be compromised. First is the latency introduced by the Linux kernel when it handles an interrupt. Then there is the latency added by the Davlik VM, specifically the time interval between when it is received at the kernel event management level and when it is then passed up to the application running on top of the VM. Particularly troubling to developers is the variability in the latency responses. In most cases, the degree of variation goes beyond the upper limit on how much can be tolerated in real-time applications.
The preliminary numbers about Android’s real-time performance vary considerably, depending on the source. In general, though, when the application is relatively simple and the system is lightly loaded with no more than 1 to 5 interrupts per second, and the frequency of interrupts is in the 10 - 30 Hertz range, the number of deadline misses are troubling, but manageable. But when the system is operating under heavy loads with a dozen or so interrupts per second, and the frequency of interrupts is in the 1 to 5 kilohertz range, the Android OS performance degrades drastically.