Welcome Guest! To enable all features please Login.

Notification

Icon
Error

Embedded Android
Eddy_D
#1 Posted : Friday, September 21, 2012 10:59:50 AM(UTC)
Rank: Newbie

Joined: 9/21/2012(UTC)
Posts: 5

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
Eddy_D
#2 Posted : Friday, September 21, 2012 11:09:03 AM(UTC)
Rank: Newbie

Joined: 9/21/2012(UTC)
Posts: 5

And some of my links to-date;

Porting Android - Adding peripherals to Android
(has an example of adding a Wifi modem to Android!)
http://processors.wiki.ti.com/index.php/TI-Android-ICS-PortingGuide

A Guide to Android Memory Usage & Memory Optimization
http://processors.wiki.ti.com/index.php/TI-Android-ICS-MemoryOptimization

Android Boot time optimization
http://processors.wiki.ti.com/index.php/TI-Android-ICS-BootTimeOptimization

Android Developers
https://developer.android.com/index.html

Android Open Source Project (ASOP)
http://source.android.com/

Android on TI Processors (rowboat)
http://code.google.com/p/rowboat/

[Book] Embedded Android, Karim Yaghmour (not out as of Sept 2012) O'Reilly Media
ISBN: 978-1-4493-0829-2
ISBN 10: 1-4493-0829-5
http://shop.oreilly.com/product/0636920021094.do?sortby=publicationDate




Johan Dams
#3 Posted : Saturday, September 22, 2012 7:34:00 PM(UTC)
Rank: Advanced Member

Joined: 9/16/2012(UTC)
Posts: 35

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.
Eddy_D
#4 Posted : Monday, September 24, 2012 10:25:40 AM(UTC)
Rank: Newbie

Joined: 9/21/2012(UTC)
Posts: 5

@ Johan Dams

Quote:
Quick question: why use android for an embedded system?


A good question. So basically, Android is a phone OS. It was designed to work in a power sensitive operation, i.e. with only a limited battery capacity. It was designed to provide audio and data capabilities over a radio modem (GSM/GPRS/EDGE, CDMA, LTE etc). It also was designed to provide a platform for smart phones, by providing a rich GUI API.

