Linux rt- patch for android anyone?

Question

Is it possible to apply the rt-patch for linux kernel to android kernel ?

WHY? This is purely a research project. Can I have a dashboard on my car that runs Android yet is also controlling safety critical tasks in the car? Android itself is uselss for SC tasks but if I have put it over a hypervisor I am sure it can be done.

Answer 1

Like others have said, there is no real reason you couldn't apply both the RT and Android patches to a Linux kernel. But whether or not that is useful to you depends on what you are trying to do.

You will not get real-time Android applications with full API support. You should, however, be able to write real-time native applications in C. See the documentation for writing native activities. You'll just have to be very careful that you don't make any API calls into Java (due to potential for garbage collection, for starters)--and probably even many Linux system calls--from threads that you intend to behave in a real-time manner. So like any true real-time system, most of the work will be up to you.

Whenever kernel.org is back online, have a look at the RT wiki.

Answer 2

I have finally taken the mantle myself and coming up with a hyper-visor based approach so that Android can support hard real time processing.

Answer 3

I dont know about the details down to the kernel level but I assume you want to create a RT Android version.

Regarding that desire I would think that just applying the RT patch will be no means get you to a real time version of Android.

Especially with a virtual machine there is a lot of complexity involved with garbage collection pauses and such that prevent true real time behaviour.

E.g. look at the real time specification for the JVM. It took 8 years to get from initial submit to an actual working implementation.

http://www.jcp.org/en/jsr/detail?id=1

So overall.. it might and probably is possible to apply the RT patch, but the outcome will not do what you are probably after.

Answer 4

Very Important Link

Ongoing research on real-time android.

http://code.google.com/edu/submissions/ncsu-rts/

---

below blog discussion is worth reading,

http://groups.google.com/group/android-kernel/browse_thread/thread/fbf7f94d80f5eb2c/4e9f6f4d22a40b36?pli=1

It is no different from real time support in any Linux system, have you looked into the real time patchset for the Linux kernel? It should apply to the Android kernels with no problems.

it says, you can successfully rt-patch of linux to android.

BTW, Definition of real time architecture is,

A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.

Above ref from :http://www.ibm.com/developerworks/linux/library/l-real-time-linux/

So, Basically why in this universe you want to apply rt-patch to android kernel?

---

**JUST FOUND**

This article is worth exploring, You might find a link to follow for your research project.

http://users.ece.gatech.edu/~vkm/Android_Real_Time.pdf

Answer 5

If your goal truly is only to boot an Android kernel with the RT patch, then it is likely trivial if the architecture of the device running the kernel is supported by the RT patch. For example, x86 is well supported, and I believe ARM is as well.

I use "trivial" in a loose sense; the RT patch may not apply cleanly to an arbitrary kernel with custom (i.e. non-mainline) changes such as the Android kernel, but architectural and lower-level integration into things such as concurrency control can be some of the biggest challenges. The RT patch is generally designed to work with arbitrary drivers, for example--but other problems may exist: the RT patch touches MANY subsystems. On the plus side, a significant amount of the RT patch has actually made it into the upstream kernel, which simplifies the task depending on the forked version the Android kernel is based on.

Assuming that the architecture is supported by the RT patch, it is successfully applied to an Android kernel with conflicts resolved, and boots, your job is still far from complete. Any user space applications such as the UIs that run on top of the JVM must be made aware of timing constraints, etc...

For more information on building application with the RT patch, you can consult this wiki for the RT patch: http://rt.wiki.kernel.org/ (note that at the time of writing this kernel.org is down due to the recent security breach).

Answer 6

You can apply the two patches (RT kernel and Android kernel modifications) but apart from the obvious hard work of integrating the two I suspect you will have at least one conceptual problem - Android uses a system of locks, called "wake locks", to control when and to what level the system it is running on can go to power saving mode.

The problem is that deep power saving modes is not at all compatible with hard real time that requires predictability.

Of course you can modify the Android patches and provide an "dummy" implementation of the wake lock mechanism, especially since in a car you have a much bigger battery then your average tablet or smart phone, but it is something you will need to address.

Other then that, it's all code integration and testing work I believe.

Good luck

Answer 7

If I understand the question. you have a very critical system (like a car's braking aids system etc..), and you want to control/track it via a nifty gui created in android (dashboard)?

I think you should always split the critical system, from the gui. That also on a hardware level. So you could do whatever you wan't in you GUI, but the critical system will never be influenced (by heavy cpu load for a fancy graph, etc.. ) 'cause it's running on it's own hardware.

So you'll have one system: the cars internal computer (as they exist today ), and a completely other system: the Android based nifty GUI.

The communication between those 2 things should be as simple as possible, there are already a lot of standards to communicate with the internal computer, they are mostly brand-dependent (example: VAG com).