What it does: An open-source voice and AI assistant for Android. It listens for a wake word, transcribes speech on the phone or with Whisper, and answers with an on-device model (Gemma via llama.cpp) or a cloud assistant of your choice. Features come from installable, sandboxed skills: timers, alarms, Home Assistant, messaging, music, navigation, weather and reminders. Zero telemetry.
Who it's for: Android users who want an alternative to Google Assistant that they control, especially on GrapheneOS and other privacy-focused setups, and anyone who wants to decide for themselves where their voice and data go.
Source code: https://github.com/ari-digital-assistant (Android app: https://github.com/ari-digital-assistant/ari-android)
License: GPL-3.0 (Android app, Rust engine, Linux app). Skills Apache-2.0, website MIT, artwork CC BY-SA 4.0.
What mine adds: A skill store. Skills install separately from the app, run sandboxed in WebAssembly, ask for permissions before install and are reviewed before they're published, so new or updated skills never need an app release. A choice of on-device or cloud for both speech recognition and the assistant, each treated as first-class. Listening rules (schedule, screen on, charging, headset, at certain places), so the microphone doesn't have to be on all the time.
Builds on: sherpa-onnx (on-device speech recognition and voice detection), openWakeWord and microWakeWord (wake word), llama.cpp with Google's Gemma models (on-device assistant), Wasmtime (skill sandbox), ONNX Runtime, TensorFlow Lite Micro, MapLibre with OpenFreeMap (place picker map), UniFFI.
How it was built: Agentic engineering. I'm a professional software engineer, and Ari is built with AI agents (Claude Code) under my direction. I set the design, review the work and test every change on my own phone, and anything measurable gets measured first: the wake word model was chosen by scoring candidates against recordings of my household before it went anywhere near a phone.
Feedback/contributions wanted: Testers above all, especially people with different accents, since the wake word has to work for everyone. Also skill developers, and native speakers to translate (currently English and Italian).
---
DISCLAIMER
This is very early software. The reason I am making this post is to hopefully attract testers who will find what is likely to be a large number of bugs.
What is it?
Ari is an on-device voice & AI assistant for Android devices.
Doesn't Google Assistant/Gemini already do that?
Yes, but Google Assistant is proprietary and unless used for basic phone commands also uses cloud-based AI. Also, it requires Google Play Services (and AI services), which quite a few folks don't want on their device. Additionally, several security/privacy-focused Android distributions like GrapheneOS lose access to it, due to not running Google Play Services with privileged permissions.
What about Dicio?
Dicio is a fantastic project - one of (if not the) first privacy-first and open-source voice assistants for Android. There are however a few key differences between Dicio and Ari. Firstly, Dicio is purer. It uses exclusively on-device intelligence (for speech-to-text and text-to-speech), and its skills rely on exclusively open-source services. Ari is different - yes, you can have an on-device model running, but you can equally just connect it to ChatGPT, Claude or Gemini (and hopefully self-hosted AI in the near future). Yes, you can have on-device speech-to-text, but you can also just use Whisper - either self-hosted or via OpenAI. Ari lets you decide where you want to trade off between performance and privacy, with both treated as first-class citizens.
Do I need to have my microphone on all the time?
It depends (see next point). Google Assistant uses an on-device digital signal processor (DSP) which is constantly listening for a wake word. This is a very efficient and low-power device, which has very little impact on battery life. Currently (2026), third-party assistants such as Ari (and Dicio) do not have access to this. This means the only way to be listening constantly is to have Ari using the microphone all the time.
In a July 2026 decision on case DMA.100220, the European Union has mandated that always-on hotword detection via the DSP, along with other core Android services related to digital assistants, be opened up to third parties. However, Google have until August 2027 (Android 18) to implement most changes, and up to August 2028 (Android 19) for concurrent hotword detection. So, for now, third-party assistants must have the microphone on to detect their wake word.
Won't having my microphone on all the time drain battery? Also, privacy!?
Yes, I get you. This annoys me too. However, I have tried to make it as painless as possible. First, you don't actually have to have it on all the time. Ari can be set as your default digital assistant in Android, meaning (depending on device) your hardware button can invoke Ari. Secondly, a scheduling system is available so you can decide when Ari listens - you can schedule on/off by time of day, when the screen is on, whilst charging, when a headset is connected, or even at certain places - as well as any combination of these.
As for battery life, having it on all day currently uses about 11% more battery in 24 hours compared to having it off. This has only been tested on my Pixel 10 Pro Fold running GrapheneOS, YMMV. Ari uses openWakeWord or microWakeWord for wake word detection, with many optimisations to try and make it as efficient as possible - but until Google implements the changes (and hopefully, not just for the EU), this is the best we can hope for.
What on-device models can it use?
For speech-to-text, Ari can use on-device transcription, Whisper hosted by OpenAI, or self-hosted Whisper. For AI responses, you can choose between Gemma 3 1B (small), Gemma 4 E2B (medium) and Gemma 4 E4B (large). Hopefully, this selection can be expanded in the future with more on-deivce options, implemented as modules.
What can it do?
Ari has a skills system. Unlike other assistants where new/updated skills require a new release of the app, skills are external in Ari. This means anyone can develop skills and publish them to the skill store. They'll then show up in a built-in skill browser for users to install. By default, no skills are installed. It is up to the user to install additional skills and accept sandboxed permissions they require. Moreover, all system calls made by skills go through Ari first, which only allows a subset of on-device permissions. Skills need to be approved (by a human), are audited, and always ask for permissions prior to installation.
Skills I've built are: Timer (with support for named and multiple timers), Home Assistant, Navigation, Alarm, Media control, Messaging (SMS, WhatsApp, Signal, Messenger, Slack and Matrix), Weather, Reminders (with support for CalDAV) and assistant skills for ChatGPT, Claude & Gemini if you decide not to use an on-device assistant.
What can't it do?
In general, if Ari can't do something it's because there isn't a skill for it yet. However, there are a few things that limit Ari compared to Google Assistant, especially until the EU's deadlines on Google approach.
Ari must be listening to detect a wake word, which currently means leaving the microphone on, either all the time, or via a schedule (see above).
Music skill - certain music services restrict their integration API to just the Google Assistant, meaning they are not supported. Currently, Ari supports Spotify, Apple Music, Tidal & Deezer. Features available vary by music service.
Messaging skill - whilst certain services allow you to have a conversation totally hands-free, for other services their integration API either specifically needs Google Assistant, or they don't support this at all. Meaning the best Ari can do is transcribe your message and add it to a conversation with a contact, but you'd have to tap 'send' yourself.
Features which use location (such as listening at certain places, or weather for your current location) use Google Play Services where it's installed, and Android's own location services where it isn't. Without Play Services, listening at certain places needs your phone to provide its own network location, as GrapheneOS does; on phones without one, that feature won't work. Ari also includes Google's location library, which keeps it off F-Droid for now; hopefully an F-Droid build without it will follow.
Is it really zero telemetry?
Yep. Unless you choose to use something like OpenAI as your assistant backend, in which case there is of course their own telemetry. Ari itself doesn't collect anything.
The only way data is shared with third-parties is if:
You specifically choose to send me your transcripts when debugging an issue, which is disabled by default and requires user interaction and confirmation.
You choose to have Ari remember things about you (such as your name or where you live). These are only stored on-device, but of course if you use a cloud assistant they will be part of its system prompt.
What does it look like?
Please see screenshots and demo video on the website heyari.dev. The website is still under construction, but you should get a decent idea.
What languages does it support?
Currently, Ari supports English and Italian. I'm a native English speaker, but a foreign Italian one, so it probably needs a lot of polish. In the future, Ari will hopefully speak as many languages as possible.
Where can I learn more?
Check out the project's website heyari.dev. You can also browse the source for the Android App, and everything else (skills, engine, the website) here.
Ok, I'm intrigued. How do I become a tester?
Please fill in the form here (this will take you to https://heyari.dev/tester). You'd need to do so with the email you're signed into the Google Play store with. You'll receive a link to install the testing version of the app once you're added as a tester.
There's a limit of 100 testers, so these are on first-come, first-served basis. Also remember I'm just one guy - so it may take a day or two before you receive your link.
---
Thanks for reading the long post. I hope this interests you in becoming a tester. So far, work on Ari has taken around 8 months. Not full time of course, I have a day job and a toddler, but it's fair to say I've worked on it for at least 4 days a week in the last 8 months. The next important stage is testing beyond my single use case, hence this post!