In my case this is a very good fit for the products I work on. I need a platform that is power sensitive, can handle a radio modem and has a good solid underlying OS (Linux in Android's case). I may or may not need a GUI. For the first product I am looking at starting, in fact I do not need the OS (the device is "headless"). But if I use Android I have that option to go ahead and add a display later on, providing a product that can even be programmed with custom apps that are tailored for this devices usage.

Note: Android will run without a display and GUI.

One Android component I am really interested in is how it performs power management. The "Wakelocks" system has been a bone of contention in the Linux community for a while (that is why it has been an Android only patch to the Linux OS at least prior to Linux 3.5). The dispute is due to the fact that wakelocks works in opposition to the traditional power management in Linux. Linux power management was intended for laptop usage where the user decided when to power down. It also monitors the battery and will alert for low battery and may resort to self power off if necessary. Android wakelocks operate by allowing other processes to give the power management a reason to stay awake. If there is no reason to stay on, then it powers off (hibernates).

In short, Traditional Linux PM wants to stay on and Android PM wants to stay off.

If you have a product that you ware developing that is very battery sensitive and it does not need to run all the time (as I have) then the Android PM is a better fit than bare bones Linux.

Plus I get all the Android services (for embedded target control and radio operation) that I can re-use and I do not have to write. And if I want to add a display later on, then the effort is mostly a mechanical/electrical level one, if it has not already been designed in.

Hope that answers your question.

- Eddy_D
Johan Dams
#5 Posted : Monday, September 24, 2012 10:43:41 AM(UTC)
Rank: Advanced Member

Joined: 9/16/2012(UTC)
Posts: 35

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.

Eddy_D
#6 Posted : Monday, September 24, 2012 11:10:18 AM(UTC)
Rank: Newbie

Joined: 9/21/2012(UTC)
Posts: 5

@ Johan Dams,

Thanks.

Yes I agree that the Android Platform is very much so a targeted platform. If someone is trying to shoehorn Android into some product that does not need all (or any) of the features that Android offers than it would probably be less effort to roll your own platform on top of vanilla Linux.


Additional:

On my prev posting, I noticed one typo, in;

Quote:
If you have a product that you ware developing that is very battery sensitive and it does need to run all the time (as I have) then the Android PM is a better fit than bare bones Linux.


That should read;

Quote:
... is very battery sensitive and it does not need to run all the time ...


- Eddy_D
Bill Gatliff
#7 Posted : Monday, October 01, 2012 10:07:37 AM(UTC)
Rank: Newbie

Joined: 10/1/2012(UTC)
Posts: 5

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.
Johan Dams
#8 Posted : Wednesday, October 03, 2012 5:29:29 AM(UTC)
Rank: Advanced Member

Joined: 9/16/2012(UTC)
Posts: 35

@bgat,

I'm sorry, but I disagree with you. Linux (the kernel) IS the operating system. All the other stuff is just user level stuff which might or might not be needed. For example, I've built several embedded system using the Linux kernel with all the functionality needed built into the kernel and one or two user level tasks which were started by directly replacing 'init'.

While Android can be considered an application framework, it's not really the best approach. It can not be denied that Android has a phone background, and as such, a lot of the classes are targeting phone applications. At this point, Google is hard at work to get Android usable on different types of devices such as tablets, probably by merging experiences with their Chrome OS in it some how.

Comparing Qt with Android as framework is, in my opinion, wrong. For starters, Qt is cross platform and does not rely on anything in the Linux kernel. I've personally ported Qt to, among others, L4 based systems without issues.

"Android brings a LOT more to the situation than Qt does"

It also brings a lot more overhead than typically needed for embedded systems, and is harder to scale down. Try running Android with a minimal C library... Personally, I think Qt offers a lot more in the embedded sphere than Android does.


Johan.
Bill Gatliff
#9 Posted : Wednesday, October 03, 2012 7:43:20 AM(UTC)
Rank: Newbie

Joined: 10/1/2012(UTC)
Posts: 5

Johan Dams wrote:
@bgat,
I'm sorry, but I disagree with you. Linux (the kernel) IS the operating system. All the other stuff is just user level stuff which might or might not be needed. For example, I've built several embedded system using the Linux kernel with all the functionality needed built into the kernel and one or two user level tasks which were started by directly replacing 'init'.


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.

Johan Dams wrote:

While Android can be considered an application framework, it's not really the best approach. It can not be denied that Android has a phone background, and as such, a lot of the classes are targeting phone applications. At this point, Google is hard at work to get Android usable on different types of devices such as tablets, probably by merging experiences with their Chrome OS in it some how.


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.

Johan Dams wrote:

Comparing Qt with Android as framework is, in my opinion, wrong. For starters, Qt is cross platform and does not rely on anything in the Linux kernel. I've personally ported Qt to, among others, L4 based systems without issues.


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.

Johan Dams wrote:

"Android brings a LOT more to the situation than Qt does"

It also brings a lot more overhead than typically needed for embedded systems, and is harder to scale down. Try running Android with a minimal C library... Personally, I think Qt offers a lot more in the embedded sphere than Android does.


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.
Johan Dams
#10 Posted : Wednesday, October 03, 2012 10:11:45 AM(UTC)
Rank: Advanced Member

Joined: 9/16/2012(UTC)
Posts: 35

Hi,

I think we disagree on the term 'embedded system'. The fact that you bring up package management shows that clearly. From my point of view, I don't want the 'end user', whoever that might be, to change anything on the system at all. That's the whole 'computer not identified as a computer' thing embedded is all about. If for example, I need a control user interfaced to a Smart Meter, a control GUI to a sensor array in the workplace, a touch interface to a process control system, etc. I want to be able to lock the system down, no upgrades, no software to install, etc. The security aspect comes from being able to lock the system down to the bare minimum and be able to use industry standard security components.

I've deployed several of these systems, with Qt or other libraries and a bare minimum of a Linux kernel on top. Often, a Linux kernel is overkill even, and ran with either a small real-time kernel or no OS at all. I usually don't have memory or computing power available to run a Java VM.

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

As it should be. The application API and GUI toolkit should not have to worry about security models. That's how things go horribly wrong. If security matters, you want to run something like an L4 kernel which has security by design.

"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."

Again, I believe this belongs at the OS level, not the application framework level.

" 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."

Sure, and that's how it should be :-) Joking aside, the fact that in embedded we use so many different transport layers, protocols, etc. makes things like RPC etc. not very useful. Take for example substation automation. This relies on communication according to IEC61850 and its security components. Together with the timing requirements this means that an e.g., Android based solution would be out of the question since it's not real time. Same with sensor network nodes, many which run 6LowPan on top of 802.15.4, etc.

Of course, I agree with you that there are places where Android makes sense on an embedded device, but in the whole universe of embedded systems, these uses are very very small... What I definitely don't want to get to is that everyone is starting to use Android for everything that has a GUI in the embedded world, throwing things like performance and power requirements out of the window.

In any case, thank you for an interesting discussion :-)


