Xime: a Wubi-first Rime keyboard for Android with Lua plugins and bundled speech

librime behind JNI, with Jetpack Compose drawing every key

Xime solves one narrow problem: typing Chinese on a phone when you already know Wubi. Its one-line summary calls it the author's own Android input method, built on Rime, with some features driven by local AI models designed in house. Almost every design choice follows from that one sentence. The engine is librime reached through JNI to native C++, the interface is Kotlin with Jetpack Compose, and the visual layer is Material Design 3 with light and dark themes and several color schemes. The stated floor is Android 9.0 (API 28), which matters because a keyboard is the one app you cannot work around when a system blocks sideloading.

That split carries an architectural cost. Drawing, theming and gesture handling live in Compose, while candidate conversion, dictionary lookup and schema switching stay inside librime, so any change to the conversion pipeline crosses a native boundary rather than staying in Kotlin. The top-level tree mirrors the division. plugin-core/ and plugins/ carry the extension machinery, tools/ and scripts/ hold build helpers, and web/ sits beside app/ for the documentation site at ime.ximei.me. Nothing in the tree points at a server component, so the app ships with its own engine and loads its own data.

Four APK architectures decide which download you install

Installation is a download rather than a package manager entry. The installation section gives no shell command at all; the only decision is which APK matches your device. Four architecture labels cover the cases: `arm64-v8a` for modern phones, which the project calls recommended for most users, `armeabi-v7a` for older 32-bit phones, `x86_64` for emulators, and `universal` for every CPU at the cost of a larger file. Match on processor rather than screen size, and reach for the universal build only when you are unsure.

Once the file installs, the sequence is the ordinary Android input method handshake: enable Xime in the system input method settings, then set it as the current input method. Both the downloaded path and the source path end on those same two steps, and neither asks you to write a schema file before the first keystroke. That last point is unusual for an Rime-based keyboard, where schemas and dictionaries are normally the thing you maintain by hand.

The F-Droid listing identifies the package as `com.kingzcheung.xime`. Checking that identifier before you install keeps an APK repackaged by some other mirror off your phone, which carries more weight here than for an ordinary app, because whatever holds the keyboard role reads every character you type.

Submodules decide whether the gradlew build finds the engine

Source builds go through Gradle, and the first real obstacle is the recursive clone. Oddly, the Build from Source steps in the installation section name four operations without giving a command for any of them. The commands sit further down under a separate Building heading:

# Clone with submodules
git clone --recursive https://github.com/ximeiorg/Xime.git

# Or initialize submodules in an existing clone
git submodule update --init --recursive

# Build Release APK
./gradlew assembleRelease

The `--recursive` flag is not decoration. A `.gitmodules` file sits at the top level of the tree, so a plain clone leaves those directories empty and `./gradlew assembleRelease` then builds against a workspace missing whatever the native side expects to find. Both commands carry the flag, which reads as the project's own warning that skipping it is a mistake somebody has already made.

When the build finishes you install the resulting APK and repeat the two enablement steps from a downloaded build: switch Xime on in the system input method settings, then make it the current input method. A `gradlew.bat` and a `run_tests.sh` sit at the top level as well, so Windows developers and anyone wanting a test entry point are served by the same clone. What the README does not name is a Gradle version, a JDK version or an Android SDK level for building, so pin those first when your build fails.

The author's AI models live in sibling repositories, not this tree

Read the summary line and you expect model code here, because it credits local AI models designed by the author. The tree does not contain any. There is no models directory among the top-level entries, and the row of project links above the feature list sends you elsewhere: a Predictive Text Model and a Handwriting Model, each pointing at its own ximeiorg repository, plus a separate AI Models List page at ime.ximei.me/model-list.html as the model catalogue. Nothing in this repository builds those weights.

The split matters before you install. Speech recognition is not part of that sibling pair. Voice input is described as a built-in streaming zipformer2 engine running offline, while online speech recognition arrives through plugins, funasr-asr for Alibaba Bailian and volc-asr for Volcano Engine. So the APK carries one neural model inside it and reaches two others over a network, through the extension store.

Predictive text is called transformer based, and it is the piece readers assume is bundled. On this evidence it is not: the transformer sits behind the predictive-text repository, and the model list page is where download choices would live. Check that first after a fresh install, because a feature listed as AI enhancement can quietly depend on a file you never fetched.

Lua plugins arrive as xipk files through an Extension Store

The extension mechanism is the least conventional part of the app. Plugins are Lua scripts packaged in a `.xipk` format, installed and enabled from Settings > Extension Store, and the shipped set mixes utility with novelty in one list: kaomoji for emoticons, xime-fluent-emoji with 222 curated 3D emojis across 9 categories, webdav-clipboard-sync and ximed-clipboard-sync for clipboard transfer, funasr-asr and volc-asr for online speech, plus meme-bunny, described without irony as a funny bunny sticker pack of 8 stickers.

Two details sit oddly together. The screenshot gallery shows a Plugin Manager and an Extension Store as separate screens, so switching what is enabled and discovering what exists are two different surfaces in the app. And a Lua runtime inside a keyboard occupies the same process as the component receiving every character you type, yet the README does not describe signing, review rules or permission prompts for what the store will accept. That gap is worth resolving before you install a third-party plugin, because the plugin list also points at a Plugin Center page online where the full catalogue lives.

Wubi shapes the defaults while Pinyin shapes the prediction model

The README is blunt about its bias: the author mainly types Wubi with Pinyin as a fallback, so resources lean toward Wubi. You can see the result in the built-in schemas, Wubi 86/98, Pinyin and mixed, with anything else, Shuangpin or Stroke for instance, arriving through the schema marketplace or wireless import rather than shipping inside the APK. Two learning aids point at the same reader: candidate coding hints that show the Wubi code under each candidate, and a swipe down on any key that reveals its radical.

The Pinyin side is not simply the leftover. Layouts cover a QWERTY full keyboard, T9 Pinyin, a stroke nine-key board, handwriting with a candidate view, a numpad with a calculator, a symbols page, an emoji keyboard, and a floating card that can be dragged around the screen. Hardware and Bluetooth keyboards get a floating candidate bar instead of the full board, and the toolbar buttons can be rearranged, with adjustable sound and vibration intensity.

The tension worth naming is that prediction is the feature most useful to the fallback user. The entry says transformer based predictive text for faster input and never says which language or schema mix the model was trained for, while the carefully built resources, radicals, coding hints and the plugin store, all serve the primary schema. A Pinyin-first user inherits a large Wubi investment and one unspecified model.

Two WebDAV routes carry clipboard history and schema files

WebDAV appears twice in the feature list, doing two unrelated jobs, and the difference matters when you decide what to send off the device. One entry is clipboard sync, described as bidirectional, so clipboard contents travel between your phone and a remote device, with a history, quick send and pinning kept inside the app. That path is plugin territory: webdav-clipboard-sync and ximed-clipboard-sync are the two named plugins, and the second routes the same function through a ximed service rather than a server you run.

The other entry needs no plugin. Schemas and settings are backed up and restored over WebDAV as a built-in feature, which is the one thing worth configuring before you start authoring a personal schema. Nothing here names a host, an account flow or an encryption setting for either route, so the defaults are not something you can read before the first sync.

Because a keyboard owns the clipboard by definition, treat the clipboard plugins as the higher exposure of the pair. A schema backup sends your dictionaries and configuration. A clipboard sync sends whatever you copied that day, which on a work phone can include one-time codes and internal addresses.

Thin documentation and a personal codebase set the ceiling

Most of what users ask about sits outside this repository. The documentation is a site at ime.ximei.me with four pages, an FAQ, a Rime Schemas List, a Plugin List and an AI Models List, and the README itself is a landing page that stops mid-link inside its acknowledgments after crediting Rime as the input method engine and naming Trime. Schema configuration and day-to-day troubleshooting therefore have to be looked up online, and the README does not document how to roll back to a previous APK.

Alternatives exist, and the differences are concrete. The same author maintains a Windows build in the winxime repository and a Linux build in xime-wayland; both are desktop input stacks with no Android IME service to register, no Extension Store and no clipboard service, so the same engine thinking lands on a different host contract. Trime, the other Android front end the acknowledgments name over the same engine, receives no comparison at all here, and the entry is cut off mid-link, so any claim about which front end to pick has to be made on a device rather than from documentation.

The remaining check is practical. With every listed build on a v3.0.0 beta tag, dated 2026-09-25, 2026-09-26 and 2026-09-27, and the last push landing on 2026-09-28, the code is moving faster than the documentation. Under GPL-3.0 you can read, build and redistribute the app, with the usual obligation to keep derived work under the same terms.

Editorial conclusion

Adopt Xime if you type Wubi daily and want your own schemas, Lua plugins and offline speech on Android without maintaining an input method yourself, and read its Extension Store as a second decision point, because a plugin shares a process with the component that sees every character you type. Do not expect a settled channel: every listed build is a v3.0.0 beta, so keep the old APK before switching. Verify first that the models on ime.ximei.me/model-list.html cover your schema, since predictive text is not bundled in this repository.

Frequently asked questions

Official sources

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