Daniel's been voice typing long enough that he's hit a wall most people don't even know exists. He can see that Android has this clean architectural split between the keyboard and the speech engine, but every app he installs keeps trying to weld them back together. His question is really about why that gap between design and practice is so wide, and what you do about it if you actually want to choose your own voice backend with your own keyboard.
And he's right that the split is real. Android has two separate system services here. The Input Method Editor, the IME, which is your keyboard app. And the speech recognition provider, which is a completely independent thing. You set them independently, you configure them independently, and the OS treats them as distinct layers.
So the architecture is smarter than the apps sitting on top of it. That's the tension Daniel's poking at.
The vocabulary matters here because the confusion starts with the words. When you tap the microphone icon on Gboard, you think you're using Android's voice input. You're not. You're using Google's speech-to-text engine, which Gboard bundles and calls directly. The system has its own default speech provider setting, and Gboard's mic button bypasses it entirely.
So there are two different microphones, effectively. The one on the keyboard, which belongs to the keyboard maker, and the one at the system level, which belongs to whatever you set as your default voice input provider.
And the system-level one is a first-class construct. Any app can invoke it through the RecognizerIntent. An app fires an intent that says, I want speech recognition, and Android routes that to whatever speech provider is set as the default. Not the keyboard's bundled engine. The default.
Which means the OS was designed for exactly the flexibility Daniel wants. Pick your keyboard, pick your speech engine, they don't have to come from the same company.
The setting is buried, though. Settings, System, Languages and input, Voice input. Four levels deep, and the label doesn't exactly scream this is separate from your keyboard.
Four levels deep and named like a subheading in a manual nobody read. That's where the design intent goes to die.
The way it works in practice, there are two invocation paths. The keyboard's own mic button, which is the one everyone uses, and it usually calls the keyboard's bundled STT directly. And then the system-level voice input action, which is the one that respects your default provider. Long-press on home, or a dedicated key on some devices, or certain apps that explicitly request system voice input.
So the keyboard mic is a private line, and the system voice input is the public switchboard. And most people only ever see the private line.
That's the distinction Daniel's been living with. He's experimented with local Whisper models, cloud APIs, specialized STT services. If he wants to point Android at one of those, the system provider setting is where it happens. But only if his keyboard actually invokes the system intent instead of its own mic.
And that's the catch. The keyboard has to choose to respect the decoupling. Nothing forces it to.
There's a concrete example of this in the open-source world. HeliBoard, a privacy-focused keyboard, has an open issue, number nine eighty-eight, about implementing support for invoking the system speech provider rather than bundling its own STT. The maintainers had to explicitly build in the option to say, when the user taps the mic, fire the RecognizerIntent and let the system handle it.
Which tells you even the well-intentioned keyboards have to do extra work to respect a split the OS already provides. The default behavior is to bundle.
Right, and the fact that it's an issue on a tracker means someone had to request it. The obvious thing is to ship your own speech engine or just not have a mic button at all.
And then there's FUTO's voice input project, a standalone STT app. It exists entirely separately from any keyboard. You install it, you set it as your default speech provider, and then theoretically any keyboard that fires the system intent can use it.
FUTO's issue number seven is part of that story. It's an STT-focused app that doesn't try to be a keyboard at all. It's just the speech engine. Which is exactly the kind of thing the architecture was built to support.
So the two examples bookend the problem. HeliBoard is a keyboard that had to learn to call out to the system. FUTO is a speech engine that's waiting for keyboards to call it. The architecture supports the split, but the ecosystem keeps pulling them back together.
And that's the mechanism. The OS gives you two independent services, a routing layer between them, and a default setting for each. What it doesn't give you is any guarantee that the apps you install will use those defaults.
Which raises the question of why. Why would Gboard, the most popular keyboard on the planet, let you point its mic button at someone else's speech engine?
It wouldn't. And the reason is the incentive structure. Gboard bundles Google's STT because that's the point of Gboard. It's a data collection surface first and a keyboard second. Every time you tap that mic, Google gets your voice, your speech patterns, the context of what you're dictating.
The keyboard is the front door. The speech engine is the listening post behind it.
And SwiftKey does the same thing with Microsoft's STT. The mic button is a feature of the keyboard, not a system service. It's branded, it's integrated, it's part of the product.
So for the closed-source keyboards, the bundling is the business model. The keyboard is how they get your voice data, and the speech engine is where the value is.
And then there's the offline dictation tools, which bundle for a different reason. They want to guarantee their STT works without network, so they ship a keyboard and a speech engine as a single unit. One APK, both components.
Which is technically unnecessary. The OS would let them ship just the speech engine and let you pair it with whatever keyboard you want.
But they don't, because then they'd have to rely on keyboard makers to invoke the system intent. And keyboard makers don't have much reason to do that. So the offline dictation tool ships its own keyboard to guarantee the integration.
It's a guarantee problem. The only way to ensure the mic button talks to your speech engine is to own the mic button.
And that's where the user-facing confusion really sets in. Because the mic button lives on the keyboard, users assume voice input is a keyboard feature. They don't know there's a separate default speech provider setting. They don't know they can change it.
The mic button is a visual shortcut that erases the architecture. It looks like the keyboard owns voice input because the icon is right there on the keyboard.
And once that mental model is set, the idea that you could swap out the speech engine independently feels like a hack. Like you're doing something the phone wasn't meant to do.
When actually the phone was meant to do exactly that, and the app layer is the thing fighting it.
There's a knock-on effect here too. This bundling makes it much harder for alternative STT providers to gain traction. If you build a better speech engine, you can't just ship it and let people pick it. You have to either build a keyboard too, or convince keyboard makers to invoke the system intent.
Which is a classic platform versus app-layer tension. The platform provides flexible primitives. The app layer consolidates them into silos because that's where the money and control are.
It's the browser story all over again. Android provides intents and defaults and services, and then a few dominant apps become the de facto OS because they control the entry point. The keyboard is the entry point for text, and text is everything.
So the misconception Daniel's trying to correct is that Android doesn't support flexible voice typing. It absolutely does. The OS has a first-class speech provider setting independent of the keyboard. What it doesn't have is any app that surfaces that setting in a way users can find.
And the second misconception is that the mic button on your keyboard uses your default voice input provider. For most keyboards, it doesn't. It uses whatever the keyboard maker bundled.
And the third one, which is the one that actually matters for Daniel's experiments, is that if you want to use a local Whisper model, you have to use a keyboard that bundles it. You don't. You can set a local STT provider as the system default and use it with any keyboard that invokes the system speech intent.
The problem is finding a keyboard that invokes the system speech intent. That's the bottleneck.
HeliBoard is one of the few that's actively working on it. FUTO voice input is one of the few speech engines that exists independently. The two projects are almost designed for each other, but they're still separate projects with separate installs and separate configuration.
And that's the practical frustration. Daniel's been voice typing for years, experimenting with local and cloud models, and he still has to go hunting for the combination that the OS was designed to support out of the box.
The design is elegant. The discoverability is terrible. Four levels deep in settings, behind a label that doesn't explain itself, and then the apps actively work against it.
The settings path is worth spelling out because it's the thing most people never find. Settings, System, Languages and input, Voice input. That's where you see what your current default speech provider is, and where you'd set a different one if you installed FUTO or something similar.
And once you set it there, it only matters if the app you're typing in fires the system intent. If it fires the keyboard's mic button, which is what most keyboards do, your default setting is irrelevant.
So you have to check both layers. What's your default speech provider, and does your keyboard actually use it. Daniel's point about going hunting is exactly right. You have to verify both.
And the fact that he's had to verify both, repeatedly, across multiple keyboards and multiple STT models, is the whole problem in one anecdote. The architecture is there. The ecosystem keeps hiding it.
There's a deeper pattern here that's worth naming. Android gives you flexible primitives, intents, services, defaults. And then the app layer consolidates those primitives into silos because consolidation is easier to monetize and easier to control.
The browser became the de facto OS on Android because it consolidated everything into one address bar. The keyboard is doing the same thing for text input. It's consolidating typing and dictation into one app that owns the whole pipeline.
And once an app owns the whole pipeline, it has no incentive to expose the seams. The seams are where users could swap in a competitor.
So the decoupling is real, but it's invisible by design. Not by the design of the OS, but by the design of the apps that sit on top of it.
And that's the thing Daniel's been circling. The OS is well designed for flexible dictation. The apps are well designed to prevent it.
Which brings up the question of what actually changes this. If local STT models keep improving, does the pressure to decouple grow, or does the bundling just entrench further?
I think it could go either way. On one hand, local models are getting good enough that a privacy-focused keyboard could ship a decent on-device STT without needing Google's cloud. That's the HeliBoard path. But on the other hand, the big players have every reason to keep bundling, because the voice data is valuable and the integration is sticky.
The stickiness is the thing. Once you're used to Gboard's mic button just working, the idea of configuring a separate speech provider feels like a downgrade, even if it's actually more flexible.
And the average user never gets far enough to find out. They tap the mic, it works, they never think about it again. The architecture is invisible because it works.
It's the paradox of good defaults. The default is good enough that nobody goes looking for the alternative, and the alternative is hidden anyway.
Daniel's in a different position because he's explicitly experimenting. He wants to swap in a local Whisper model, or a cloud API, or a specialized STT service. So he's forced to confront the architecture directly.
And what he found is that the architecture is there, but the apps don't surface it. The offline dictation tools bundle a keyboard with their STT. The closed-source keyboards bundle their STT with the keyboard. Everyone's bundling something.
The only ones who aren't bundling are the open-source projects that are explicitly trying to respect the decoupling. HeliBoard on the keyboard side, FUTO on the speech engine side.
Even HeliBoard had to have someone file an issue to get it to do the right thing. The default behavior in the ecosystem is to bundle, and the decoupling is something you have to opt into.
Which is backwards from how the OS was designed. The OS decouples by default. The apps rebundle by default.
The answer to Daniel's question about why there's so much confusion is that the confusion is manufactured. The architecture is clear. The apps make it confusing.
They make it confusing in a specific way. The mic button on the keyboard looks like a system feature. It's not. It's an app feature that happens to look system-level because it's on the keyboard, and the keyboard is the thing you interact with constantly.
The keyboard is the most system-feeling app on the phone. It's always there, it's always visible, it feels like part of the OS. So when it has a mic button, that button feels like part of the OS too.
But it's not. It's a button that calls a specific speech engine owned by the keyboard maker. And the actual system speech provider is sitting in a settings menu four levels deep, waiting for an app to invoke it.
There's a weird inversion. The thing that feels most system-level is the least system-level, and the thing that is actually system-level is buried where nobody looks.
That inversion is the whole story. It's why Daniel has to go hunting, why the combinations are hard to find, and why most people never realize the flexibility exists.
Let's talk about what actually happens when you do go hunting. You install FUTO voice input, you set it as your default speech provider, and then you install a keyboard that fires the system intent. What's the experience like?
It's mostly fine, once you get past the setup. The keyboard's mic button, if it's configured to fire the RecognizerIntent, will route to FUTO. FUTO does its thing, returns the text, and the keyboard inserts it. The user sees no difference in the flow.
The decoupling, when it works, is invisible in the good way. The user just taps the mic and gets text, same as always.
The difference is under the hood. The text is coming from a local model, or a different cloud provider, or whatever you've set. And if you want to change it, you change the default speech provider, not the keyboard.
Which is the flexibility Daniel's been looking for. Swap the keyboard, keep the speech engine. Swap the speech engine, keep the keyboard. The two are independent.
That's the thing most voice typing apps obscure. By offering a single solution that takes over everything, a keyboard with a mic button and its own dictation mechanism, they make it seem like the two are inseparable.
The single solution is easier to sell. One app, one install, everything works. The decoupled solution is more flexible but requires two installs and a settings change.
The single solution is what the app stores surface. Search for voice typing, you get keyboards with built-in dictation. You don't get speech providers, because speech providers aren't a category in the Play Store.
The app store taxonomy itself reinforces the bundling. There's no speech provider category. There's just keyboards, and some of them happen to do voice.
Even the distribution channel is working against the architecture. The OS has a first-class speech provider construct, but the store doesn't recognize it as a thing you'd search for.
Which means the only people who find FUTO or similar projects are the ones who already know what they're looking for. Daniel found it because he's deep in this stuff. The average user never would.
That's the discoverability problem in a nutshell. The architecture is there, the apps exist, but the path from wanting flexible dictation to having it is completely opaque.
We've got a design that's elegant, an ecosystem that's hostile to it, and a settings menu that hides the one control that would make it work. That's the landscape Daniel's been navigating.
The reason it matters is that voice typing is getting better, not worse. The models are improving, the latency is dropping, the accuracy is climbing. More people are going to want to use it, and they're going to hit the same wall Daniel hit.
They'll tap the mic, it'll work, and they'll never know they could have swapped in a different engine. Or they'll want to swap, and they'll find out it's possible but only if they dig.
The open question is whether the pressure from better local models will force the bundling to break. If a local STT gets good enough, a keyboard that respects the decoupling becomes more attractive, because it can offer privacy without sacrificing accuracy.
But the big players can just bundle better local models too. Gboard already does on-device speech recognition in some contexts. The bundling doesn't have to break; it can just absorb the improvement.
That's the pessimistic read. The optimistic read is that the open-source projects, HeliBoard and FUTO and the like, create a viable alternative path that keeps the decoupling alive.
Daniel's experiments are part of that. Every time someone sets FUTO as their default speech provider and pairs it with a keyboard that fires the system intent, they're proving the architecture works.
The architecture was never the problem. It was always the apps.
The apps aren't going to change on their own. Gboard has no reason to add a use system speech provider toggle. SwiftKey has no reason either. The toggle would only matter to people who want to leave, and they're not going to build an exit ramp.
The exit ramp has to come from the open-source side. HeliBoard's issue nine eighty-eight is an exit ramp. FUTO's standalone STT app is an exit ramp. Small, hard to find, but real.
The people who need them are the ones who already know the architecture exists. Which is a small group, and Daniel's in it.
He's been voice typing for years, experimenting with local and cloud models, and he's still having to explain to people that the keyboard and the speech engine are separate. That's how deep the confusion goes.
The confusion is the product. Not in a conspiratorial sense, but in the sense that the apps benefit from you not knowing the difference.
The OS doesn't benefit from you knowing either. Android doesn't run ads on your voice data. Google does, but Android as a platform is neutral. It just doesn't surface the setting.
Nobody with the power to fix the discoverability has the incentive to fix it. Google's not going to put a use system speech provider toggle in Gboard. And Android's not going to put a big banner in settings saying your keyboard and your speech engine are separate.
Which leaves it to the users who care to do the digging. And Daniel's done the digging, and he's sharing what he found.
What he found is that the split is real, the settings path exists, and the apps that respect it are few but they're there.
Hilbert: I worked a temp job in twenty eleven at a call center that used early Android tablets for customer surveys. Custom keyboard app, separate voice input provider. I was the guy who had to explain to new hires why the mic button on the keyboard didn't use the same speech engine as the system voice input. Spent three days thinking the tablet was broken because the two gave different results.
That's the exact confusion Daniel's describing, but in a workplace setting. The mic button doing one thing, the system voice input doing another, and nobody understanding why.
Hilbert: I wrote a training doc. Printed on yellow paper. Had a diagram I drew by hand showing the two paths. Keyboard mic goes here, system mic goes here. Took me an afternoon.
The yellow paper is a nice touch. Very official.
Hilbert: It wasn't official. It was the only paper left in the supply closet. But it worked. New hires stopped asking why the two mics gave different answers.
The fact that a temp worker had to write a training doc to explain Android's architecture to new hires is a pretty good summary of the discoverability problem.
Hilbert: The settings menu doesn't help. It buries the voice input provider under Languages and input and never explains that it's separate from the keyboard. I had to figure that out by poking around for three days.
Your experience matches Daniel's. The architecture is there, but the path to understanding it is completely unmarked.
Hilbert: The architecture's fine. It's the explanation that's missing. Nobody tells you the keyboard and the speech engine are two different things. You have to find out the hard way.
Once you know, it seems obvious. But until someone draws you the diagram, you're just confused about why the mic button and the voice input setting don't agree.
Hilbert: I still have the doc, I think. In a box somewhere. Yellow paper, hand-drawn diagram, the whole thing.
You should dig that out. That's a piece of Android history.
Hilbert: It's not history. It's a piece of paper with a diagram on it. But it might still be in the storage unit.
If you find it, we should do a segment on it. The lost art of the hand-drawn Android architecture diagram.
Hilbert: I'll look. No promises. It's been fifteen years.
The diagram probably still explains the split better than the settings menu does.
Hilbert: It explained it better than the settings menu did in twenty eleven. Doubt the settings menu's gotten much clearer since.
It hasn't. It's still the same four-level path with the same unhelpful label.
Hilbert: There's your answer then. The confusion isn't just the app makers. It's Android's own settings menu burying the one control that would make the whole thing make sense.
The apps obscure it, and the OS doesn't surface it. The user is stuck between two things that both fail to explain what's happening.
Hilbert: That's what I told the new hires. The keyboard mic is one thing. The system mic is another. They don't talk to each other unless someone builds the bridge.
Most keyboard makers don't build the bridge because they'd rather own both sides.
Hilbert: Can't blame them. If I owned both sides, I'd keep it that way too.
The question is whether anyone with the power to change it has a reason to. And the answer seems to be no.
Hilbert: The reason would be if enough people wanted it. But most people don't know they want it because they don't know it exists.
Which is the loop we've been describing. The confusion is self-perpetuating.
Hilbert: That's why I wrote the doc. Break the loop for the next person. Even if it was on yellow paper.
Hilbert: It was what we had.
The open question I keep coming back to is why no major keyboard maker has shipped a use system speech provider toggle prominently. The architecture supports it. The setting exists. The only thing missing is a big obvious switch in the keyboard's own settings.
The answer is that the toggle would be an exit ramp. It would tell users, hey, you can leave our speech engine and use someone else's. No company builds that voluntarily.
But a smaller player could. A keyboard that doesn't have its own STT, or doesn't care about voice data, could ship the toggle as a feature. Use whatever speech provider you want, we don't care.
That's basically what HeliBoard is doing. It doesn't have its own STT, so it fires the system intent and lets you choose. The toggle is implicit in the design.
As local STT models improve, that approach becomes more viable. A keyboard that just handles typing and lets the system handle speech is actually a coherent product.
The question is whether it can compete with the bundled experience. Gboard's mic button just works. HeliBoard's mic button works too, but only after you've configured a speech provider and made sure the intent fires correctly.
That's the tradeoff. Flexibility versus friction. The decoupled path is more flexible but has more setup. The bundled path is easier but locks you in.
Daniel's been living in that tradeoff for years. He's willing to do the setup because he wants the flexibility. Most people aren't.
Which is why the bundling persists. The friction is the moat.
The friction is the moat. That's the whole episode in four words.
The moat is going to hold until someone makes the decoupled path as easy as the bundled one. That's the real challenge.
The takeaway for anyone listening who wants to try this is: the architecture supports it, the setting is at Settings, System, Languages and input, Voice input, and the apps that respect it are few but real. HeliBoard and FUTO are the names to know.
The deeper takeaway is that the confusion is structural. It's not you. It's the apps and the settings menu working together to hide a design that was actually pretty good.
Which leaves us with the open question. If local STT keeps getting better, does the pressure to decouple grow, or does the bundling just absorb the improvement and get stickier?
I don't know. But I suspect the answer depends on whether the open-source projects can keep the exit ramp alive long enough for the local models to mature.
Something to watch. Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the yellow paper diagram, which we may or may not ever see.
This has been My Weird Prompts. Check the show notes for the settings path and the HeliBoard and FUTO references.
Email us at show at my weird prompts dot com if you've got your own voice typing setup to share. We'll be back soon.