Johan.
Bill Gatliff
#11 Posted : Wednesday, October 03, 2012 2:50:01 PM(UTC)
Rank: Newbie

Joined: 10/1/2012(UTC)
Posts: 5

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. :-)
Johan Dams
#12 Posted : Wednesday, October 03, 2012 2:57:58 PM(UTC)
Rank: Advanced Member

Joined: 9/16/2012(UTC)
Posts: 35

"But I sense you want to close this thread"

Not at all...

"Your statements regarding security are factually incorrect"

Care to elaborate? Security should be part of the system design. The ability of e.g., an L4 kernel to separate individual tasks from each other to the extend that if one gets compromised, the others are not is a design feature of the operating system, and not let into the hands of the application programmer. Same with cryptographic capabilities: you don't roll your own. You'd be surprised how often I see people roll their 'own crypto' in their application.


Johan.

Bill Gatliff
#13 Posted : Wednesday, October 03, 2012 7:13:23 PM(UTC)
Rank: Newbie

Joined: 10/1/2012(UTC)
Posts: 5

Johan Dams wrote:

Care to elaborate? Security should be part of the system design. The ability of e.g., an L4 kernel to separate individual tasks from each other to the extend that if one gets compromised, the others are not is a design feature of the operating system, and not let into the hands of the application programmer. Same with cryptographic capabilities: you don't roll your own. You'd be surprised how often I see people roll their 'own crypto' in their application.


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 Dams
#14 Posted : Thursday, October 04, 2012 1:21:16 AM(UTC)
Rank: Advanced Member

Joined: 9/16/2012(UTC)
Posts: 35

Hi.

"without first getting permission from the user"

What you describe Android being capable from a security point of view is exactly why I would not use it: the end user can decide what abilities the application can use (e.g., use internet, use certain resources). My point is that as the embedded system implementer, I want to decide what the system can and cannot do with regard to access control. Not only that, I want to do it in such a way that no other application, even if hostile, can circumvent those checks and balances.

This is what an L4 kernel can provide versus a Linux kernel: I decide what task can talk to what other task. For example, I have a secure framebuffer running multiple applications, yet they can not snoop each others key presses. When a screenshot tool could be installed by compromising a running application, it would only be able to capture the output of this one application, not any of the other ones. Same with network traffic, mouse events, etc. This is fundamentally different from a Linux kernel.

"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."

Sure it does, for the reasons I mentioned above. You can give much more fine grained security access to applications running on L4 than you can on Android (or just Linux). In the end, Android is just Linux, but with a set of policies for applications which increase security from a user perspective, but not from a systems perspective. It is intended to make the user think before granting an application access to certain services - but does not prevent malicious applications from installing due to the end user clicking 'ok' to everything. Remember: never trust the user (especially in embedded!).

Also, and I'm sure you know this, Qt is much more than a GUI framework:
http://doc.qt.digia.com/4.8-snapshot/classes.html


Johan.


Bill Gatliff
#15 Posted : Thursday, October 04, 2012 5:01:58 PM(UTC)
Rank: Newbie

Joined: 10/1/2012(UTC)
Posts: 5

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!
Johan Dams
#16 Posted : Thursday, October 04, 2012 8:46:51 PM(UTC)
Rank: Advanced Member

Joined: 9/16/2012(UTC)
Posts: 35

Hi bgat,

Yeah, I think that's mostly it. My definition of embedded (at this point in time) is different. By the way, it's not that I'm not familiar with Android or know its use cases. My team was the first one outside of Google to have ICS running with full 3D acceleration on an ARM device: http://www.powerdevelope...s/viewtopic.php?p=15541


Johan.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Powered by YAF 1.9.5.5 | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 2.252 seconds.