Glossary

The words this documentation uses, defined once.

Every other page defines its own jargon on first use, then leans on this page instead of repeating itself. If a term shows up here, its full write-up (with screenshots, settings, and edge cases) lives on the guide page linked from that entry.

Keyboard and input basics

IME

IME stands for input method editor, Android’s umbrella term for any keyboard app, WM Keyboard included. Concretely, it’s WMKeyboardService: the background service Android hands text-field focus to whenever you tap into one, and the thing every other term on this page is a piece of. It’s declared direct-boot aware in the app manifest, which matters enough to get its own entry below.

Subtype

Subtype is Android’s own term for one entry in its system-wide “Choose input method” sheet. WM Keyboard registers one InputMethodSubtype per enabled layout, each carrying the layout’s language tag and a stable id derived from the layout id itself, so a layout keeps the same subtype identity across restarts and app updates. The app’s own activeLayoutId stays the source of truth; the OS subtype is mirrored to match it, and a switch made from Android’s own sheet is followed back the other way. Whether your layouts show up as subtypes at all is WM KeyboardLanguagesSystem language switcherList languages in Android's switcher (on by default); a companion Show app name first toggle (off by default) prefixes the subtype label with “WM Keyboard · ” instead of leaving it as the plain language name. See Switching languages for the full picture, including the three other ways to switch that don’t touch Android’s subtypes at all.

Composing text

Composing text is the standard Android concept of text that’s been typed but not yet committed to the field: tracked internally as a buffer that gets pushed to the field with each keystroke and flushed once you move on. What it actually holds depends on which composer is running:

Latin-script typing — the word currently in progress, feeding the suggestion strip’s completions and corrections.
Avro (Bengali phonetic) — the romanized source you typed, not the Bengali output, and it can’t be reversed back into it; the fixed-Bengali layouts keep no composing buffer to resume at all.
CJK conversion — the untransliterated reading (pinyin syllables, kana, a stroke code) until you pick a candidate. See Chinese, Japanese & Korean.

Candidate bar

The horizontally scrolling row of ranked character or word candidates that a CJK conversion composer (Pinyin, T9 Pinyin, Zhuyin, Cangjie, Cangjie Quick, Stroke, Jyutping, or any of the Japanese schemes) shows in place of the ordinary suggestion strip whenever its composing buffer isn’t empty. Candidates pack left-aligned and sized to their text rather than spaced evenly; a chevron opens an expanded, wrapping grid. How deep that grid goes depends on the scheme. See Lattice below. Full detail, including the tap-to-commit flow, is on Chinese, Japanese & Korean → The candidate bar.

Addons and plugins

Addon

The umbrella term for any of the eleven kinds of content you can install into WM Keyboard: themes, layouts, dictionaries, emoji keyword packs, snippet packs, sticker packs, icon packs, fonts, emoji fonts, key sounds, and plugins. You install one from a repository (a small JSON index) by adding its URL; the file you download is in exactly the format the app’s own export already produces, so there’s no packaging, signing, or build step involved. With one exception, an addon is inert data: nothing runs when you install or use it. See What are addons? for the full type table, size limits, and trust model.

Plugin

The one addon type that isn’t pure data: a plugin is a small Lua script, sandboxed so it has no key-event API, no field-read API, no clipboard API, no network or file access, and no way to see another app or the device beyond its own on-device storage. It draws its own toolbar panel and only runs while that panel is open. Two rules apply to plugins that don’t apply to the other ten addon types: a plugin must publish a checksum or the install is refused before any network call happens, and a plugin installed from a repository always lands switched off rather than running immediately. Installing is refused outright if WM KeyboardToolsPluginsAllow plugins is off (off by default), a separate setting from the Plugins toolbar tool, which only controls whether a Plugins panel appears on the toolbar, not whether plugins are allowed to run. See WM Keyboard plugins.

Editions and storage

Flavor / edition

WM Keyboard ships as two Gradle build flavors (full and lite) from a single flavor dimension that flips five build flags on or off together (ML Kit handwriting, ML Kit scanners, grammar checking, the local LLM, and offline Whisper). “Edition” is the word this documentation uses for the same thing; “flavor” is the Gradle-level name developers use. Lite hides exactly five toolbox tools (Handwriting, Text scan/OCR, QR & barcode scanner, Document scanner, Grammar check) and two nested options Full edition only inside tools that exist on both editions (Whisper’s engine choice inside Voice typing, and the on-device LLM choice inside AI writing tools). Both editions share a package name and signing config, so installing one over the other is a normal update with your data intact. Measured release APKs run about 65 MB for Full and 15 MB for Lite. Check which you have at WM KeyboardAboutAppVersion, which names the flavor directly. Full comparison: Full vs Lite.

