Embedded Android: The droid you're looking for? - Embedded.com

Embedded Android: The droid you’re looking for?


One of the nice things about a blog is all the help you get in writing your next post. One of the dicey things about a blog, on the other hand, is all the help you get in writing your next post. But before I go any farther on either thought, I want to be sure everyone knows how grateful I am for the feedback. Constructive criticism is not just welcome, it is essential if we are going to continue the breathtaking rate of progress that we've seen in embedded systems design over the last two decades or so. Keep it coming!

(By the way, did I mention that there's no such thing as an “embedded system”? I'll revisit that topic in a future submission.)

You keep using that word…
One of several key misunderstandings about Android's value proposition was heavily reflected in the feedback from my previous article. It is true that from one perspective, Android has a pretty decent implementation for packaging applications into little bundles that can be easily installed on other devices. But viewed from a different perspective, Android doesn't really offer an application package management system at all. And this is another one of Android's design decisions that has significant implications for embedded work.

When you write an Android “application,” a large part of the task involves the design of a collection of Activity classes. It's only slightly oversimplifying to say that you derive from this Java class to implement most of the user-visible parts of your Android program, with one class for each of the “screens” that your application requires. (The devil is always in the details, of course, many of which we will discuss in due time. Most books on Android programming cover those details pretty thoroughly, however, and they are available right now.)

The Android Software Development Kit (SDK) is the toolchain you use when writing Android applications, and it comes with scripts that bundle your Activity classes, a manifest file, resource files, and other stuff into a single application package file often referred to as “an APK” (a reference to the filename extension used). Developers push their APK file to a target device with still more SDK tools; end users might do likewise, after downloading the APK from a public or private server.

About those servers. Google has one already, called Google Play. And several readers responded along the lines that, if one removes the application that interacts with Play, then you have essentially “locked down” the device from further software additions. That isn't quite how it works, actually.

You get the Google Play application only after you have passed Android's Compatibility Test Suite, which no embedded system is likely to achieve because many of the requirements don't make sense for non-phone, non-tablet hardware. And honestly, we're a lazy bunch who probably won't even try. So if users want to install Angry Birds on your milking machine, they'll have to “side load” its APK file via the SDK tools, after stealing said file from another device: they won't get it from Google Play. Problem solved, right?

Kind of. If you think users will go to all that effort, you can provide positive assurance they will fail by simply not running the Android Debug Bridge (ADB) server on the target device. Problem more-solved…ish.

If you squelch ADB, how will you get data on and off the device? One proven robust way is by using an SSH server, which … Android generally lacks. Yet another reason for putting a true operating system underneath the Android framework. We're getting to this, but it'll be a couple more articles yet.

Another way that several readers suggested for preventing unauthorized software installation is to not share the cryptographic keys used to sign your applications, since “Android doesn't run unsigned applications”. But remember how you created your keys? Yeah, your audience will just do that too. Those keys actually serve just to authenticate the APK's author, they aren't a tamper-resistance mechanism.

All the above isn't to say that you can't make an Android device that's locked-down. You can, but you might not want to. And if you really do, then you'll have to do it carefully so that you don't break things you will need yourself e.g. when it's time to do an upgrade on fielded devices. Either way, you're back to understanding how Linux works underneath Android: use the kernel's permissions model to prevent non-root users from running the APK installer program resident on the device, and then make sure your users can't get root.

Finally, that whole “signed application” thing is hardly unique to Android: Linux can do it too.… but it doesn't mean what you think it does
All of the above described considerations regarding the installation of Android application packages, a.k.a. APK files. Those files contain code that runs on top of the Android framework, which I said in the last article that embedded developers should use sparingly. What do we do about the rest?

Turns out, in an ordinary Android device the considerations for updating files containing the Android framework, native runtime libraries, underlying infrastructure, and standalone processes are vanishingly small. As in: there are none whatsoever. Android puts a lot of thought into managing APK files, but pays no attention to managing the scaffolding that supports them.

Cell phone developers deal with this by, in many cases, just downloading an entirely new filesystem image to the phone. This approach has the upside of eating lots and lots of network bandwidth and battery power, while at the same time minimizing all that unnecessary developer friendliness and system integrity. We can do better in the general embedded space—and professional ethics and common sense dictate that we must: we might not have enough storage for two complete filesystems, after all, and we can't ever expose the device to the possibility of failure just because someone kicks out the power cord during an update. What's more, with a typical lifespan of almost ten years, it's pretty likely that the universe will present a challenging upgrade scenario for every embedded system that a mere wipe-and-reinstall just won't address.

One way I have dealt with this problem is by incorporating an existing, Linux-based software package management framework to the situation. My current favorite is dpkg, the same tool that Debian uses. There are other options, but that one is particularly good at dealing with dependencies between package files—which is of keen interest here, since Android-based embedded systems will by definition need more packages than most to deal with the split-personality implementation strategy we started discussing last time.

… no, really, it doesn't. Honest.
I'm still waiting to hear if my credit score qualifies me for a higher word count from UBM, so I'll wind down (for now) with this final thought: the term RTOS means real-time operating system .

I mention this because I was pretty surprised by the number of readers who tossed around expressions like, “Android as my RTOS.” We can now see how that notion is wrong on at least two levels: Android doesn't do real time, and Android isn't an operating system.

Terminology matters, especially when what you are talking about is as complicated as a modern-day computing platform running Android. If we don't all speak the same language, and if that language itself isn't concise, then we're headed for a destination of disaster before we've even started the journey.

I see the term RTOS used in a lot of places it doesn't belong. One of the first things that impressed me about Jean Labrosse, fellow Design West instructor and author of the filled-with-awesomeness uC/OS kernel, is that he corrected me every time I called it an “RTOS”. “It isn't an operating system,” I recall him saying, “it's a scheduler.” Dan Saks abuses me in a similar fashion when I make a mistake describing C++ in his presence. Both authors would even toss in a few four-letter “french words” when I was slow on the uptake, though I'm pretty sure Dan's were just made up on the spot.

The reason I'm grateful for their corrections is that in doing so, they helped me switch from the wrong way of thinking about something towards a better, clearer, and more accurate way— and also one that was informed by their decades of experience figuring out what the right way to think about their subject matter actually is.

Let's all be careful to do the same thing for Android.

Bill Gatliff is a freelance embedded systems consultant, specializing in adapting the Linux kernel and device drivers, and Android, for custom hardware. He also teaches, is a contributing editor for embedded.com, and is both a distinguished faculty and member of the advisory panel for the Embedded Systems Conference. That's the former name for Design West, which tells you how long he's been at it. He can be reached by email to .

2 thoughts on “Embedded Android: The droid you’re looking for?

  1. Interesting article, but I am also curious about the decision process when choosing Android for an embedded application. Like one of the posters to your previous blog on the topic, it seems to me that unless you want to let third parties run applications o

    Log in to Reply
  2. Always great to hear from you, Niall! Especially when you've predicted (provided?) the topic for my next posting. Stay tuned! 🙂

    Log in to Reply

Leave a Reply

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