You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Exactly this. Main element is not visible. So the whole app is pain. Even on official screenshots this problem persists.
Its interesting how author itself use this app?
Exactly this. Main element is not visible. So the whole app is pain. Even on official screenshots this problem persists. Its interesting how author itself use this app?
I reproduced this on an Android 12 emulator on current main (so with #148's behavior="padding" already in) and traced it — opened #182 with a fix.
Short version: it isn't the behavior prop. KeyboardAvoidingView measures its own frame in window coordinates but reads the keyboard's screenY in screen coordinates. Before Expo's mandatory edge-to-edge those origins coincided; now they differ by exactly the status-bar inset, so the computed padding lands short by that much:
48.86 dp x 3.5 = 171 px, which is exactly the composer row — hence the input box being invisible.
That also explains why this keeps coming back under new numbers (#53/#70, #147/#148, and the closed #74): each of those changed only the behavior value, so none of them touched the mismatch.
@zFitness@DaveScream — if either of you can try the branch in #182, a confirmation on real hardware with a different status-bar height or gesture navigation would be genuinely useful; I only have an emulator and a Pixel 3 XL here.
I am seeing the same Android keyboard/input problem in my OpenCode Mobile workflow: focusing a text input does not resize/reposition the chat surface correctly when the keyboard opens, so the composer/input area is covered or remains at the wrong viewport position. This is especially visible on multiline text input; closing/reopening the keyboard does not reliably restore the expected layout.\n\nEnvironment: Android device/version and app build still need to be recorded precisely; the server is OpenCode 1.18.18 (, ).\n\nI see PR #182 contains the coordinate-space/edge-to-edge fix for this issue. Please merge/release it or confirm the exact build/device combinations that still need validation.
Additional Android reproduction: focusing a text input does not resize or reposition the chat surface correctly when the keyboard opens, so the composer/input area is covered or remains at the wrong viewport position. This is especially visible on multiline text input; closing and reopening the keyboard does not reliably restore the expected layout.
Environment: exact Android device/version and app build still need to be recorded; the server is OpenCode 1.18.18, Qiiks/opencode release v1.18.18-orw.1.
PR #182 contains the coordinate-space/edge-to-edge fix for this issue. Please merge/release it or confirm the exact build/device combinations that still need validation.
Focused PR #190 isolates the keyboard fix from the unrelated changes in PR #182: #190. Static verification is green (5 focused tests, 325 expanded tests, typecheck clean). Android 17 hardware verification is still required; this host has no Android SDK/ADB/device.
Fixed by the merge of #182 into the Qiiks/opencode-mobile maintenance branch (maint/v0.4.16) — shipping in release v0.4.16-maint.1 (APK will be attached there). Upstream review of #182 is still recommended; this merge keeps the fork usable while it waits.
Activity
DaveScream commentedon Jul 31, 2026
Exactly this. Main element is not visible. So the whole app is pain. Even on official screenshots this problem persists.
Its interesting how author itself use this app?
ncend commentedon Aug 13, 2026
https://github.com/ncend/opencode-mobile/releases/tag/v0.4.12-arm64
see my fork and try
fix(chat): keep select-text hint above the system navigation bar
fix(ui): stop the keyboard covering the composer on Android
omgoshjosh commentedon Aug 15, 2026
I reproduced this on an Android 12 emulator on current
main(so with #148'sbehavior="padding"already in) and traced it — opened #182 with a fix.Short version: it isn't the
behaviorprop.KeyboardAvoidingViewmeasures its own frame in window coordinates but reads the keyboard'sscreenYin screen coordinates. Before Expo's mandatory edge-to-edge those origins coincided; now they differ by exactly the status-bar inset, so the computed padding lands short by that much:48.86 dp x 3.5 = 171 px, which is exactly the composer row — hence the input box being invisible.
That also explains why this keeps coming back under new numbers (#53/#70, #147/#148, and the closed #74): each of those changed only the
behaviorvalue, so none of them touched the mismatch.@zFitness @DaveScream — if either of you can try the branch in #182, a confirmation on real hardware with a different status-bar height or gesture navigation would be genuinely useful; I only have an emulator and a Pixel 3 XL here.
fix(chat): keep select-text hint above the system navigation bar
dbusan commentedon Aug 16, 2026
Also experiencing the same issue on my Pixel 9 running Android 16.
Qiiks commentedon Aug 16, 2026
I am seeing the same Android keyboard/input problem in my OpenCode Mobile workflow: focusing a text input does not resize/reposition the chat surface correctly when the keyboard opens, so the composer/input area is covered or remains at the wrong viewport position. This is especially visible on multiline text input; closing/reopening the keyboard does not reliably restore the expected layout.\n\nEnvironment: Android device/version and app build still need to be recorded precisely; the server is OpenCode 1.18.18 (, ).\n\nI see PR #182 contains the coordinate-space/edge-to-edge fix for this issue. Please merge/release it or confirm the exact build/device combinations that still need validation.
Qiiks commentedon Aug 16, 2026
Additional Android reproduction: focusing a text input does not resize or reposition the chat surface correctly when the keyboard opens, so the composer/input area is covered or remains at the wrong viewport position. This is especially visible on multiline text input; closing and reopening the keyboard does not reliably restore the expected layout.
Environment: exact Android device/version and app build still need to be recorded; the server is OpenCode 1.18.18, Qiiks/opencode release v1.18.18-orw.1.
PR #182 contains the coordinate-space/edge-to-edge fix for this issue. Please merge/release it or confirm the exact build/device combinations that still need validation.
Qiiks commentedon Aug 17, 2026
Focused PR #190 isolates the keyboard fix from the unrelated changes in PR #182: #190. Static verification is green (5 focused tests, 325 expanded tests, typecheck clean). Android 17 hardware verification is still required; this host has no Android SDK/ADB/device.
harrywl commentedon Aug 18, 2026
I'm also experiencing this issue — after the keyboard opens, the input box stays hidden behind it and doesn't move up.
Device: Android 16, app version v0.4.15.
Qiiks commentedon Aug 21, 2026
Fixed by the merge of #182 into the Qiiks/opencode-mobile maintenance branch (
maint/v0.4.16) — shipping in release v0.4.16-maint.1 (APK will be attached there). Upstream review of #182 is still recommended; this merge keeps the fork usable while it waits.fix(keyboard): include bottom inset in Android keyboardVerticalOffset (…
fix(ui): stop the keyboard covering the composer on Android (dzianisv…
fix(android): add small constant keyboard offset compensation for MIUI
Merge pull request #236 from dzianisv/fix/keyboard-ime-194
fix(android): keep chat composer above the keyboard (dzianisv#194, dz…
release: v0.4.18 — keyboard, voice, and stability fixes