Direct boot

The window between the device powering on and you entering your PIN, pattern, or biometric for the first time since that boot. During it, credential-encrypted storage (the app’s normal filesDir, its settings DataStore, learned words, clipboard, snippets) simply can’t be read; touching it throws. WM Keyboard declares itself direct-boot aware specifically so Android doesn’t swap in a different keyboard during that window, since you need a working keyboard to type your own unlock PIN. The single gate is whether the OS reports the user unlocked, which defaults to unlocked if the platform has no concept of it at all. What runs in that window is deliberately narrow: appearance and behavior settings (layout, theme, sizing, sounds) are mirrored into a separate, non-credential area of storage on every change so they’re available from boot, with API keys and tokens filtered out of that mirror; personal stores like your learned words, clipboard, and snippets simply run memory-only and discard anything written until you unlock, rather than merging it in afterward. Bundled dictionaries are inflated into that same pre-unlock area once and serve both states; downloaded or imported dictionaries stay credential-only. 37 of the app’s 62 tools work during this window. See The toolbar for which. Don’t confuse this with the lock screen: a phone unlocked once since its last reboot counts as “unlocked” here even if you lock the screen again immediately after. That’s a separate concept covered on Incognito & secure fields. Fuller mechanics: Your data on device and the architecture notes.

CE / DE storage

Credential Encrypted and Device Encrypted are Android’s own platform shorthand for the two storage areas direct boot splits behavior across, but you won’t find those initialisms used literally anywhere in this codebase or its other pages. Both consistently spell them out instead: “credential-encrypted storage” for the normal, PIN-protected area, and “device-protected storage” for the small area readable from boot. If you’ve seen those phrases elsewhere in these docs, this is the platform vocabulary they map to.

The prediction vocabulary

Trie

A prefix tree used for word completion, behind a shared read-only interface (WordSource). The mutable, node-based Trie holds words learned at runtime, your personal vocabulary. Everything else uses the same immutable, flat-array layout instead, in two forms: an in-heap PackedTrie for imported word lists, and a memory-mapped MappedTrie that reads straight off a compiled .wmdict file with no heap footprint at all. That’s what backs the bundled dictionary and anything downloaded. The flat-array layout is what cuts retained memory for the ~17K-word bundled English word list roughly sevenfold (about 6.5 MiB down to well under 1 MiB) versus the node-based version; the memory-mapped form goes further still, since it’s never loaded onto the heap in the first place. All three return identical query results. See Suggestions & prediction and Downloadable dictionaries.

Bigram

A learned pair of words (the one you typed, and the one you typed right after it) used to predict what comes next. Your own bigrams accumulate as you type and are stored alongside your personal word list; a small bundled set of common English word-pair frequencies fills next-word prediction from your very first keystroke, before you’ve typed enough for your own history to take over, and your own bigrams always outrank that bundled set once they exist. WM KeyboardPrivacyYour dataClear learned words wipes both your learned words and your learned bigrams at once. See Suggestions & prediction and Your data on device.

Lattice

The shared decoder behind every CJK conversion scheme except the code-table ones. Given a composing buffer already split into reading units, it scores whole candidate paths through the buffer rather than ranking prefixes longest-first, so a shorter first word that leaves a better remainder can outrank a longer one, which is what makes committing a whole sentence with repeated space presses work. Pinyin, T9 Pinyin, Zhuyin, Jyutping, and the Japanese schemes all use it, which is why they can rank candidates up to 100 deep. Cangjie, Cangjie Quick, and Stroke skip it entirely: they map a shape or stroke code to exactly one character through a fixed lookup table instead, which is also why their candidate lists cap out at 24. See Chinese, Japanese & Korean.

Details & edge cases

Toolbar vs. toolbox. The toolbar is the strip of tools you’ve pinned; the toolbox is the grid behind the toolbar’s grid button, holding every other enabled tool that isn’t pinned. A tool lives in exactly one of the two at any given moment, never both. See The toolbar.
“Unlocked” means storage, not the lock screen. Direct boot’s notion of unlocked tracks whether credential-encrypted storage has been decrypted this boot, which happens once and stays true even if you lock the screen again afterward. The lock-screen-specific behavior (what typing does while the device is actually locked right now) is a distinct setting covered on Incognito & secure fields; don’t conflate the two.
CE/DE is platform vocabulary, not this codebase’s. If you go looking for the bare initialisms in the source or elsewhere in these docs, you won’t find them. See CE / DE storage above for the phrases actually used.
Composing text has no single shape. What it holds (a word in progress, a romanization that can’t reverse, or an untransliterated reading) depends entirely on which composer is running. Composing text above covers the three flavors; each language page covers its own in full.