App
Android app
Problem
Context and motivation
VocaPhone's recognition backend is genuinely good — that part has already won me over, I'll be using it regardless of what happens with this request. The keyboard UX side, though, is where I currently bounce off as a user who spends most of his typing time on regular text entry rather than dictation. Getting a keyboard's UX to a level where you stop wanting to switch away from it usually takes a long time — many months of iteration on things like layout, popups, gestures, edge cases — and that's a genuinely separate discipline from getting recognition right.
That got me thinking: why carry two hard problems (a good recognition backend and a polished keyboard UX) when one of them is already solved elsewhere, mature and open-source? Android already has a standard mechanism for exactly this kind of split — a keyboard's mic key doesn't have to record audio itself, it can hand off to whatever IME is registered as a voice-input shortcut, then get control back once that IME is done. If VocaPhone plugged into that standard, each project would only need to do what it's already good at and was conceptually meant to do: HeliBoard handles the keyboard UX it has already spent years maturing, VocaPhone handles recognition, which is its actual strength.
As a user, this would give me a real, working workflow today, without waiting on anyone: dictate through VocaPhone, type/edit through HeliBoard, right now — not "eventually, once VocaPhone's own keyboard UX catches up."
I also want to flag, genuinely not to be discouraging: I'm not sure it's the best use of a small team's time to maintain two hard, wide-scope areas at once (recognition and keyboard UX/input). You obviously know your own bandwidth and roadmap better than I do, and maybe you've deliberately decided both are worth owning long-term — that's a completely reasonable call to make. I just wanted to share the reasoning, since it's part of why I'm asking for this specific integration instead of a broader keyboard UX rework.
The good news on the "how much work is this" front: I checked HeliBoard's source, and no change is needed there at all — the mechanism it uses is a standard system API, not a hardcoded list. On VocaPhone's side, the fix looks like a single, small, targeted change (I went through the code and pinned down exactly where). Details below.
As for Heloboard, I just know it as and the most recent, up-to-date, and open-source, LatinIME fork, which reportedly can handoff the voice input procedure to another app. I'm not suggesting to focus exclusively on it. It's just about already existing, open and widely used standards, not a vendor lock-in.
Smallest change
How HeliBoard's mic key works today
RichInputMethodManager.switchToShortcutIme() / updateShortcutIme() in RichInputMethodManager.kt reads InputMethodManager.getShortcutInputMethodsAndSubtypes() and switches to whatever it finds there via switchInputMethod(). That's a standard Android system API call — the OS itself maintains this list based on which installed IMEs declare an auxiliary voice subtype. Nothing HeliBoard-specific, nothing to patch on their end. This is also how Gboard's mic key has worked with Google Voice Typing for years — same underlying mechanism, not something proprietary to Google.
What's currently blocking this on VocaPhone's side
android/app/src/main/res/xml/method.xml currently declares no subtypes:
<input-method xmlns:android="http://schemas.android.com/apk/res/android"
android:supportsSwitchingToNextInputMethod="true" />Without a subtype declaring android:mode="voice" and android:isAuxiliary="true", VocaPhone never shows up in getShortcutInputMethodsAndSubtypes(), so HeliBoard (or any other standards-compliant keyboard) has no way to discover it as a voice-input target.
What I think would need to change
The actual dictation pipeline already looks complete and wouldn't need to be touched — VocaPhoneInputMethodService + DictationService + the MicDictationControl state machine (START → FINISH → commit) already does what's needed. The gap is just the entry/exit point:
- Add a voice subtype to
method.xml:
<subtype
android:label="@string/voice_input_label"
android:imeSubtypeMode="voice"
android:isAuxiliary="true" />
- When
VocaPhoneInputMethodService is activated via that subtype specifically, show a minimal "listening" view instead of the full keyboard UI — essentially the existing mic/dictation screen, just as the only thing on screen.
- On finishing dictation (after commit), call
switchToPreviousInputMethod() instead of staying resident as the active IME, so the user lands back on their regular keyboard immediately.
That's a small, additive change on top of what's already built, and it doesn't touch the main keyboard layout/UX at all.
Happy to test a build if this is something you'd consider.
Other options (optional)
No response
Before you submit
App
Android app
Problem
Context and motivation
VocaPhone's recognition backend is genuinely good — that part has already won me over, I'll be using it regardless of what happens with this request. The keyboard UX side, though, is where I currently bounce off as a user who spends most of his typing time on regular text entry rather than dictation. Getting a keyboard's UX to a level where you stop wanting to switch away from it usually takes a long time — many months of iteration on things like layout, popups, gestures, edge cases — and that's a genuinely separate discipline from getting recognition right.
That got me thinking: why carry two hard problems (a good recognition backend and a polished keyboard UX) when one of them is already solved elsewhere, mature and open-source? Android already has a standard mechanism for exactly this kind of split — a keyboard's mic key doesn't have to record audio itself, it can hand off to whatever IME is registered as a voice-input shortcut, then get control back once that IME is done. If VocaPhone plugged into that standard, each project would only need to do what it's already good at and was conceptually meant to do: HeliBoard handles the keyboard UX it has already spent years maturing, VocaPhone handles recognition, which is its actual strength.
As a user, this would give me a real, working workflow today, without waiting on anyone: dictate through VocaPhone, type/edit through HeliBoard, right now — not "eventually, once VocaPhone's own keyboard UX catches up."
I also want to flag, genuinely not to be discouraging: I'm not sure it's the best use of a small team's time to maintain two hard, wide-scope areas at once (recognition and keyboard UX/input). You obviously know your own bandwidth and roadmap better than I do, and maybe you've deliberately decided both are worth owning long-term — that's a completely reasonable call to make. I just wanted to share the reasoning, since it's part of why I'm asking for this specific integration instead of a broader keyboard UX rework.
The good news on the "how much work is this" front: I checked HeliBoard's source, and no change is needed there at all — the mechanism it uses is a standard system API, not a hardcoded list. On VocaPhone's side, the fix looks like a single, small, targeted change (I went through the code and pinned down exactly where). Details below.
As for Heloboard, I just know it as and the most recent, up-to-date, and open-source, LatinIME fork, which reportedly can handoff the voice input procedure to another app. I'm not suggesting to focus exclusively on it. It's just about already existing, open and widely used standards, not a vendor lock-in.
Smallest change
How HeliBoard's mic key works today
RichInputMethodManager.switchToShortcutIme()/updateShortcutIme()inRichInputMethodManager.ktreadsInputMethodManager.getShortcutInputMethodsAndSubtypes()and switches to whatever it finds there viaswitchInputMethod(). That's a standard Android system API call — the OS itself maintains this list based on which installed IMEs declare an auxiliary voice subtype. Nothing HeliBoard-specific, nothing to patch on their end. This is also how Gboard's mic key has worked with Google Voice Typing for years — same underlying mechanism, not something proprietary to Google.What's currently blocking this on VocaPhone's side
android/app/src/main/res/xml/method.xmlcurrently declares no subtypes:Without a subtype declaring
android:mode="voice"andandroid:isAuxiliary="true", VocaPhone never shows up ingetShortcutInputMethodsAndSubtypes(), so HeliBoard (or any other standards-compliant keyboard) has no way to discover it as a voice-input target.What I think would need to change
The actual dictation pipeline already looks complete and wouldn't need to be touched —
VocaPhoneInputMethodService+DictationService+ theMicDictationControlstate machine (START → FINISH → commit) already does what's needed. The gap is just the entry/exit point:method.xml:VocaPhoneInputMethodServiceis activated via that subtype specifically, show a minimal "listening" view instead of the full keyboard UI — essentially the existing mic/dictation screen, just as the only thing on screen.switchToPreviousInputMethod()instead of staying resident as the active IME, so the user lands back on their regular keyboard immediately.That's a small, additive change on top of what's already built, and it doesn't touch the main keyboard layout/UX at all.
Happy to test a build if this is something you'd consider.
Other options (optional)
No response
Before you submit