Voice dictation sees a lot — here's exactly what betterflo does with it
The floating mic and the keyboard both sit in a text field to do their job. Here's what each actually reads, what it deliberately doesn't, and why password fields are a hard line.
- On-device ASR— shipped now
- Fitting the phone— shipped now
- Privacy by design— shipped now
- How we talk about it— later
15 June 2026
Any app that types for you has a strange amount of access, if you stop to think about it. It’s the thing standing between you and every text field on your phone — search boxes, chat apps, forms, banking logins. That’s true of a keyboard, and it’s just as true of betterflo’s floating mic, which is why we think either surface should be judged less by what it could see and more by what it chooses to do with it.
Here’s what betterflo actually looks at, on each surface.
The floating mic — the default way to dictate — inserts your text using an Android accessibility service. To put your words in the right place, it reads the field you’re actively dictating into: its content and where your cursor is. That’s a real capability, not a small one, and we’d rather say so plainly than let “on-device” sound like it means “can’t see anything.” It happens entirely on-device: the field’s content is used to place your text and then discarded — not stored, not logged, not sent anywhere.
The keyboard — now a keyboard in full, with a key grid, a suggestion strip and the mic beside the space bar — reads the field’s type (search box, email address, general text) and, where it genuinely improves accuracy, the text immediately around your cursor. That context is what lets the recognizer disambiguate a homophone or get an Indian name right instead of guessing at the nearest English-sounding word.
Since it types, it sees typing. That is what Android’s own warning about input methods means, and it is true of every keyboard you have ever used; the honest question is what the keyboard does with it. Here: the suggestion strip is matched against a word list that ships inside the app, and the action bar — Fix, Tone, Rewrite, Translate — reads the text you point it at, because rewriting a sentence you cannot read is not a thing software can do. That work runs on the phone. The rewrite comes back beside your own line and replaces nothing until you choose it, and if it comes back different from your text only in punctuation or capitalisation, the app drops it rather than dressing it up as a suggestion. None of it is stored, and none of it is uploaded.
Then there’s what neither surface does. Password and other secure fields are a hard boundary, not a setting you could accidentally leave off. The moment a field is password-class, the floating mic hides itself and the accessibility service doesn’t act on that node; the keyboard stops reading the surrounding text around it, keeps no log of it, and doesn’t feed it into anything that improves the product later — no exceptions carved out for convenience. You can still dictate into a password field if you choose to; the mic still works. What doesn’t happen is either surface treating that field like any other and remembering something about it. It’s a boundary enforced in the code that reads the field, not a policy we just promise to follow.
We built it this way because voice dictation has more reason than most apps to earn that kind of restraint. Typing is already something people trust their keyboard with by necessity; speaking adds your literal voice to that trust, and a floating mic that can read the field you’re in — over any app — is the permission that understandably worries people most. The honest response to “it can see what I’m typing” isn’t to pretend it can’t — it’s to be specific and conservative about which of the things it technically could see actually get used, to draw a line around the fields where the answer should just be nothing, and to say clearly that reading is not the same as sending.
That’s the distinction we’re careful to keep apart: “reads locally” and “sends off the device” are not the same claim. Betterflo reads what it needs, exactly where it needs it, to do the job you asked for — insert your dictated text or improve its accuracy — and it does not send that content anywhere by default, doesn’t read fields you’re not dictating into, and treats secure fields as off-limits by design rather than by promise. Either surface sees something because of where it sits. What it does with that access is the part worth being precise about — and the part we’d rather have you check than take our word for. See the accessibility-service disclosure for the exact, plain-language version we show before ever asking for that permission.