OpenHab server on Android?

In the search for a “perfect” hardware to use for an OpenHab server installation for a small home, I came to think about an ordinary Android tablet (like Nexus 10) + OTG-cable with both power and USB-port + Z-wave USB-stick:

  • I think it meets requirements on CPU, RAM and storage capacity
  • It has battery backup “built in” from the beginning which is nice
  • It looks way nicer/slimmer than a Rasberry Pi 3 or similar even if they are in a case
  • It has a display “built in” and could run the OpenHab android client too in parallell for control, creating an “all-in-one” solution

However, from my somewhat limited understanding the Android Java environment will not meet the OpenHab server requirements.

Have anyone tried to do this, or is it even possible (to put OpenHab server on Android)?


I don’t think this is possible. While Android is written in a Java like language, the actual Java Virtual Machine (JVM) which runs the code, and the format of the binaries that gets created when compiling the source to byte code is completely different.

On top of that the way that Android works as an OS is quite different from a typical Linux desktop/server environment. For example, I don’t know how or if an Android tablet will support a USB zwave dongle. I don’t know if an Android tablet can do power and USB data at the same time (i.e. you can’t charge and use a USB device at the same time).

I suspect that OH could be ported to Android but it would be a massive massive effort.

Has anybody actually tried this? I’d be interested in the concrete problems – I don’t really see why jvm byte code vs. dex should matter at all?

Without going into a bunch of technical detail, Dalvik or what ever the default runtime environment that runs on Android is nothing like the Java Runtime Environmeny (JRE). So at a minimum you would need to recompile all of openHAB and all of the libraries that openHAB depends upon in Android SDK. While there is a lot of overlap between the two, Dalvik and JRE are not the same. There are some APIs in JRE that are not in Dalvik and vise versa. On a project as large as openHAB you certainly are going to hit a library you cannot compile without modifying or reimplementing.

Assuming you can get it to compile then you have to run it. Given the number of problems that occur when even trying to run openHAB with OpenJDK verses Oracle Java, which is a complete reimplementation of the JRE, I have no confidence that openHAB would run well on a runtime environment that doesn’t even try to be functionally equivalent to Oracle’s JDK.

And then you have the problem that the Linux environment on Android is so vastly different from that which runs on a desktop or server (or board computer) that you would have to do some massive hacking to enable OS level features and services that openHAB needs to run. By the time you are done you won’t really have an Android OS anymore.

Now there is a workaround, assuming you have a rooted Android device. There is the Linux Deploy which creates a chroot Linux environment on your Android Device to run standard Linux apps. This is probably as close as you will be able to get, but realize that in this case you would not be running openHAB on Dalvik, you would have a separate parallel JRE installed upon which openHAB would run.

But again, some of the same issues arise that I already referenced concerning access to USB and hardware.

This post references running Eclipse (basis of openHAB 1) on android.

I had asked two concrete questions:

  • Why should the DAX vs. JVM bytecode difference matter?
  • Has anybody tried it, and what are the concrete problems.

I don’t see how your extended elaboration of your previous assumptions answers any of these. I think the Eclipse link is completely irrelevant because there the problem is SWT, while OpenHab seems to be a headless server.

I agree that USB / hardware access is likely to be a problem, but omission of certain (even all) hardware support should not prevent the core from running (even it it might be relatively useless without some hardware support).

Thanks, Rich, for the research and insights into the range of issues about running openHAB on Android. I learned a lot from the time and effort you contribute! :smile: Perhaps others can dig deeper into possibilities, but I think it’s probably full of challenges that are better addressed by a SBC like PINE64 running Debian.

1 Like

If you are unsatisfied with my answers, I suggest you go try it yourself and report back here with your experiences.

Given my experience think you will find it to be quite a challenge if not impossible.

To give this a spin, I have imported the OpenHab source into IntelliJ, which seems to build fine (AndroidStudio doesn’t seem to have Maven support unfortunately and Eclipse seems quite dead wrt. Android).

My plan was to create a simple Android module that depends on the very core of OpenHab just to see if there is a chance at all to get this work. Does this sound more or less reasonable?

