Home Assistant Companion for Android: the official app for a self-hosted smart home

What the Home Assistant Companion for Android actually connects

The README opens by calling this the official Android app for Home Assistant, which it describes as an open-source home automation platform. That single sentence defines the scope: the app is a client, not a hub. It does not store your device states, run automations or hold your configuration. Those live on the Home Assistant instance you already run, and the app is the surface you carry around. The intended audience is therefore narrow and easy to state. If you run Home Assistant and you carry an Android phone, this is the sanctioned way to reach it. If you do not run Home Assistant, nothing here applies to you. The repository topics hint at the breadth of that client role: android, automotive, compose, home-assistant, home-automation, kotlin, open-source-app and wear. Automotive and wear appear as separate top-level directories, so the project treats phone, car and watch as distinct targets rather than one app with a mode switch. The README also frames the project as one used by millions of users worldwide, though it offers no figure and none should be inferred from it.

Native Android hooks are the reason to use it over a browser

Home Assistant has a web interface, and on a modern phone that interface works. The README lists what the native app adds on top: widgets, notifications and location tracking, described as Android-specific features. It also mentions themes and dashboards under customisation. This is the honest dividing line for the project. A browser tab can render your dashboard; it cannot put a widget on the home screen, post a notification through Android's notification system, or report location in the background. Those three capabilities are the product. The trade-off is that each one depends on Android platform behaviour that changes between versions and manufacturers, which is why the repository carries a lint module and a separate testing-unit module rather than treating UI as the only concern. The README does not enumerate which sensors exist or how notifications are templated; for that it sends readers to the companion documentation site, and that site, not this repository, is where the feature list is maintained.

Repository layout: app, wear, automotive, common and build-logic

The top-level entries read like a multi-target Gradle project. There is app/, wear/ and automotive/, which map to the three form factors named in the topics. There is common/, which by naming convention holds code shared across those targets, and build-logic/, which holds the Gradle convention plugins the modules apply. There is also microwakeword/ and provides-sensor-processor/, two names that suggest a wake word component and an annotation processor for sensor definitions respectively. Those two directories are the most interesting signal in the layout, because they imply the sensor surface is generated rather than hand-written per sensor. Support files sit alongside: fastlane/ for store metadata, .maestro/ for end-to-end UI flows, lint/ for custom lint rules, testing-unit/ for shared test fixtures, and a set of AI assistant instruction files (AGENTS.md, CLAUDE.md, GEMINI.md, AI_POLICY.md) that tell you contributors are expected to declare how automated tooling was used. The README does not describe any of this; it is visible only from the directory listing.

Installing the Home Assistant Companion for Android

The README gives exactly two download routes, both pointing at the Play Store package io.homeassistant.companion.android. The stable listing is the first link, and a beta channel exists through the Play Store testing programme. The README says the app is also available in other app stores without naming them, so treat that as unverified. There is no APK link, no F-Droid instruction and no sideloading guide in the README.

If you are installing on a phone, this is the whole procedure as documented:

# no local build is needed to use the app
# open the Play Store listing and install
https://play.google.com/store/apps/details?id=io.homeassistant.companion.android

After install, the app expects a Home Assistant instance to connect to. The README does not document the onboarding flow, the login screen or the server URL field; it defers all of that to the companion documentation site. If you are building from source instead of installing, the README's contributing path is a fork, a branch, and a pull request, with the developer guide hosted on developers.home-assistant.io. The repository itself is a Gradle project, and the wrapper files gradlew and gradlew.bat are present at the top level, so a checkout is built with the wrapper rather than a system Gradle install:

./gradlew

The README does not state which JDK or Android SDK version that requires; check build-logic/ and the Gradle files in the checkout before assuming your local toolchain matches.

Where the app is the wrong tool

The clearest failure case is architectural. The app has no server component of its own, so on a network where the Home Assistant instance is unreachable, the client has nothing to show. The README does not describe any offline mode, local caching of entity state, or fallback to a cloud relay. Anyone expecting the app to keep working when the home server is down is reading a capability into it that the README does not claim. A second limitation is platform. This is the Android companion; the repository name and README are explicit about that, and the presence of wear/ and automotive/ widens the Android surface rather than extending to other platforms. A third constraint is distribution. The README's only concrete install channel is the Play Store, so devices without Play services, or users who avoid it, have no documented path from this repository. The README does say other app stores carry it but names none, and it does not publish an APK. Finally, the AI_POLICY.md and the several assistant instruction files at the top level mean there are contribution rules beyond code style; a drive-by patch that ignores them is likely to be sent back.

How this differs from a generic Android dashboard client

The obvious alternative is pointing a browser at your Home Assistant web interface, or wrapping it in a generic WebView shell. The difference is not rendering quality; it is access to Android APIs. A browser cannot register a home screen widget, cannot post through the notification channel system, and cannot report background location. The README lists exactly those three as the native additions, which is a fair summary of what you lose by staying in the browser. The second alternative is a third-party Android client for Home Assistant. The meaningful distinction there is provenance and surface area: this repository is the official one, it is Apache-2.0 licensed, and its layout shows dedicated modules for wear and automotive rather than a single phone app. A third-party client may cover the phone case well and still have no watch or car target. The README does not compare itself to any alternative, so the comparison has to be made from the directory structure and the feature list, both of which point the same way: breadth of Android form factors is the differentiator.

Maintenance pace, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-23. Recent releases are dated 2026-08-31 (2026.8.4), 2026-08-16 (2026.8.3) and 2026-08-09 (2026.8.2), a cadence of roughly two to three weeks between patch releases. The version scheme tracks the calendar, so 2026.8.x belongs to August 2026. That matters if you run Home Assistant itself on a similar calendar versioning scheme, because client and server are released on separate schedules and this README says nothing about a compatibility matrix. The practical upgrade cost for a user is a store update. For a contributor it is higher: the project carries a lint module, a detekt configuration, a Gradle lockfile (gradle.lockfile and settings-gradle.lockfile are both present) and Renovate configuration (renovate.json5), so dependency bumps arrive as automated pull requests and the build is pinned. The licence is Apache-2.0 per the repository metadata and LICENSE.md. That permits commercial and closed-source reuse under its terms, but it also means redistributed builds must carry the licence and attribution; if you fork and publish, read LICENSE.md and CLA.md rather than assuming a permissive licence removes all obligations. Nothing here is legal advice.

Editorial conclusion

Adopt it if you already run a Home Assistant instance and want Android-specific hooks such as widgets, notifications and location tracking, or if you want to build those hooks yourself from the Kotlin sources. Do not adopt it as a standalone smart home app: the README describes it as the official Android app for Home Assistant, so without a server there is nothing for it to control. Before installing, verify which app store build you are getting and whether the companion documentation covers the version of Home Assistant you run, because the README points to the documentation site for anything beyond the download links.

Frequently asked questions

Official sources

1. home-assistant/android on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases