Onboarding enables the Dictus keyboard but never selects it — users think it is active and the mic does nothing (v1.1.0)

[Pivii]

Note: this body was rewritten once the root cause was established. The original analysis was wrong and the thread below records how it was corrected — worth reading if you want the reasoning, not needed if you just want the fix.

Summary

Two users report that tapping the mic in the Dictus keyboard does nothing. One gave up on the app and went back to dictating in-app and copy-pasting by hand. One is on GrapheneOS and provided a log export.

Root cause: v1.1.0 onboarding enables the Dictus keyboard but never selects it, then tells the user setup is complete. On Android those are two different actions. The keyboard the users were tapping was never ours — ours was never activated.

Already fixed on develop by #41, which is not released.

The defect in v1.1.0

AppNavHost.kt, onboarding step 3 (OnboardingKeyboardSetupScreen):

LaunchedEffect(currentStep) {
    if (currentStep == 3) {
        val imm = context.getSystemService(INPUT_METHOD_SERVICE) as InputMethodManager
        val isEnabled = imm.enabledInputMethodList.any { it.packageName == context.packageName }
        viewModel.setImeActivated(isEnabled)     // "activated" only ever means "enabled"
    }
}
...
3 -> OnboardingKeyboardSetupScreen(
    imeActivated = imeActivated,
    onOpenSettings = {
        context.startActivity(Intent(Settings.ACTION_INPUT_METHOD_SETTINGS))  // the enable list
    },
    onNext = { viewModel.advanceStep() },
)

It checks enabledInputMethodList and nothing else. It never reads DEFAULT_INPUT_METHOD. showInputMethodPicker() does not appear anywhere in the app module on v1.1.0 — the only call site is inside DictusImeService itself (:304), unreachable unless the Dictus keyboard is already active.

Every line of the user's log matches

Observation	Explanation
enabled=true, selected=false on all 8 launches over 8 days	he ticked the checkbox; nothing ever selected Dictus
no DictusImeService created, ever	the IME was never the active input method, so the system never created the service
no handleMicTap called, ever — on v1.1.0 that line is logged unconditionally on entry	no tap ever reached our IME
two successful recordings on 2026-08-21 at 11:23	onboarding step 6's in-app test recording — the app path works fine
raw transcript text in the log	pre-#40 build, consistent with v1.1.0
log starts 2026-08-21, no gaps	v1.1.0 has no purge in TimberSetup; complete history since install

Still broken on develop

#41 fixes the activation gap. These do not, and are what will make the next field report just as hard to diagnose:

1. A failed mic tap produces no UI and no log. gatedMicTap (ime/.../DictusImeService.kt:640) returns silently when RECORD_AUDIO is missing (log only, and an InputMethodService cannot request runtime permissions), and runGateCommand does dictationController?.startRecording() — a null controller is swallowed with no trace. grep over the whole ime/ module returns zero Toast and zero error surface.

   Verified on an emulator: a successful keyboard mic tap writes two lines, both from DictationService, and none from the IME. A broken keyboard and an unused keyboard produce identical logs.

2. selected cannot be trusted. Settings.Secure.getString(DEFAULT_INPUT_METHOD) returning null is fed to isImeComponentForPackage and yields false, indistinguishable from "another IME is selected", with nothing logged either way (MainActivity.kt:220-228). The SecurityException branch is handled; a silent null is not.

3. Logging gaps that made this take an emulator control run to settle: Debug log export is too thin to diagnose field reports: null tags, no device context, silent mic-tap path #112.

Actions

1. Cut a release from develop — 46 commits ahead of v1.1.0, including fix(onboarding): require selecting Dictus IME #41. Every user still on v1.1.0 is in this state.
2. Surface mic-tap failures in the keyboard UI (item 1 above).
3. Debug log export is too thin to diagnose field reports: null tags, no device context, silent mic-tap path #112 — make the keyboard log its mic path.
4. Distinguish "cannot read DEFAULT_INPUT_METHOD" from "not selected".