Looking at the project structure, there are actions, bindings, io and persistence modules, but it’s not obvious to me what the actual core is (ties all this together and running the web server / interface)? Do you have any pointers for a good starting point (I found good documentation for module development, but that didn’t seem very helpful for this case)


The core includes the jetty web server, event bus, rules engine, persistence engine, base classes for items, actions, etc… also part of the core are any libraries the above depends upon and the over all OSGI container ( Eclipse for OH 1, karaf for OH 2).

The bulk of the actual core of OH is actually implemented by third parties (e.g. the OSGI container, jetty web server, Xtext language interpreter, etc) and getting all of those working on Android will be a big part of the challenge.

Beyond that, I think everything in org.openhab.core is a good place to start due the minimum set of classes needed to have a core OH.

Given that i have seen reports of karaf running on Android, i might suggest focusing on OH 2 instead of OH 1.

1 Like

Ok, here is why the DAX vs. JVM difference matters: Jetty loads webapps dynamically from a JAR (WAR) file. Loading OSGi components seems to work in a similar way. On Android, one would need to load DEX files instead.

Jetty seems to have official Android support in iJetty. Felix (used in Karaf AFAICT) seems to support Android out of the box – but I did not find a lot of information about Karaf itself. Do you have a pointer to your source?

A google search for Android and xtext seems to suggest that it works “out of the box” already.

So in my opinion, the main problem might not be getting all the core pieces to work on android, but to set up the corresponding Android build infrastructure properly (if Karaf works on Android somehow).

I just did a Google search for “karaf on Android” and I saw a couple of mentions of people getting it to work.

You probably ashtray are aware, but just in case you are not, everything needs to be compiled to DAX fit an Android version. You can’t mix JVM jars and DAX files.

I played around with running OH server on a broken Nexus tablet many years back, using Ubuntu Touch. It was interesting to see it working, but in the end switched to using an old laptop for better performance. The expandability and reduced latency when issuing commands really made an improvement, with many of the same benefits (battery backup, built in audio/display, low power consumption, etc).!topic/openhab/gapTQrrsIUw

I totally forgot about the option of running Ubunutu on a tablet. That should sidestep all the issues with DEX entirely.

I’m running now for over 2 years on an android tvstick. It proved to be far much more reliable that the rpi based installs (rpi had many times corrupted disks), and more economical and smaller.
Hence using android hardware but running Linux could be an option to explore as well!searchin/openhab/Hardware$20android/openhab/f8O3EPUjcWk

On a related topic… what about Windows 10 tablets based on x86 intel atom CPUs?

Would this present a platform, that could work out of the box? (with x86 binaries?)

Recently nice and powerful w10 tablets came to the market, at a reasonable price.
For example this 12" tablet would look great mounted on a wall for user interface… and i think it could run all necessary background services… Or could it?

See here:

If it will run Oracle Java Runtime Environment it will run openHAB. I know when MS first came out with their Surface tablets they limited you to only installing from the Windows Store. I don’t know if that is still the case. If not it should work no problem.

Somewhat related to this topic. I’m running OH1 on a Qualcomm Snapdragon 805 processor (same proc used in numerous Android phones/tablets). Using the Linaro kernel release and Linaro Ubuntu 14.10 + patches provided by Qualcomm, I was able to get it up and running just fine.

The specific hardware I’m using it Inforce 6540 Single-Board Computer, but it shouldn’t be much different from an other snapdragon-based platforms. The 600 ad 800 series of SoCs seems to be well supported by Linaro. I’ve had to recompile the kernel a couple times to add support for things like USB<->serial converters (Davis Vantage Weather Station), but it seems pretty reliable.

That being said, the newer tablets and phones are using ARMv8, which is a completely different architecture. Not sure what troubles that will bring.

Just as an update…
I got an opportunity to testdrive the before mentioned CHUWI windows tablet…
After installing java jre on windows 10 (64-bit system), I successfully ran OH.
While tablet is not the fastest one, openhab works like a charm…

1 Like

I hope also to see one day OpenHab server installed on Android running on my PINE64. I don’t know how much effort it requires but it will be very nice to have it.
I know that a French company Zodianet has already done this smart move by publishing the zibase multi on the android store…

Try to install a full Linux on Android. Just check “Complete Linux Installer” or “Linux Deploy” app on Playstore.