The keyboard a user types with on Android is itself an app, an input method editor, and it sees the keystrokes flowing through it, including in your app. Most people run a third-party keyboard, which means an app you do not control processes what users type in your fields, and a malicious or careless one could capture it. There are two sides to this: protecting sensitive input in your own app from being learned or logged by whatever keyboard is installed, and, if you build a keyboard, the heavy responsibility of holding everything users type. Here is how input method editors see input and how to handle both sides.
Short answer
On Android, the keyboard is an input method editor (IME), an app that processes the user's keystrokes, including in your app, so a third-party keyboard sees what users type in your fields. Per Android, you cannot control which keyboard a user runs, but you can protect sensitive input: use password input types for credential fields, which signal the field's sensitivity and mask it, and set the flag that disables personalized learning on sensitive fields so the keyboard does not learn or store the input. If you build an IME, you hold everything users type, a serious responsibility, so never capture or transmit keystrokes beyond what the feature needs, and follow Google Play's policy. Sensitive input should be marked so the keyboard treats it carefully.
What you should know
- The keyboard is an app (an IME): it processes the keystrokes it handles.
- A third-party keyboard sees your fields' input: you do not control which one.
- Use password input types for credentials: signals sensitivity and masks input.
- Disable personalized learning on sensitive fields: so input is not learned or stored.
- Building an IME is a heavy responsibility: you hold everything typed.
How do keyboards see your input?
Because the IME sits between the keystroke and your field. The table shows the two angles.
| Angle | Detail |
|---|---|
| Your app's fields | A third-party keyboard processes input typed into them |
| Personalized learning | Keyboards may learn from and store typed text |
| Password fields | Signal sensitivity; the system handles them specially |
| Building an IME | Your keyboard sees input across all apps |
| Keyboard with network access | A red flag for a keyboard that should not need it |
The mechanism is simple: on Android the keyboard is an input method editor, a separate app that receives the user's key input and provides the text to the focused field, so whatever keyboard the user has installed processes what they type in your app. Since most users run a third-party keyboard and you cannot dictate their choice, an app you do not control is in the path of your fields' input. Keyboards also often learn from typed text to power suggestions and autocorrect, which can mean storing input, and that is undesirable for sensitive content. The flip side is building your own IME: such a keyboard sees input across every app the user types in, which is why a keyboard requesting network access, when it has no legitimate need, is a classic warning sign for input capture.
How do you protect sensitive input in your app?
Mark sensitive fields so the keyboard treats them carefully. For credential fields, use the password input types, which both mask the input visually and signal to the system and keyboard that the field is sensitive, so it is handled with the special treatment passwords receive rather than as ordinary text. For other sensitive fields that are not passwords but should not be learned or stored, such as personal identifiers or one-time secrets, set the flag that disables personalized learning on the field, so the keyboard is told not to learn from or store what is typed there. These are signals to the keyboard rather than guarantees, since you do not control the IME, but they communicate sensitivity through the standard mechanism a well-behaved keyboard respects, and they are the right baseline. Combine this with not putting more sensitive input on screen than necessary, and with the rest of your data handling. The principle is to use the input-type and learning flags to tell whatever keyboard is in use that a field is sensitive, so a cooperating IME does not learn, store, or expose the input.
What if you build a keyboard?
Then you hold the highest trust, and the rules are strict. An IME you build sees everything the user types across all their apps, which is one of the most sensitive positions an app can occupy, so the responsibility is to never capture, log, or transmit keystrokes beyond what the keyboard's function genuinely requires. A keyboard should not be quietly sending typed text anywhere, and requesting network access or excessive permissions without a clear, disclosed need is exactly the pattern that marks a keyboard as a risk. Follow Google Play's policy for input method editors, which constrains how keyboards may handle and transmit user input, be transparent about any processing, and apply least privilege to permissions. If your keyboard offers cloud features, make them clear and consensual, and keep sensitive input, like content from password fields, out of any learning or transmission. The principle is that a keyboard is trusted with a user's every keystroke, so it must handle that input minimally, transparently, and within policy, never as something to harvest.
What to watch out for
The first trap is not marking sensitive fields, leaving credential or personal input as ordinary text a keyboard may learn and store; use password input types and disable personalized learning on sensitive fields. The second is forgetting a third-party keyboard processes your input, so client-side field handling is a signal, not a guarantee. The third, if you build an IME, is capturing or transmitting keystrokes or requesting network access without a disclosed need, which violates trust and policy. Field input types are set in your app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled APK or AAB against OWASP MASVS, assesses your app's data handling and, for a keyboard, its permissions, while the input-type flags and IME conduct are yours to implement.
What to take away
- On Android the keyboard is an input method editor, an app that processes keystrokes including in your fields, and a third-party keyboard you do not control is in the path of your input.
- Protect sensitive input by using password input types for credentials and disabling personalized learning on sensitive fields, signaling sensitivity to whatever keyboard is in use.
- If you build a keyboard, you hold everything users type, so never capture or transmit keystrokes beyond what is needed, avoid unnecessary network access, and follow Google Play's IME policy.
- Use a pre-submission scan such as PTKD.com to assess your app's data handling and, for a keyboard, its permissions, and set field input flags in your app.
