AnySoftKeyboard: an offline Android keyboard whose languages ship as add-ons

Installing from F-Droid or a Play Store channel, not from source

There is no build step in the README, because this is an Android app distributed through stores rather than a library you compile. The README carries a Google Play badge and an F-Droid badge, and the application id in both links is `com.menny.android.anysoftkeyboard`. The support floor is stated plainly: Android 6.0 and above, API level 23 and up.

That floor is worth reading as a maintenance signal rather than a limitation. Android 6.0 dates from 2015, so the project is still choosing to support nine-year-old devices, and it does so without appearing to trade away current Android behaviour. The 1.13 release notes mention support for Android 15 16KB memory pages, which is a forward-looking detail: 16KB page support is the kind of change that breaks apps on new Android versions if nobody addresses it, and this release notes list says it was addressed.

The distribution model has three channels and the README documents each one, which is unusual and useful. Every commit to `main` deploys a new release to the ALPHA channel on Google Play. Every Wednesday the latest ALPHA is promoted to BETA. Once release requirements are met, a STABLE release branch is cut in the format `release-branch-ime-vX.X-rX`, and every commit to it is published to the STABLE channel with a gradual user roll-out.

So subscribing to the beta channel is a two-step affair: join the Google Groups alpha-testers group, then opt in through the Play testing link. That is a deliberate funnel, and it is the reason a keyboard app with a large user base can ship gesture-typing changes without waiting for a yearly release cycle.

Language packs, themes and quick texts as separate installable units

The most distinctive decision in the project is that content is separated from the keyboard. The README lists three add-on families with their own pack index files: `addons/languages/PACKS.md` for language packs, `addons/themes/PACKS.md` for themes, and `addons/quicktexts/PACKS.md` for quick-text expansions. The repository tree confirms the shape, with an `addons/` directory alongside `ime/`, and separate release branch naming for each: `release-branch-ime-vX.X-rX` for the keyboard itself and `release-branch-addons-vX.X-rX` for the content.

The payoff is visible in the language list. English alone ships in QWERTY, Dvorak, AZERTY, Colemak and Workman layouts, and then there are Hebrew, Russian, Arabic, Lao, Bulgarian, Swiss, German, Swedish, Spanish, Catalan, Belarusian, Portuguese and Ukrainian, with a link to the pack index for the rest. Arabic and Hebrew are the reason a general-purpose keyboard exists at all here, since neither has a comfortable stock Android layout.

The genuinely unusual capability is word list mixing. The README says external packages include word lists that can be freely mixed, and offers the example directly: a French layout with suggestions for German and Russian. Standard Android keyboards tie suggestions to the input language, so this is a different model of what a keyboard does. You choose a layout for the keys you want and separately choose dictionaries for what it suggests, which is more useful for a multilingual typist and more work to configure.

There are also dedicated keyboards for narrow fields: one for text fields requiring only numbers, and one for email or URI addresses. Physical keyboard support is listed as well, and the feature list rounds out with auto-capitalization, next-word suggestions, customizable or fully disabled automatic correction, gesture typing, dark mode following the system or set manually, a power saving mode, per-app tinting, key-press sound and vibration, and voice input.

Incognito Mode as a switch rather than a design

The repository description reads Android on screen keyboard for multiple languages and NO internet access. Both halves matter, and the second one is the claim most people shopping for a keyboard will care about.

The README backs the no-internet claim with a feature rather than an architecture note: Incognito Mode, which will not learn new words and will not keep history of what was typed, including emoji history. That is a well-scoped promise about retention rather than about the network, and it is the right scope for a keyboard, because what a keyboard accumulates is the user's text.

The limitation is in the design. Incognito Mode is something you turn on. A keyboard whose default behaviour learns new words and keeps a typed history is a different proposition from one that never does, and the README lists it among the features rather than describing it as the default. A reader assessing privacy has to notice the feature and enable it, rather than confirm it is on by default. The emoji keyboard behaves the same way, with its own history cleared under the same switch.

That said, the add-on model introduces a question the core project cannot answer for you. Because word lists, themes and quick texts are separate packages, each one is a separate thing you install, and the README's pack index is where you find out what a given pack contains. The README does not make claims about what third-party packs transmit, and the no-internet statement describes the keyboard. Anyone treating this as a privacy decision rather than a typing preference should read the pack list before installing, not after.

One more detail is easy to miss and relevant to anyone who has used a stock keyboard: the emoji set is customized through a Settings icon inside the emoji window, and long-pressing the smiley key opens it. That is a small thing, but it means emoji configuration happens in the keyboard rather than in a system settings screen.

How a version travels from main to F-Droid

The README documents its own release process, and the documentation is specific enough to be checked against reality. Cutting a release branch from `main` uses the naming format `release-branch-ime-vX.X-rX`, or `release-branch-addons-vX.X-rX` for the content packs. Then you bump `minor` in `ime/build.gradle` or `addons/build.gradle` and update `patchOffset` by appending the last patch number of the previous release to reset the counter. Then you update `refname` in the matrix strategy inside `.github/workflows/deployment_promote.yml` so the workflow targets the new branch. Finally you open a pull request against the new release branch base.

Once the branch exists, the roll-out is automatic and graduated. Each new commit goes to 10% of users. Each day, if no new commit was pushed, the percentage increases. When roll-out reaches 100%, an F-Droid release is made. That is a slower, more conservative pattern than publishing to a store directly, and it is the standard answer to the problem of shipping a keyboard to a large installed base where a bad gesture-typing change would affect everyone at once.

