Do Android keyboards log keystrokes locally or send them to servers?

1. Android’s baseline: system limits and the role of the IME (input method)

Android does not let background services arbitrarily intercept the default soft keyboard’s key events, so keylogging from a passive background app is not supported by the platform itself — the only legitimate path for per‑character capture is the input method editor (IME) that the user chooses to install and enable as their keyboard ^{[1] [7]}. Because keyboards are, by design, the component that receives what the user types, they inherently have access to text entered in other apps and can therefore log that data if programmed to do so ^{[2] [3]}.

2. Local logging: keyboards and dedicated “logger” apps that save to the device

Several projects and apps explicitly demonstrate local keystroke capture: open‑source malicious or proof‑of‑concept keyboards store keystroke logs on the device’s filesystem for later inspection ^[3], and legitimate‑looking utilities and accessibility‑style typing recorders advertise on‑device storage of captured text for recovery or analytics ^{[8] [9]}. Security writeups and practitioner guides treat local log files and accessibility abuses as common vectors for theft or accidental data exposure, and recommend switching to trusted keyboards and checking for unusual apps with input or accessibility privileges ^{[10] [2]}.

3. Remote transmission: cloud prediction and spyware dashboards

Not all keyboards confine data to the handset. Cloud‑based prediction systems send characters or fragments to vendor servers to power suggestions and language models — researchers found many IMEs that transmit pinyin or typed characters to cloud services and in several cases implement encryption poorly, exposing typed text during transit ^[4]. Commercial monitoring/spyware products explicitly promise remote dashboards where captured keystrokes are uploaded and reviewed remotely, meaning keystrokes move off the device and into operator servers once those apps are installed and granted the necessary permissions ^{[5] [6] [11]}.

4. Conflicting claims and platform defenses

Vendors offering defensive services sometimes claim Android “blocks keyloggers from accessing or transmitting user keystrokes” or that iOS enforces system keyboard usage to limit such capture, presenting a stronger protective posture than plain Android permissions imply ^[12]. That view competes with empirical research showing IMEs and some vendor keyboards do transmit characters for cloud prediction and that many third‑party monitoring packages openly upload captured keystrokes ^{[4] [5]}. The reporting provided does not authoritatively quantify how often each outcome occurs across the Android ecosystem, so claims of wholesale immunity should be treated as vendor marketing unless independently verified ^{[12] [4]}.

5. Practical takeaway and unanswered details

In practice, keystroke capture on Android is possible only through components the user enables (a third‑party keyboard or an app abusing accessibility/privileged features), and those components can either log data locally or send it to servers depending on their implementation and permissions ^{[1] [3] [9]}. Sources document both storage‑local and server‑based behaviours — researchers and offensive/defensive tool authors alike — but the provided reporting does not supply a landscape‑level measurement of prevalence, nor does it prove that stock system keyboards universally transmit keystrokes off‑device; that depends on the specific keyboard vendor and features like cloud prediction or remote monitoring services ^{[4] [2] [5]}.