# openHAB Android: the habdroid client for a home automation server > openhab-android is the native Android client for openHAB, written in Kotlin and licensed EPL-2.0, which gives you sitemaps, push notifications through openHAB Cloud, NFC tag actions, voice commands and a Tasker plugin. Its FOSS build flavor drops the Google services so it can ship through F-Droid, at the cost of push notifications. **openhab/openhab-android** — openHAB client for Android - Repository: https://github.com/openhab/openhab-android - Website: https://play.google.com/store/apps/details?id=org.openhab.habdroid - Stars: 653 · Forks: 333 - Language: Kotlin - License: EPL-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/openhab-openhab-android ## A phone client, not a server, and not a controller hub The app is described in the README as a native client for openHAB which allows easy access to your sitemaps, and that single sentence sets the boundary. The server does the automation, the rules and the item states, and this app is the remote control for it. The audience is somebody who already runs an openHAB server and wants a phone front end for it, and the documentation lives at the openHAB site under the Android app page. It is written in Kotlin, the primary language of the repository, and the licence is EPL-2.0, which is the Eclipse Public License used across the openHAB ecosystem. The project publishes to Google Play under the package org.openhab.habdroid, to F-Droid, and as direct APK downloads from the GitHub releases, so there are three routes to the same app depending on how you want it distributed. ## What the client actually does beyond showing sitemaps The feature list is longer than a sitemap viewer, and the extra entries are what make it a home automation client rather than a web page in an app. You can control your openHAB server and/or an openHAB Cloud instance, for example an account with myopenHAB, and you can receive notifications through an openHAB Cloud connection. Items can be changed via NFC tags, so a physical tag near the phone becomes a switch. Voice commands can be sent to openHAB. The alarm clock time can be sent to openHAB, which is the feature that turns the phone into a bedside controller rather than a panel. The app supports wall mounted tablets, for a permanently deployed panel in a hallway or kitchen, and it includes a Tasker action plugin so an automation tool on the phone can drive it. The three screenshots in the README show the main menu, the widget overview and the main user interface, which is enough to see that the app is built around the sitemap widget model of the server rather than around a device list. ## Beta builds, and the Play testing channel The release history explains itself. The recent tags are 3.22.4-beta from 2026-10-18, 3.22.3-beta from 2026-10-07 and 3.22.1-beta from 2026-10-04, so every published version carries the beta suffix and the numbering follows the openHAB 3.22 release series rather than a separate app versioning scheme. The README explains how to get these builds: beta builds are distributed via GitHub and via F-Droid, at the package org.openhab.habdroid.beta, and those builds can be installed alongside the stable version, so the beta channel and the stable channel coexist on one phone. There is a third route, a Google Play opt-in, at the apps testing URL, which lets you receive updates of stable versions before other users do. That combination, a permanent beta channel on three distribution channels, is what you should expect from an app that is versioned in step with the server. It also means that a user on the beta build and a user on the stable build may be running different app versions against the same server, so server compatibility is something to check when you upgrade the server rather than only the phone. ## The foss flavor and what it costs you The build system is Gradle with a mobile module, and it offers an optional build flavor called foss for distribution through F-Droid. The README states what that flavor changes in one sentence: it has FCM and crash reporting removed and will not be able to receive push notifications from openHAB Cloud. That is the whole trade. FCM is Firebase Cloud Messaging, the delivery mechanism Google Play services provides, and without it the app has no channel to receive a cloud-initiated notification. So the choice is concrete. If your openHAB setup pushes notifications to your phone, for example an alarm triggered by a sensor, the foss build will not deliver them and you must use the full flavor from Google Play or the direct APK. If you are on F-Droid because you want to avoid Google services entirely, then your notifications have to arrive by another route, or the app becomes a poll-and-refresh control surface. The map view has a similar dependency: for the full build flavor you need to generate an API key from the Maps API page and add it to the gradle.properties file, either next to the readme or in $HOME/.gradle, as a line of the form mapsApiKey= with the key you obtained. Without that key, the map view is unavailable in the full build. ## Setting up a development environment in Android Studio The README walks contributors through the setup, and the sequence is the ordinary Android Studio one with one project-specific step at the end. The instructions are to download and install Android Studio, check out the latest code from GitHub via Android Studio, install the SDKs and Gradle if asked, and then, on the left side, click on Build Variants and change the build variant of the module named mobile to fullStableDebug. That last step is the one that trips people up, because the app is a multi-module Gradle project with several flavors and the default variant is not the one you want for local work. The repository confirms the shape, with a mobile/ module at the top level alongside build.gradle, settings.gradle, gradle.properties, gradlew and gradlew.bat, plus ci/, docs/, assets/ and fastlane/. The README also asks you to read the contribution guidelines in CONTRIBUTING.md before producing any amount of code. The Android app has its own store metadata under fastlane/metadata/android, which is where the Play listing and the localised descriptions live, so a change to the app's user-facing strings or store copy has more than one place it can land. Translations are handled separately, through Crowdin, and the README asks contributors not to submit translations as pull requests against the mobile/src/*/res/values-*/strings.xml files but to go through the Crowdin web service instead, with the project at crowdin.com/project/openhab-android. ## Where a phone app is the wrong piece of the system Three cases point elsewhere. The first is a household that wants notifications without opening an app. The client relies on an openHAB Cloud connection for push, and the FOSS build has FCM removed, so a setup that must avoid Google services and must still receive alerts needs a different notification path entirely. The second is a large installation with many users, where per-device provisioning and per-user credentials make a phone app the wrong interface and a wall panel or a voice assistant more appropriate. The third is a team that wants a maintained, stable channel. Every tag in the recent history carries a beta suffix, and the stable builds come from Google Play, so a deployment that requires a version-pinned, tested binary has to track the Play channel rather than the GitHub releases. There is a scope point as well. The app is the openHAB client, so the automation logic lives on the server, and none of the features listed here change that. NFC tags, voice commands, the alarm clock bridge and the Tasker plugin are all ways of getting input into the server, and anyone expecting local rules on the phone will be disappointed. The widget model that the screenshots show is the server's sitemap concept rendered on a phone screen, which is the right abstraction to reason about when deciding whether the app is a good fit for your installation. ## Conclusion openhab-android fits a household or small installer who runs an openHAB server and wants a phone that talks to it directly, on a device where the app has to be maintained by whoever set up the home. It does not fit a setup that depends on openHAB Cloud push notifications and also needs a F-Droid-only build, because the foss flavor removes FCM and crash reporting and cannot receive push notifications from openHAB Cloud. Before you build it yourself, generate a Maps API key and put it in gradle.properties for the map view in the full flavor, and note that every release you ship is tagged beta, so you are testing on the same channel your users are. ## FAQ ### What is openhab-android? It is the native Android client for openHAB, written in Kotlin and licensed EPL-2.0, which allows easy access to your sitemaps. The documentation for it is at the openHAB site under the Android app page, and the app is published as org.openhab.habdroid on Google Play, on F-Droid and as direct APK downloads from the GitHub releases. ### What can the openHAB Android app do besides showing sitemaps? It can control your openHAB server and/or an openHAB Cloud instance, receive notifications through an openHAB Cloud connection, change items via NFC tags, send voice commands to openHAB, send the alarm clock time to openHAB, run as a wall mounted tablet, and it includes a Tasker action plugin. ### What does the foss build flavor lose? The foss flavor, which is the one distributed through F-Droid, has FCM and crash reporting removed and will not be able to receive push notifications from openHAB Cloud. Everything else about the app is unchanged, so the cost of avoiding Google services is specifically the cloud push channel. ### How do I build openhab-android from source? Install Android Studio, check out the code from GitHub via Android Studio, install the SDKs and Gradle if prompted, then select Build Variants on the left and change the build variant of the mobile module to fullStableDebug. For the map view in the full flavor, generate a Maps API key and add mapsApiKey= to gradle.properties. ### How are translations for the openHAB Android app handled? All language and regional translations in the mobile/src/*/res/values-*/strings.xml files are managed with Crowdin. The README asks that translations not be contributed as pull requests against those files but submitted through the Crowdin web service, at the openhab-android project. ## Sources - [License: EPL-2.0](https://github.com/openhab/openhab-android/blob/main/LICENSE) - [openhab/openhab-android on GitHub](https://github.com/openhab/openhab-android) - [Project website](https://play.google.com/store/apps/details?id=org.openhab.habdroid) - [README](https://github.com/openhab/openhab-android/blob/main/README.md) - [Releases](https://github.com/openhab/openhab-android/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openhab-openhab-android