The releases themselves carry a wrinkle. v1.13-r1 from 2026-02-08 and v1.13-r2 from 2026-09-08 have identical body text: gesture-typing accuracy and performance improvements, Android 15 16KB memory page support, updated emojis for Android 15 and up, a fixed emoji keyboard crash, better edge-to-edge support, the Android 6.0 API 23 minimum, bug fixes, YABTU, and updated translations. Both point at the same milestone, number 95. The earlier release notes for v1.12-r1 do add the detail that r2 omits, including clipboard support improvements, Direct-Boot device support, a reduced installation size for supporting devices, and a note that translations come from the community via crowdin.net.

So read the milestone rather than trusting the release body when you need to know what changed between two 1.13 builds. The v1.13-r2 body is a summary of the milestone, not a diff against v1.13-r1.

Bazel, Gradle and a Node tooling layer inside an Android app

The repository is Java, and it carries two build systems plus a JavaScript toolchain. The tree has `BUILD.bazel`, `WORKSPACE.bazel`, `WORKSPACE.bzlmod`, `MODULE.bazel` and `MODULE.bazel.lock` at the top level alongside a `.bazelrc` and `.bazelversion`, which is Bazel with bzlmod enabled. It also has `build.gradle`, `settings.gradle`, `gradle.properties`, a `gradlew` wrapper and `gradlew.bat`, so Gradle is present too. And there is a separate Node layer with `package.json`, `pnpm-lock.yaml`, `tsconfig.json`, `eslint.config.mjs` and a `.nvmrc`.

That Node layer is worth a close look, because `package.json` does something unusual. The build and test scripts are stubs, deliberately failing rather than doing anything:

"scripts": {
    "build": "exit 1",
    "test": "exit 1"
  }

What the file really configures is tooling. It pins the package manager and the Node floor, with a pnpm-only build policy:

  "engines": {
    "node": "^24.1.0"
  },
  "pnpm": {
    "onlyBuiltDependencies": []
  },

The dependency list explains what that tooling is for. `@actions/core` and `@actions/github` are GitHub Actions libraries, and `@langchain/core` and `@langchain/google-genai` are present alongside them. Then come `fast-xml-parser`, `js-yaml`, `follow-redirects`, `tar`, `commander` and `undici` for network, archive and parsing work, plus `typescript`, `eslint`, `prettier` and their plugins for the repository's own linting and formatting. So the Node code appears to be automation that runs in CI, not an application runtime.

The presence of `.devcontainer/`, `mise.toml`, `CLAUDE.md`, `AGENTS.md`, `.claude/`, `.gemini/` and `.jules/` is worth noting too. Several of the top-level dotfiles exist to instruct coding agents, and `mise.toml` suggests a tool version manager is the intended way to get the required Node, Java and pnpm versions in place before you build anything. If you want to work on the keyboard itself rather than its automation, `ime/` is the directory to open, and `CONTRIBUTING.md` is the file the README points you at first.

Apache 2.0 with a copyright assignment clause

The licence is Apache License 2.0, copyright 2009 Menny Even-Danan, and the README quotes the standard grant. What the README adds is a requirement that changes the character of a contribution. The Copyright requirement section says the components in this repository are released under the Apache2 licence and that by contributing you give all copyright and distribution rights to the AnySoftKeyboard maintainer, linking to the maintainer's profile.

That is a real constraint and it is not hidden in a separate legal document. Apache 2.0 on its own permits proprietary derivative works, whereas an assignment of all copyright and distribution rights to a single maintainer means the project can relicense contributions at their discretion and cannot accept a contribution that arrives with incompatible terms. Contributors are also pointed at `CODE_OF_CONDUCT.md`, and there is a `CONTRIBUTORS.md` alongside `issue_template.md` for the issue template and a `.github/` directory for workflows.

For language pack authors this is the part to read first. Writing a Hebrew, Lao or Bulgarian pack is exactly the kind of contribution this project is built on, since the add-on model depends on people writing them, and the pack index at `addons/languages/PACKS.md` is where the existing ones are listed. The trade is that your pack ships under a licence whose terms flow to one maintainer. A translator working through Crowdin is in a similar position, and the README links the Crowdin project directly for that.

The project also links a web site at anysoftkeyboard.github.io as its main site, and points readers at GitHub Discussions rather than an issue tracker alone. It maintains a Mastodon account at hachyderm.io/@anysoftkeyboard for announcements. Anyone looking for maintainer background will find more in `CONTRIBUTORS.md` and `CONTRIBUTING.md` than in this README.

Editorial conclusion

AnySoftKeyboard is worth a look if you type in a language the stock keyboard does not cover, or if you want suggestion word lists that can be mixed across layouts, since mixing a French layout with German and Russian suggestions is exactly what the add-on model enables. The trade-offs are concrete. Incognito Mode exists rather than being absent, so the privacy story rests on turning it on, and the repository description's no-internet claim describes the keyboard rather than auditing every add-on you install. The install path is a store listing, not a build, so the last release v1.13-r2 of 2026-09-08 with its Android 15 16KB page support and API 23 floor is what you would actually install. Anyone wanting to modify the keyboard starts in `ime/`, reads `addons/languages/PACKS.md` to see the pack format, and reads `CONTRIBUTING.md` before a first pull request, since contributions transfer copyright to the maintainer.

Frequently asked questions

Official sources

1. AnySoftKeyboard/AnySoftKeyboard on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases