BiBi Keyboard: an Android IME that routes speech through 18 ASR backends
说点啥（BiBi Keyboard）:一个基于 Kotlin 的 Android 平台的 LLM 与 ASR 语音输入法键盘应用 An LLM ASR voice input method keyboard application for the Android platform based on Kotlin
At a glance
- What is it?
- BiBi Keyboard is a Kotlin Android keyboard that treats speech recognition as a swappable backend rather than a fixed feature. The README lists 18 ASR providers, six of them on-device, plus LLM post-processing and a floating-ball mode for use inside other keyboards. The trade-off is that most of its accuracy depends on keys you supply yourself.
- Who is it for?
- Adopt BiBi Keyboard if you already hold an API key for a cloud ASR provider and want a voice-first keyboard on Android 8.0 or later, or if you want a fully offline path through the sherpa-onnx local models. Skip it if you expect a keyboard that works well before any provider configuration, or if you cannot grant overlay, accessibility, or LSPosed permissions on a managed device.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap BiBi Keyboard fills: speech as a provider, not a feature
Most Android keyboards bundle one recognition engine and expose no choice about it. BiBi Keyboard inverts that. The README describes "18 个 ASR 供应商（12 个云端 + 6 个本地）", which is 18 ASR providers split into 12 cloud and 6 local. The named local models are SenseVoice, FunASR Nano, Qwen3-ASR, Parakeet, FireRedASR, and X-ASR, running through sherpa-onnx. On the cloud side the topics list names Doubao, Qwen ASR, Whisper, and ElevenLabs.
That design targets a specific user: someone who already pays for a speech API, or who has a device capable of running a local model and wants recognition to stay on it. The README's quick-start step 3 is blunt about this. You open the settings, pick an ASR provider, and paste an API key. The suggested starting point is Volcano Engine, with a note about 20 free hours. The app itself does not ship a recognition service you can use without that step.
The secondary audience is people who like their current keyboard. The floating-ball feature is described as "跨输入法使用", meaning it works across input methods, so you keep your existing keyboard and trigger BiBi from an overlay instead of switching IMEs.
How recognition, post-processing and insertion actually chain together
The interaction model is press-and-hold. You long-press the microphone, speak, and release. The README also describes 智能判停, automatic stopping on silence, so you do not have to release manually. Audio is uploaded on release, per the phrase "松开即上传".
The chain after that has three stages visible in the material. First, ASR produces a transcript from the chosen provider. Second, an optional LLM post-processing step corrects the result; the README calls this "AI 文本后处理" and lists it under speech recognition rather than as a separate product. Third, the text is inserted into the focused field. Insertion has more than one path: the app can act as the active IME, or it can insert through the accessibility permission, or through an LSPosed or LSPatch module the README calls IME Bridge, which is what allows recording and text injection inside a third-party keyboard.
The history feature is the part worth noting for anyone debugging accuracy. The README states that history can cache the audio and re-run recognition or post-processing. That means a bad transcript is not necessarily a lost recording: you can change provider or prompt and reprocess the same clip. For a tool whose output quality depends on which of 18 backends you selected, keeping the source audio is the difference between tuning and guessing.
There is also a fallback layer. The README mentions a backup engine plus a local standby resident, described as making things more reliable when the network is unstable. The mechanism is not spelled out beyond that, so treat the failover behaviour as something to verify on your own network rather than something the documentation quantifies.
Installing it: the four permissions and the one setting that matters
Distribution is an APK from the Releases page, not a store listing for the free build. The README's install steps are: download the APK, install it, then enable the keyboard through 设置 → 系统 → 语言和输入法 → 虚拟键盘 → 管理键盘 → 启用"「说点啥」". After that you open the app settings, choose an ASR provider, and enter the API key.
System requirements are stated as Android 8.0 (API 26) or higher. The build configuration in the README lists Compile SDK 37, Target SDK 35, and Min SDK 26. Permissions are tiered by feature. Microphone is required for recognition. Overlay permission is optional and gates the floating ball. Accessibility is optional and gates automatic text insertion. LSPosed or LSPatch is optional and gates the IME Bridge integration with third-party keyboards.
The stack is Kotlin 2.3.21 with Jetpack Compose and Material 3 or Miuix, Coroutines, OkHttp 5.3.2, SharedPreferences for storage, and sherpa-onnx for local models. SharedPreferences is the storage layer, which matters for the backup feature: the README advertises config export and import, so the practical migration path between devices is that export file, not a synced account.
The provider configuration guide lives on a Notion page linked from the README rather than in the repository. If you are evaluating this for a team, that is the first document to read, because the setup cost is entirely provider setup.
The local models are the interesting part and the least documented
Six on-device models through sherpa-onnx is an unusual amount of choice for an Android keyboard. It is also the area where the README gives the least to work with. There are no model sizes, no memory figures, no latency numbers, and no guidance on which of the six suits which device class. The names are listed and that is all.
That matters because local ASR on Android is a resource question before it is an accuracy question. A model that runs acceptably on a recent flagship may not be usable on the API 26 floor the README sets. Nothing in the supplied material resolves this, so the honest position is that the local path exists and is named, and its practical cost is unverified here.
The cloud path has the opposite problem. It is well specified in the sense that you know what you are configuring, but every request carries a per-provider price and sends audio off the device. The README's own recommendation points at Volcano Engine. For anyone whose audio is sensitive, the six local models are the reason to consider this project at all, and their undocumented footprint is the reason to test before committing.
Where the free build stops and Pro begins
The README states that a Pro version is on the Play Store at a one-time price of $5.49. The features it names as Pro-only are hot words, simplified-to-traditional Chinese conversion, a continuous speaking mode, and WebDAV automatic backup. The free build retains the 18 ASR providers, the floating ball, the AI edit panel, the clipboard sync, and the backup and restore of configuration.
The split is coherent. What Pro adds is mostly convenience and personalisation around the recognition core, not access to recognition itself. Hot words and the continuous mode are the two that would change daily use; WebDAV automatic backup is the one that matters if you run the app on more than one device, since the free path is a manual export and import of SharedPreferences.
One caveat on the licence. The repository is Apache-2.0, which permits use, modification, and distribution with the copyright notice retained. The README states this directly. Apache-2.0 covers the source in the repository. It does not automatically cover the Pro build distributed through Play, and it says nothing about the terms of the third-party ASR APIs you configure, each of which has its own agreement. That is not a legal opinion, just the boundary of what the licence file in this repository can tell you.
The maintenance question: what you inherit when you install it
The release cadence is visible and tight. v4.4.1 landed on 2026-08-21, v4.4.2 on 2026-08-29, and v4.4.3 on 2026-09-05, with the last push to the default branch on 2026-09-10. Three point releases in roughly two weeks suggests active work on a four-point version line.
For an operator, that cadence is a cost as well as a signal. An IME holds a privileged position: it sees everything typed, and it may hold overlay, accessibility, and LSPosed permissions. Frequent updates mean frequent re-review if you are deploying this in any managed setting. The README mentions a daily automatic update check on launch, which you would want to understand before putting the app on a device you support.
Integration surface is the other maintenance item. The clipboard sync feature depends on SyncClipboard, and the README is explicit that this is a server component rather than something running locally. The IME Bridge depends on LSPosed or LSPatch, which in turn depends on the Android version and the rooting situation of the device. Those are external dependencies that the project does not control, and they are the parts most likely to break independently of BiBi's own release schedule.
How it compares with a plain Android voice keyboard
The obvious alternative is the voice typing already built into a stock Android keyboard, or a dedicated dictation app that hands text to the clipboard. Those take one recognition engine, chosen by the vendor, and give you no setting for it. BiBi Keyboard's difference is not that it recognises speech, it is that recognition is a configuration value with 18 options and a documented swap procedure.
The second alternative is a general speech-to-text API used directly, with your own small client. That gives you the same provider choice but none of the insertion machinery: no overlay ball, no accessibility insertion, no IME Bridge, no history with cached audio for reprocessing. If you only need transcription into a file, an API call is simpler. If you need the text to land in whatever app has focus, the keyboard-shaped problem is the whole problem, and that is the part BiBi Keyboard actually solves.
The honest limitation is that BiBi is not a better recogniser than the providers it calls. It is an integration layer with a provider switch. The README's own quick-start recommends Volcano Engine and mentions 20 free hours, which is an acknowledgement that out of the box, the quality you get is the quality of the account you bring.
Editorial conclusion
Adopt BiBi Keyboard if you already hold an API key for a cloud ASR provider and want a voice-first keyboard on Android 8.0 or later, or if you want a fully offline path through the sherpa-onnx local models. Skip it if you expect a keyboard that works well before any provider configuration, or if you cannot grant overlay, accessibility, or LSPosed permissions on a managed device. Before installing, open the provider configuration document linked from the README and confirm that your chosen ASR vendor is among the 18 listed and that you accept its per-request pricing, because the app ships without a bundled recognition service.
Community notes