When you enable a third-party keyboard, Android shows a warning that it "may be able to collect all the text you type, including personal data like passwords and credit card numbers". That dialog is accurate, it applies to every keyboard including Google's own, and most people tap OK without reading it. Here is what sits behind it.
What an input method is allowed to see
A keyboard on Android is an input method service. The app you are typing into hands it an InputConnection, which is a two-way channel. Through it the keyboard can:
- receive every key press, obviously, since it generates them;
- read text before and after the cursor in the current field, which is how autocorrect knows the word you just finished and how "undo" knows what to put back;
- read the field's type: plain text, email address, URL, number, date, password;
- read whether the app asked for no personalised learning, the flag browsers and messaging apps set for private modes;
- receive the clipboard's contents if it registers a listener, which is how clipboard history features work.
It cannot see other apps' screens, other fields, or anything in an app that is not currently accepting text. It is not a screen reader. But inside the field you are typing into, the keyboard sees what you see, and that includes the field with the dots in it.
The password field is a request, not a wall
A password field is marked by the app with a flag on the input type. Nothing in Android stops a keyboard from reading a field marked as a password. What happens next is entirely the keyboard's decision, made in its own code.
In FrankenKeys that decision is one class, FieldPolicy, and its table is the policy:
| Field kind | Suggest | Autocorrect | Learn | Suggestion bar shows |
|---|---|---|---|---|
| plain text | yes | yes | yes | words |
| person name | yes | no | yes | words |
| text with the no-suggestions flag | no | no | no | nothing |
| email address, including web email | no | no | no | nothing |
| URL | no | no | no | nothing |
| phone number | no | no | no | nothing |
| number, any variation | no | no | no | nothing |
| date, time, date-time | no | no | no | today and now chips |
| password, text or numeric | no | no | no | a Generate button only |
"Learn" is whether a committed word can reach the personal dictionary or the phrase model, and it is a yes only in the fields that suggest. The password row shows one button, which generates a password into the field; nothing on the bar reads out of it. The clipboard vault also refuses to capture while a password field is focused, and refuses any clip the source app marks sensitive, which is what password managers do.
The incognito flag overrides everything: when an app sets it, nothing typed is learned, no matter what the row above says.
What the permission list adds
The rules above govern what the keyboard does with what it sees. The permission list governs where it could send it. A keyboard with INTERNET and a policy like the one above is trusting you to trust the policy. A keyboard without INTERNET has taken the second question off the table: it can read the password field, like every keyboard, and it can send it nowhere, unlike most.
So the permissions a keyboard needs are short. Vibration, if it offers haptics. Microphone, if it offers voice typing and uses the system recogniser. That is the list a keyboard needs to be a keyboard. FrankenKeys holds those two, plus three that are not about you at all: a bind to Android's on-device AI service, Play Billing for the one-time unlock, and a private receiver permission the app uses to talk to itself. The full list with sources is one page over.
Anything beyond that, contacts, location, camera, network, is a feature decision, and the vendor should be able to say what feature. Some can. I went and read the reasons the larger vendors give in a separate post.
The part that is uncomfortable
I want to be plain about a thing this site could easily gloss. A keyboard that cannot reach the network can still be a bad keyboard for your privacy, if it writes what it learns to a file that some other app on the phone can read. FrankenKeys stores its learned words, phrase model and pinned clips in app-private storage, which Android does not let other apps read without root. The in-app Privacy page lists every such store, ten of them, with a wipe button beside each, and the class behind it is KnowledgeReport if you want to check the list is complete. The backup file you can export is readable JSON by design, so treat it as what it is: a copy of what the keyboard knows.
None of that requires trusting a server, because there is no server. But it does require the app to behave, and that is exactly why the build ships unobfuscated. A promise you cannot read is a promise.
The short version
- Any keyboard sees every key and can read the current field, password fields included. That is what the enabling dialog is warning you about.
- Whether it does anything with a password field is the keyboard's own code.
- Whether it could send anything is the permission list, enforced by the OS.
- FrankenKeys: a documented field policy, no learning in sensitive fields, and no network permission.
The system dialog is the only honest thing most people ever read about keyboards, and it is dismissed in under a second. I would rather it were longer.