Just thought I would launch this topic to gather user experiences on this. I am just getting into this subject myself and it seems to be very useful to be able to take Android+Linux as a starting point for a new embedded product. There does not seem to be a lot of info on this subject at this time (get the book finished Karim! :) ), so maybe drop some links that you have found useful.

Also, the latest changes to the Linux v3 branch have incorporated some of the Android patches as native components in Linux now (wakelock API and Binder) so it may even be possible to leverage off of these, without using the Android filesystem, to accelerate an embedded product.

I will drop some in that I have found, in following replies.

Your thoughts?

- Eddy_D

Hi.

Quick question: why use android for an embedded system? What specific embedded application do you have in mind that would require Android, and can't be done easily with just Linux?

For example, Android is primarily a phone and tablet operating system with a lot of focus on the user interface. If you need a fluid user interface, it might look like a good choice. However an embedded OS usually performs only one function visible to the user: one application, not a bunch of them. Why not just write that in something like Qt, deploy on Linux and call it a day? Android has so many extra's that would need to be disabled or stripped out that form security issues (malicious attacks targeting Android - might even have to provide regular updates...), performance issues, or can just go plain wrong.

If you have an embedded application without a GUI, Android would even be completely superfluous...



Johan.

Hi,

Ok, you are one of the first people I met that seem to have a valid use case. I've just seen too many people going for 'embedded Android' that would be better off using a plain Linux kernel with a basic Qt or even plain C application on top.

Thanks for detailing that; I'm sure it will come in handy for others!


Johan.

Hi Guys!


There are couple of fundamental misconceptions present in this thread that are clouding the discussion. Since I'm a professional embedded Linux developer who also uses Android in his work products, and I'm an instructor and advisor to the Embedded Systems Conference and elsewhere, I thought I would jump in and help a little. :-)

First, the term "Linux" refers only to the kernel itself---it does not imply any operating system. And without some form of operating environment to host user applications, the kernel doesn't really accomplish much except in some special use cases. When coupled with the right collection of user applications a.k.a. an "operating system" and your own programs, however, you can obviously accomplish a lot!

Second, Android is almost exclusively an application framework, and not an operating system per se. But it travels along with additional code that brings the total up to a very minimal, purpose-built operating system. You always do best to keep this concept in mind, because it is highly likely that you will have to do major work on the operating system provided by AOSP along with Android, when you try to use it in something that isn't a tablet or phone. I tend to replace its operating system entirely, in fact.

Conceptually speaking, Android is a lot like Qt in terms of the contribution it provides to the overall system's behavior: a great environment for implementing programs, but not a finished program in itself. But when a developer adopts Qt in an embedded platform that also utilizes a Linux kernel, he's aware that he will need to bring other content as well.

That's also true with Android, though Android brings a LOT more to the situation than Qt does. Which is one reason why Android is so appealing to embedded Linux users: it provides a pretty cohesive framework that covers many important use cases. You can cobble something similar together with other components, but that is likely to be more work with lower reward.

Third, Android is NOT a "phone operating system". It's not even an operating system! It's perhaps best described as a resource-conscious framework for implementing applications that can be useful for phones, tablets, and other resource-constrained devices. There isn't much in Android itself that makes it specific to a phone, other than the typical Activity classes that are often included with it. Those classes can be easily removed for devices that aren't phones.

The reason that Android's "wake locks" have been controversial with the Linux kernel community is that they are a lousy API. The concept is intrinsically flawed, and also doesn't generalize beyond the current Android community's hyper-focus on cell phone-type devices. The Linux kernel's runtime-pm API is objectively better, and can replace and improve upon wake locks in every use case that I have encountered to date.

The part that is "missing", if you want to call it that, is what the kernel guys are calling "opportunistic suspend". That's almost purely a user-space consideration, and Android even in its present state neglects the subject badly. That's one reason I don't consider it an "operating system".


HTH.

