Trime: the Rime input method engine for Android

What Trime solves, and who ends up using it

Android ships a small set of input methods. If your language is a Chinese dialect, or if your input style depends on a shape-based code table rather than pinyin, the stock keyboards have nothing for you. Trime exists to fill that gap. The README describes it as a frontend based on the RIME input method framework, written in Java and Kotlin with JNI, and calls it "a universal shape-based and phonetic-based input method platform". The history section is unusually candid about the origin: it started as a frontend for TaeRv Pinyin and was named the TaeRv Input Method, then became a platform for code tables such as Wu dialect, and later added Wubi and Liangbi. Version 3.0 is the current line, built on librime through JNI.

The audience follows from that history. This is not a keyboard for someone who wants a default pinyin experience with predictive emoji. It is for people who already think in terms of Rime schemas: a dictionary, a set of rules, and a configuration file that decides how keystrokes turn into candidates. Dialect users, Wubi and Liangbi typists, and anyone maintaining a personal schema on desktop are the natural users. The README's own framing, protecting the native language of various Chinese dialects, tells you the project optimizes for coverage of input systems rather than for polish of any single one.

How the Kotlin frontend and librime fit together

The architecture is a two-layer split. The Android side is Kotlin (the repository's primary language) and hosts the input method service, the keyboard UI, and the settings. The engine side is librime, the same C++ library used by Rime on desktop, reached through JNI. That is why the repository carries an app/src/main/jni directory, a CMake build, and a patches directory with a lua.patch applied to librime-lua dependencies during builds.

Because the engine is librime, the data flow is the familiar Rime one: schemas and dictionaries are read from a user directory, the engine composes candidates as you type, and the frontend renders them. Trime's own contribution is the Android integration, not the composition logic. The README's third-party library list shows what comes along for the ride: Boost, LevelDB, marisa-trie, darts-clone, glog, snappy, yaml-cpp, utfcpp, and OpenCC. OpenCC is the one worth noting for users, since it handles conversion between Traditional and Simplified Chinese, and the Makefile uses the opencc command to generate the Simplified Chinese string resources from the Traditional ones.

The practical consequence is that Trime's behaviour is largely librime's behaviour. If a schema works on desktop Rime, the engine side should understand it. What can differ is the frontend: keyboard layout, candidate bar, and how the app exposes configuration. The README does not document the configuration UI in detail; it points to the wiki instead.

Installing Trime from F-Droid or Google Play

For users, there is nothing to build. The README lists a stable channel on F-Droid and Google Play under the package name com.osfans.trime, a nightly channel on the GitHub releases page, and a canary channel in GitHub Actions. The stable release at the time of writing is v3.3.12, published on 2026-09-01, with a nightly build pushed on 2026-09-22.

After installing, you enable Trime as a system keyboard in Android settings and switch to it. The part that trips people up is dictionaries: Trime is an engine, and the README does not bundle a general-purpose schema description. It links a separate configurations repository, rimerc, for that purpose. Expect to import schema files yourself.

For developers, the build path is documented and explicit. Clone with submodules, then build. The README gives both a Makefile target and the raw Gradle command:

git clone [email protected]:osfans/trime.git
git submodule update --init --recursive

The Makefile shows what the convenience targets actually do. make debug applies the librime-lua patch and then runs :app:assembleDebug, and make release does the same with :app:assembleRelease. On Windows the README substitutes .\gradlew assembleDebug and .\gradlew assembleRelease. A release build needs signing information in a keystore.properties file:

storePassword=myStorePassword
keyPassword=mykeyPassword
keyAlias=myKeyAlias
storeFile=myStoreFileLocation

The README's troubleshooting section names one concrete build error, a CMake message about Target "boost_log_setup" linking to Boost::coroutine, and prescribes make clean on Linux or macOS, or .\gradlew clean on Windows. It also notes that Windows developers need Developer Mode enabled for symlinks, or git configured with core.symlinks true, though it adds that copying is used instead when symlink creation fails.

Where Trime is the wrong tool

The biggest limitation is stated by the project's own structure rather than its README: Trime is a platform, and a platform without content is an empty keyboard. If you install it expecting usable Chinese input immediately, you will be disappointed. The README sends you to rimerc for configurations, and the wiki for documentation, which means the onboarding path runs through repositories and pages outside the app.

A second limitation is build weight. The requirements list Android SDK, Android NDK, OpenJDK 17, and Python 3 for OpenCC dictionary generation. That is a native toolchain, not an Android Studio project you can open and run. The troubleshooting section's advice, clean, update submodules, make a new clone, check issues, is the advice of a project where build failures come from dependency state rather than from your code.

Third, the release channels are not equivalent. The README offers stable, nightly, and canary. Nightly builds are produced continuously; the one listed here was pushed on 2026-09-22, one day before the stable line's most recent push. If you want reproducibility, the stable channel is the only defensible choice.

Finally, consider the maintenance model. The repository has not been archived and its last push was on 2026-09-22, but the README names a single developer, osfans, alongside a list of contributors and community channels on QQ, Telegram, Tieba, and the issue tracker. Support is community-shaped. If you need a vendor to answer within a service window, this is not that product.

Trime against a stock Android IME and against desktop Rime

The obvious alternative is whatever keyboard came with your phone. Gboard and the Android Traditional Chinese IME support pinyin and handwriting, and they work without configuration. The difference is control. A stock IME decides which input systems exist; Trime lets the schema decide. If your input system is not one of the mainstream ones, the stock keyboard cannot be extended, and Trime can.

The more interesting comparison is desktop Rime. Both use librime, so the engine behaves the same way, and schemas are portable in principle. The difference is the frontend and the surrounding environment. On desktop you edit YAML files directly and rebuild the deployment from a menu. On Android, Trime mediates through an app, with its own settings surface and its own file locations, and the README does not document that mediation in detail. The Makefile's translate target, which runs opencc -c tw2sp to generate values-zh-rCN strings from values-zh-rTW, is a reminder that even the app's own localization is derived rather than hand-maintained.

A third point of comparison is the legacy codebase. The README points to trime-legacy for the 2.0 line. That is a different project with a different architecture, and it exists because the 3.0 rewrite moved the engine to librime. Anyone with an old configuration should check the wiki rather than assume a drop-in path.

Licence, upgrade cost, and what the repository actually promises

Trime is GPL-3.0, and the README's SPDX headers use GPL-3.0-or-later. That matters if you plan to redistribute a modified build: the copyleft terms travel with the code. The bundled third-party libraries carry their own terms, which the README lists individually, including Boost Software License, New BSD, LGPL for libiconv, Apache 2.0 for OpenCC, and BSD for RIME itself. If you ship Trime inside a product, the LGPL component is the one to examine first. This is a description of what the repository states, not legal advice.

Upgrade cost is real but bounded. The project publishes stable releases at a slow cadence: v3.3.11 on 2026-07-01, v3.3.12 on 2026-09-01. The nightly channel moves faster and is regenerated continuously. For a user, upgrading is an app update, and the risk is that a schema stops loading after an engine change. For a developer, upgrading means re-syncing submodules, since librime and its dependencies are pinned as submodules and the Makefile applies a patch on top. The README's troubleshooting list, update the repo, check that modified submodules are compatible with the current version, is effectively the upgrade procedure.

There is no documented rollback path in the README. If a nightly build breaks your setup, the README does not describe a downgrade procedure, so keeping the stable release available is the practical safeguard.

Editorial conclusion

Adopt Trime if you already use Rime on the desktop, want the same schemas on Android, and are comfortable installing dictionaries into the app's user directory. Do not adopt it if you expect a working Chinese keyboard out of the box or if you need a vendor to support you; the README points to the wiki, issues and community groups instead. Before committing, verify that your schema's dictionary files load on the current v3.3.12 release, and check whether the nightly channel is acceptable for your device.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. osfans/trime on GitHub
3. Project website
4. README
5. Releases