Ava Pro turns spare Android devices into Home Assistant voice satellites

One APK per device, paired over the ESPHome API

Ava Pro is a native Android platform built specifically for Home Assistant. A single, lightweight installation on existing devices replaces a standalone ESP32 Bluetooth proxy, a dedicated satellite voice receiver and intercom hardware.

The connection is the part that matters for adoption. It connects via the standard ESPHome API, described as an officially certified secure millisecond-level protocol, with no MQTT, no HACS and no custom integration required.

That is a deliberate architectural choice. HACS is the community repository mechanism for Home Assistant custom components, and most third party Home Assistant projects require a custom integration to be installed and then kept in step with every core release. A device that speaks the ESPHome API needs none of that, which means a firmware update on the server side is enough to change how the device behaves.

The pairing flow is deliberately short. You install the APK, open Home Assistant, Ava appears in the discovered ESPHome devices, and you click Add. The device then presents itself to the server the same way any ESPHome node would, which is why it needs no special handling on the Home Assistant side.

The lineage matters too. The project gives special thanks to the original author for contributing the initial concept and design, and Ava Pro is based on the original brownard/Ava repository. It is a continuation, not a from-scratch project.

A C++ core, because a browser container would cook the tablet

The engineering argument in the feature list is about thermals and CPU, and it is worth taking seriously because the target hardware is old.

The core engine is written in native C++, not wrapped in a browser container. The claim is that even on a wall-mounted tablet, idle CPU usage is near zero, and that multiple devices which have been running on the wall for years have shown no overheating issues.

That is a meaningful design constraint. The alternative to a native core for a voice assistant on an old Android device is usually a WebView or a headless browser engine, which is exactly the kind of thing that pins a CPU and turns a tablet into a hot brick on a wall. A native core also removes a layer of latency between the microphone and the response.

The dependency list at the bottom of the README explains how much of the stack is native or how much is borrowed. It lists Home Assistant, ESPHome, WebRTC, Music Assistant, Sendspin, openWakeWord and microWakeWord, ONNX Runtime and TensorFlow Lite for the machine learning work, GeckoView, Shizuku, Jetpack Compose and Media3 for the interface and media, Protocol Buffers, and Opus for the audio codec.

openWakeWord and microWakeWord are the wake word engines, and the pairing with ONNX Runtime and TensorFlow Lite is what makes local voice inference possible on a device with no network round trip. GeckoView and Media3 are Mozilla and Android components, and Shizuku is the Android service that lets an app use system APIs with higher privileges without root.

Voice: local wake words, echo cancellation and voiceprint

The voice capability list is the most specific part of the documentation, and it is where the local inference claim is tested.

There is a C++ inference pipeline with custom wake words and dual wake support, so a device can respond to more than one phrase. Acoustic echo cancellation is included, with the effect that the wake word works while music plays, which is the difference between a voice assistant that works in a living room and one that does not.

There is local voiceprint recognition, stated as under 120 milliseconds, which distinguishes family members and filters TV audio. That is a privacy feature as much as a convenience one: the person identification happens on the device, so the audio does not need to leave it to be attributed.

There is also ambient sound detection for glass break, baby cry, doorbell, alarm and siren. All of it is processed on-device, which is the property that makes the whole design coherent. The privacy claim in the description is not a separate promise, it is a consequence of the architecture.

The cost of that architecture is the model files and the compute. A native C++ inference pipeline with ONNX Runtime and TensorFlow Lite on an old tablet is a meaningful amount of work for the device, which is why the documentation insists on the native core rather than a web container.

Every module is separable, and the device range is wide

The design decision that makes the application practical on mixed hardware is that all functions can be disabled.

The documentation's own framing: if the device's Bluetooth chip is too weak, simply disable the Bluetooth proxy. If you do not need intercom, there is a one-click deactivation. If you want a pure voice satellite, cut it down to voice only. Each module is completely decoupled, so you enable only the functions your device can handle.

That matters because the supported device range is enormous. The application supports Android 5.0 to 16 and runs on old Fire tablets, retired phones, car infotainment systems, smart mirrors and single board computers. A ten year old phone with a weak radio is still a usable voice satellite if you stop asking it to be a Bluetooth proxy.

The capabilities themselves are listed as separate blocks. The Bluetooth module is an ESPHome BLE proxy with IRK private address resolution, RSSI distance filtering with away-delay presence and screen-off scanning, extending Bluetooth coverage to every room where a device is placed, with no ESP32 required. The audio module is a LAN room-to-room intercom and voice messaging system, with Sendspin multi-room sync with Music Assistant at 5.4-level lossless, and audio that continues uninterrupted across overlay transitions. The display module offers multi-layer overlays in one process, floating panels, animated notification scenes, Stream Deck style quick entities, a Dawn magazine screensaver with smart always-on display and pixel shift, and an optional Home Launcher mode.

The sensor module is a native ESPHome environment pipeline for light, magnetic field, proximity, battery, Wi-Fi, storage, memory and uptime, kept alive by a foreground service with the screen off, with light and proximity fused for adaptive wake.

Camera, fleet control and runtime loaded mods

Three capabilities extend well beyond voice.

The camera module is a native binary direct pipeline with zero latency, no HTTP bridge and no frame buffering, and it exposes still captures and motion detection as Home Assistant sensors. The zero latency claim follows from the design: no frames are copied into a buffer for later processing.

The fleet module is the one that will matter to anyone running more than one of these devices. It uses UDP LAN discovery and ADB for remote screen control, shell access, logs and config push, with passcode and authorized deep-link access, so one console reaches every device in the house.

The mods module is the most unusual. It loads code at runtime with DexClassLoader, imports offline ZIP archives, and installs them directly, and the list of what people have built includes a DLNA renderer, an AirPlay receiver, Edge TTS with more than 400 voices, an offline speech to text engine, a Zigbee gateway, biometric authentication, GPS, on-device AI, camera RTSP and MJPEG to NVR, and device packs modelled on Echo Show, Portal and the Phicomm R1. Mods can be installed, updated or removed without touching the core.

That last point cuts both ways. A runtime class loader means a mod can do anything the app's permissions allow, which is exactly what a home automation user wants and exactly what a security reviewer will ask about. The documentation does not describe a signing or permission model for mods, so on a shared or exposed network that is a decision you make rather than one the project makes for you.

The licence forbids the two things a vendor would want

Ava Pro is licensed under CC BY-NC-ND 4.0, and the documentation spells out the terms: you may share it with attribution, and you may not use it commercially or distribute a copied or modified version.

That is unusual for an Android application, and it is the single most consequential fact about the project. A Creative Commons content licence rather than a software licence means no commercial use, and the no-derivatives clause means the modified build cannot be redistributed.

For the intended use, which is a person running this on their own devices at home, that is not restrictive. You can install the APK, share the link, tell people about it. What you cannot do is ship it inside a product, run it as a service for paying customers, or publish a fork.

The licence field in the repository metadata is one GitHub cannot classify, and the LICENSE.md file at the root is where the terms live, so the file rather than the summary is the thing to read before any distribution decision.

The releases carry codenames, 0.7.8 with 365, 0.7.7 with SMOOTH and 0.7.6 with GAMBIT, and the last push was on 2026-10-12 with the repository not archived. The version.json file at the root and the per-language scene files, custom_scenes.json, scenes_de.json, scenes_en.json and scenes_zh.json, suggest the build is assembled per locale.

Editorial conclusion

Ava Pro fits a Home Assistant user with old Android hardware lying around, who wants a wall tablet that answers voice commands and talks to the other rooms without buying a satellite speaker, and who is comfortable installing an APK and pairing an ESPHome device. It does not fit a commercial deployment, because the CC BY-NC-ND 4.0 licence forbids commercial use and redistribution of a modified copy, and it does not fit a user who wants a supported product, since the releases carry codenames and the project is a single author's continuation of an earlier repository. Before adopting it, read the licence terms, confirm the device's Bluetooth hardware is strong enough to serve as a proxy or switch that feature off, and check the wiki for the practical guides the README points to.

Frequently asked questions

Official sources

1. Issues
2. knoop7/Ava-Pro on GitHub
3. README
4. Releases