You are, of course, free to disagree with me. :-)

But you are actually supporting my point, and not yours: the Linux kernel doesn't accomplish much without support of user programs. You do not state that you have shipped Linux systems that have no user programs whatsoever.

For some implementations, it's true that the formalism of an "operating system" isn't necessary. Not everyone needs run-levels, package management, and so on. And when you choose to go that route, then you have simply a Linux kernel plus a few purpose-built user programs.

But Linux is still only the kernel, and those programs are taking the place of what would normally be something more resembling an operating system. This isn't a bad solution.

My quibbling here with terminology is important, because getting the functionality ascribed to the correct parts of the system greatly informs you as to where changes need to be made when necessary. You already realize this, clearly, because you understood that since you didn't need the functionality of /sbin/init, you could replace it. You didn't go hacking around in the Linux kernel looking for the CONFIG_RUNLEVEL option to turn off run-levels, for example.



The speculation in your latter sentence is telling, at least to me.

If you go look at the actual Android framework source code, you don't see very much there that's of utility only to cell phones. There are a few classes, sure, but the overwhelming majority are to deal with internal event management, GUI widgets, networking, and multimedia support. These functionalities are useful to many kinds of devices in addition to cell phones.

So, based on the observation that the overwhelming majority of classes that are implemented in the Android framework are not uniquely useful for cell phone systems, one must conclude that Android is not merely a cell phone framework.

Keep in mind that Android AOSP also travels along with a large stack of example programs, which includes a phone dialer. Those aren't part of the framework itself and thus don't bias Android's framework specialization in one way or another: they just demonstrate that the framework is useful in certain use cases.

As for Android being the "best approach" or not, that's too subjective a question to answer.



You do realize that Android is more cross-platform capable than Qt, right?

True, you can't (reasonably) use Android above anything other than an enhanced Linux kernel. But Android activity classes that have no native code (which correctly describes about 2/3 of the applications in the Google Play application store to date) can run without modification on ARM, MIPS, and x86 platforms. They don't even need to be recompiled.

With Qt, everything is native code. So you must at least recompile that code to run it on a foreign instruction set architecture. This isn't a negative of Qt, they just were solving a different problem than Android.



There really isn't such a thing as a "typical" embedded system. That's the joy of this business! :-)

Part of Android's "overhead" is in the fact that most of what the user sees is running in a java-like virtual machine. That does impose a performance hit (I've heard numbers as high as 30% compared to native code, but it's probably dependent on the workload used for the test). But that virtual environment allows Android to do interesting things regarding portability, power management, and security.

On balance, the tradeoff seems to work. Note that comparable iPhone devices, which run everything in native code, do not gain significantly longer battery life than Android devices. And although the user experience is quite different, ICS- and JB-based Android devices are comparable in the quality of the experience to iPhone devices.

So even though Android uses a VM instead of native code, which is the origin of the "overhead" that you find unpleasant, it doesn't seem to have made much difference to the end-user-observable characteristics that matter. So is that "overhead" really relevant? To the top-line requirements, it would seem not.

Android already has a minimal C runtime library, called bionic, which is far smaller than the glibc libraries typically paired with Qt (I haven't looked at bionic compared to uClibc, another library often paired with Qt). Some other ways that Qt comes up short compared to Android:

* Qt lacks a security model. It relies exclusively upon the security mechanisms of the underlying OS and kernel.

* Qt has no framework for application package management. How the application file enters and exits the system depends entirely upon the underlying OS mechanisms.

* Qt has no facilities for power control or awareness. Qt applications cannot natively request notification of impending platform suspend/resume events, nor can they deny requests for same.

* Qt doesn't have a comprehensive mechanism for re-use of classes in a Service-Oriented-Architecture kind-of way. To invoke a Qt-based object, you have to link the class code to your application at build time.

None of the above are true shortcomings of Qt: they just aren't problems that Qt was trying to solve. So if you reject Android in favor of Qt, you must also provide answers (and implementations) for the functions that Android brings but Qt doesn't.

Android isn't the end-all, be-all solution for embedded Linux. But it isn't easily dismissed, either.


b.g.

Yes, we clearly differ on the types of devices we are deploying. Sadly, that's the only thing we seem to agree on.

Your statements regarding security are factually incorrect, by the way. But I sense you want to close this thread. :-)

