AnySoftKeyboard

An Android on-screen keyboard, Apache-2.0, described by its own repository as being for “multiple languages and NO internet access.” 3.3k stars, 930 forks, 8,986 commits on main as of 2026-08-09; the licence header carries a 2009 copyright in the name of Menny Even-Danan, which makes this the oldest continuously maintained project in the corpus by a wide margin. Minimum Android 6.0 (API 23). Distributed through both f-droid and Google Play, the latter with alpha, beta and stable channels and a gradual rollout.

The privacy claim is architectural, not a policy

Most software that promises not to misuse your data is promising restraint. An input method is the one component on a phone that sees every password, message and search before any application does, and the usual defence is a privacy policy — a statement about what the vendor chooses to do with what it receives.

AnySoftKeyboard’s claim is a different kind of claim: the keyboard has no network access at all. There is nothing to promise about transmitted data because nothing is transmitted. Its incognito mode extends the same logic locally — “will not learn new words, will not keep history of what was typed (including emoji history)” — so the second copy of your typing, the one in the personal dictionary, also stops existing.

That is the strongest form of the argument this spoke keeps meeting (foss-application): a guarantee that holds because the capability is absent, not because the operator is trustworthy. It is also the version that costs the user something concrete, which is the next section.

What the absence of a network costs

The features a cloud keyboard sells are exactly the ones that need a server or a large local model: cross-device sync of learned words, cloud-backed personalisation, and the very large next-word models that make modern prediction feel effortless. What is offered here instead is word suggestion, next-word prediction and auto-capitalisation computed on the device, gesture typing, voice input, dark mode with system detection, and layouts covering QWERTY, Dvorak, AZERTY, Colemak and Workman alongside Hebrew, Russian, Arabic and many more.

The language packs are separate installable applications, and that is the structurally interesting part. Rather than shipping every dictionary in one binary or fetching them on demand, the project pushes languages, themes and quick-text packs out to the add-on store as their own packages. It keeps the base install small without a download server, and it turns “add a language” into “install an app,” which is the sort of trade an offline-only design forces. The same pattern appears in termux‘s add-on apps, for a different reason.

What is not established

• Nobody has verified the no-network claim here. It is checkable — an Android application’s permissions are inspectable, and the source is public — but no audit, teardown or third-party review is held in this corpus, and the standing caveat in ../CLAUDE.md applies: this is the project’s own claim, recorded as such.
• Prediction quality against the cloud keyboards is unmeasured. No benchmark, no user study, no error-rate comparison. The trade being made is clear; its size is not.
• Play Store distribution is not examined. Both channels are offered without the README explaining what differs between them, unlike termux, which is explicit that its Play build is the inferior one.

Connections

Alongside termux (cross-wiki, osint-wiki) this is the corpus’s second Android FOSS application and the second to treat f-droid as a first-class channel. Both replace something the platform vendor supplies as a default — a keyboard, a shell — with a version the user installs deliberately. Substitution is the frame, but note that this one is not marketed against a named competitor. The README sells an absence rather than a replacement, which is the rarer move in this corpus. Compare hometube, whose privacy pitch is the same shape and whose dependencies undercut it.