[Pivii]

Correction and verification

Two updates to the analysis above.

1. The log is from the GrapheneOS user's phone, not from an unrelated tester. So it is the log of one of the two people reporting "tapping the mic does nothing".

2. The "IME service never started" conclusion was an assumption; it is now verified.

It rested on "IME logs would reach the file if the service ran". Control test on a Pixel 4 API 29 emulator with the Dictus keyboard enabled and selected:

$ adb shell settings get secure default_input_method
dev.pivisolutions.dictus/.ime.DictusImeService

$ grep -n "DictusImeService created" files/dictus.log
5:2026-08-28 13:34:31.198 [D/null] DictusImeService created
122:2026-08-28 14:34:54.478 [D/null] DictusImeService created

The IME runs in the same process as the app, TimberSetup.init is called from DictusApplication.onCreate, and FileLoggingTree applies no level filter — so IME logs do reach the file. Their total absence from the user's export means the service genuinely was never instantiated on that device over the 8 logged days, consistent with selected=false on all 8 launches.

What this means for the report: on that phone the Dictus keyboard was never the active input method, so there was no Dictus mic button to press. The missing-RECORD_AUDIO path (fix 1 in the issue body) is not what this user hit. The blocking problem for him is that enabling the keyboard without selecting it leaves the app in a dead state it never signals — proposed fix 3 above, which should be reprioritised to first.

Caveat, stated because the file cannot rule it out: TimberSetup.purgeLegacySensitiveLogOnce deletes the log once on upgrade, and the export begins abruptly at an app launch on 2026-08-21. Any keyboard use before that date is invisible. The 8 days that are covered show selected=false throughout.

The silent mic-tap failure paths in the issue body remain real and unfixed — they are just not what produced this particular log. Logging gaps that made this take a control run to settle are filed separately as #112.

[Pivii]

Retracting the previous conclusion

The user has now described his experience precisely: he enabled the keyboard through onboarding, he is on the Dictus keyboard when he types in other apps, and tapping the blue mic does nothing. My earlier conclusion — "the IME service never started, he never selected the keyboard" — was built on an assumption I have since tested, and it does not hold up. Retracted.

What the log physically cannot show

Empirical test on a Pixel 4 API 29 emulator running current develop, Dictus keyboard active in a real editor. Log snapshot before and after tapping the blue mic:

$ diff before.log after.log
> 2026-08-28 15:12:17.142 AudioRecord started: 16000Hz mono Float32, buffer=1920, inputPreference=BuiltInMicPreferenceAccepted, routedType=15
> 2026-08-28 15:12:17.165 DictationService started foreground with ACTION_START

Two lines, both from DictationService. Zero lines from the IME.

So on current develop the log cannot distinguish a recording started from the keyboard from one started in the app, and a mic tap that fails writes nothing whatsoever. The user's two recordings on 2026-08-21 carry exactly this signature — they may well have been keyboard taps. Silence in the log is fully consistent with his report, and is not evidence that the keyboard was unused. This is issue #112, and it is what made the first analysis wrong.

The user is running v1.1.0, not develop

His log contains raw transcript text (Transcription result: raw='Coucou, comment ça va...'). Redaction landed in #40, which is not an ancestor of v1.1.0. His AudioRecord started line also lacks the inputPreference=/routedType= fields added by #52.

git rev-list --count v1.1.0..develop = 46. Several of those target exactly this symptom: #52 (prefer built-in mic), #50 (gate mic while engine loads), #49 (prewarm engine), #46 (reload provider on model switch). His build has none of them.

One anomaly that remains genuinely unexplained

On v1.1.0 the mic button is wired straight to handleMicTap(), which logs unconditionally on entry:

private fun handleMicTap() {
    Timber.d("handleMicTap called, state=%s, bound=%s", _serviceState.value, isBound)

v1.1.0 also logs "DictusImeService created" in onCreate, and its manifest declares no android:process, so the IME shares the app process and the file tree planted in DictusApplication.onCreate.

His export contains neither line, not once in 8 days. On his build every mic tap should have produced handleMicTap called. I cannot reconcile that with his account, and I am not going to invent a mechanism for it.

Two candidates, neither verified:

1. The purge wiped the relevant history. TimberSetup.purgeLegacySensitiveLogOnce deletes dictus.log once on upgrade. His export begins abruptly at an app launch on 2026-08-21 — exactly what a post-purge file looks like. His keyboard attempts may predate it.
2. selected=false is a false negative. Settings.Secure.getString(DEFAULT_INPUT_METHOD) returning null is fed to isImeComponentForPackage, which yields false — indistinguishable from "another IME is selected", and nothing is logged either way (MainActivity.kt:220-228). The SecurityException branch is handled; a silent null is not. On a hardened ROM this read can be restricted. This is a real defect regardless of the outcome here: we cannot currently trust that field.

Reprioritised

1. Debug log export is too thin to diagnose field reports: null tags, no device context, silent mic-tap path #112 — make the keyboard log its mic path. Without it no field report about the keyboard is diagnosable.
2. Surface mic-tap failures in the keyboard UI (fix 1 in the body above) — still the core product bug.
3. Distinguish "cannot read DEFAULT_INPUT_METHOD" from "not selected", and log which.
4. Ship the 46 commits. Users are on v1.1.0 while the fixes for this symptom sit on develop.

Previous fix 3 ("force selection in onboarding") is demoted: its premise was my incorrect reading.

[Pivii]

Root cause, from the log and the v1.1.0 source alone

No further input from the user is needed or will be requested. He tapped the mic repeatedly and the log shows nothing; that is our defect, and the v1.1.0 source explains it completely.

v1.1.0 onboarding enables the keyboard but never selects it

AppNavHost.kt step 3 (OnboardingKeyboardSetupScreen) in v1.1.0:

LaunchedEffect(currentStep) {
    if (currentStep == 3) {
        val imm = context.getSystemService(INPUT_METHOD_SERVICE) as InputMethodManager
        val isEnabled = imm.enabledInputMethodList.any { it.packageName == context.packageName }
        viewModel.setImeActivated(isEnabled)     // "activated" only ever means "enabled"
    }
}
...
3 -> OnboardingKeyboardSetupScreen(
    imeActivated = imeActivated,
    onOpenSettings = {
        context.startActivity(Intent(Settings.ACTION_INPUT_METHOD_SETTINGS))  // the enable list
    },
    onNext = { viewModel.advanceStep() },
)

The step checks enabledInputMethodList and nothing else. It never reads DEFAULT_INPUT_METHOD, and showInputMethodPicker() does not appear anywhere in the app module on v1.1.0 — the only call site is inside DictusImeService itself (:304), which is unreachable unless the Dictus keyboard is already active.

On Android, enabling an IME and selecting it are two different actions. Onboarding does the first, tells the user setup is complete, and never does or checks the second.

Every line of the user's log matches this

Observation	Explanation
enabled=true, selected=false on all 8 launches over 8 days	he ticked the checkbox; nothing ever selected Dictus
no DictusImeService created, ever	the IME was never the active input method, so the system never created the service
no handleMicTap called, ever — and on v1.1.0 that line is logged unconditionally on entry	no tap ever reached our IME
two successful recordings on 2026-08-21 at 11:23	onboarding step 6, the in-app test recording — the app path works fine
raw transcript text present in the log	pre-#40 build, consistent with v1.1.0
log starts 2026-08-21 with no gaps	v1.1.0 has no log purge in TimberSetup; this is the complete history since install

The account and the log are not in conflict once you accept that whatever keyboard he was tapping, it was not ours — because ours was never activated, while the app had told him it was.

Already fixed on develop, unreleased

#41 fix(onboarding): require selecting Dictus IME does exactly this: gates onboarding on imeSelected, adds the picker, and makes it reliable on Android 15. It is one of the 46 commits sitting on develop and not in v1.1.0.

What this issue should now cover

1. Release the 46 commits. Every user on v1.1.0 is in this state. This is the fix that matters.
2. Surface mic-tap failures in the keyboard UI — still unfixed on develop, and still the reason a broken keyboard is indistinguishable from an idle one.
3. Debug log export is too thin to diagnose field reports: null tags, no device context, silent mic-tap path #112 — the keyboard must log its mic path. It logs nothing today, on develop as well.
4. Distinguish "cannot read DEFAULT_INPUT_METHOD" from "not selected" (MainActivity.kt:220-228): a null read is silently treated as "not selected" with no log.

[Pivii]

Reproduced on v1.1.0, and the develop fix verified — both on a Pixel 4 API 29 emulator

v1.1.0: reproduced end to end

Clean install of a build from the v1.1.0 tag, permissions not pre-granted, then the exact path the user described — enable Dictus from onboarding step 3's "Open Settings", tick the checkbox in the real system list, come back:

$ adb shell ime list -s
dev.pivisolutions.dictus/.ime.DictusImeService          <- enabled
...
$ adb shell settings get secure default_input_method
com.google.android.inputmethod.latin/...LatinIME        <- still not Dictus

Onboarding step 3 in that state shows a "Continue" button and lets the user straight through. The flow then reaches step 7: "All set! Dictus is configured and ready to use." — with default_input_method still LatinIME.

Opening any text field afterwards brings up Gboard, whose toolbar carries its own mic icon in the top-right. That is the blue mic the user has been tapping. On a device without Google voice typing it does nothing at all, which is exactly the report.

Two details from the run that corroborate the log analysis above:

• Onboarding's step 6 test recording downloads the tiny model even though Small Q5 was just fetched at step 5 — the same confirmAndTranscribe: model=tiny + download signature seen at 11:23 in the user's log. Those two recordings were onboarding, not keyboard taps. (Fixed separately by fix(onboarding): use downloaded model for test recording #48.)
• Onboarding restarts at step 1 after a process death mid-flow; progress is not persisted.

develop: #41 works

Same starting state (Dictus enabled, LatinIME still default), build from develop:

Requesting system input method picker
IME status: enabled=true, selected=true
DictusImeService created            <- the IME service finally starts

Step 3 now opens the system input-method picker automatically and does not let the user past until Dictus is actually selected. DictusImeService created appearing here also confirms the earlier reasoning: that line is present whenever the keyboard is genuinely active, so its absence across 8 days in the user's export was real.

One new defect found on develop, now fixed

The moment the keyboard became active at step 3, it blanketed itself with "Speech recognition could not start — Try loading the model again, or cancel to return", offering a Retry that can never succeed. Cause: DictationService.prewarmActiveModel treated "the model has not been downloaded yet" as an engine failure:

val modelPath = modelManager.getModelPath(activeModelKey)
if (modelPath == null) {
    providerSlot.markFailed(activeModelKey)          // -> SttEngineState.Failed
    Timber.w("Engine prewarm failed: active model is not downloaded")

At onboarding step 3 no model exists yet — the download is step 5 — so every new user hit a hard error before doing anything wrong.

Fix applied (working tree, not committed):

• New SttEngineState.ModelMissing, distinct from Failed; prewarm publishes it via SttProviderSlot.markModelMissing, logged at info as Engine prewarm skipped: model=%s is not downloaded yet.
• PendingMicGate treats ModelMissing as not pending — prewarming again cannot download a model, and a lingering pending intent would silently start recording on the next unrelated Ready.
• The overlay no longer appears for a background prewarm. It surfaces only when the user actually taps the mic, and then shows "No voice model yet / Download a voice model to start dictating." with a dismiss button and no useless Retry.

Verified on device: no overlay on reaching step 3, correct panel on a mic tap. Two unit tests added (PendingMicGateTest, SttProviderSlotTest); full testDebugUnitTest green.

Note this narrows but does not close the silent mic-tap problem: a tap with a missing permission or an unbound controller is still silent, and the keyboard still writes no log line for either. #112 stands.