I completely agree that security is a system-wide consideration---encompassing assets that are both inside and outside of the target device. And yes, the rate of roll-your-own "security" in our business is tragic.

The Linux kernel also has the ability to separate processes from each other. This isn't a design feature of the operating system (which in Linux is always defined as being everything but the kernel itself), but rather a capability provided by the kernel that the operating system must conform to. L4 is similar in this regard, though being a microkernel it draws the security "lines" in different places than Linux does. (At the end of the day, however, it all comes back to a page-fault interrupt from the MMU).

The Linux kernel implements the "user, group, other" permissions model established by Unix a long time ago. It's a great starting point for application framework security, but you have to mindfully apply it. For example, if you run every process as the root user, then you've basically defeated all the security features other than the memory barrier between kernel and all user processes.

On anything more complicated than a single-process system, you will have the need for processes to communicate between each other. That's where the differences between Qt and Android become apparent. And simply switching over to L4 doesn't address those differences at all.

Android is explicitly designed to allow the end user much more fine-grained control than simple u/g/o access controls. It wants to allow the user to be aware of applications that are using the network connection, for example, or gaining access to their contacts list. Or more to the point, Android seeks to avoid a situation where an application is stealing information from the user without the user's knowledge. This is key, because a big reason for Android's existence is to facilitate developers and users being able to safely modify the system after deployment. This responsibility includes protecting the system from destabilizing changes, but also preventing trojan programs from stealing the user's private data without the user being aware.

(A vendor can trivially disable Android's end-user configurability features if they want to. Whether they should or not is another discussion).

Part of Android's security implementation is a set of checks inside the framework libraries that are nearly impossible for user applications to circumvent without first getting permission from the user---and the framework itself seeks that permission, not the application that wants it. These checks occur at a level above where u/g/o could meaningfully contribute to the situation, other than to prevent the user from physically modifying the library files where the checks take place. The Android framework must be asked by an application for permission to use a network connection, for example, and the framework will refuse that request until the user approves it.

The above is a restriction that is beyond what a typical, out-of-the-box Linux kernel or L4 can provide. But the security mechanisms those two kernels DO provide out-of-the-box is a foundation for building the above. Android does, Qt doesn't.

Again, this isn't a slight to Qt at all because Qt is a GUI framework, and not an application framework. Qt seeks to solve a much, much smaller problem than Android does.

I have used Qt before, and found it to be pretty elegant as a GUI framework. But sometimes, that just isn't enough. And nowadays, that "sometimes" is happening more often than it used to.

Johan:


I think I finally see what's going on here, why we seem to keep talking past each other...

The devices you produce are fixed-function, and that functionality is delivered by you and not largely subject to change by anyone downstream of you. That fact is what grants you the ability to make the technical judgements that you have described in this thread.

On the other hand, the devices I create are usually highly customized by my clients before final installation. The devices aren't necessarily programmable by the end user, but I'm not the decider of what the delivered product looks like. In fact, I rarely ever even SEE the finished product, but I still have to deliver something that can be safely and robustly modified by the next developer in the pipeline.

Were I in your shoes (and if I had never seen this other side of the business :-)), then I would probably make similar decisions as you. They're good decisions, but they are possible to great extent because you are the sole arbiter of what the finished implementation is.

Were you in my shoes, however, I'm thinking you might better appreciate the value of Android. Or, perhaps, risk reinventing it.

It's cool that we're both doing embedded systems, and yet what we do is so different!