GrapheneOS
Keyboard Switch broken on BFU Lock Screen
I've run into a series of bugs that have resulted in me being locked out of my phone until/if this issue can be fixed. My default keyboard has utterly failed to work on boot (it did prior and has for a long time, apparently it's a known issue I was unaware of), and I have USB disabled so I can't work around it with a HID keyboard. Since the device is locked, those problems are unfixable and safe mode did not help in getting around the keyboard issue.
However, the button to switch keyboard layouts, which did work in the past, does not seem to on the latest version of the OS. I have other keyboards capable of running at boot (and which I've used before at boot) installed, if I could only switch to them I could get out of this softlock. I've included a video of it below, it doesn't even highlight when touched like most buttons do, and the OS provides no haptic feedback when it's pressed, unlike pressing on the text field. Would this be fixable from the OS side via a future OTA patch?
https://github.com/user-attachments/assets/d7e6559c-1c63-4289-8089-65b45728f5e6
@thestinger Unfortunately this was in safe mode as you can see in the bottom left corner. The only difference between safe mode and otherwise I noticed is I don't occasionally see the "app keeps stopping" warning from the failing keyboard. I don't get a different keyboard to use and didn't notice any other differences besides "safe mode" in the bottom left.
Would this be fixable from the OS side via a future OTA patch?
Yes, but we have a LOT of stuff we need to work on and it's not really clear what's wrong. It may be fixed in Android 16 QPR1 but we don't have access to that yet.
I understand, you've had a million tasks thrown at you lately and your manpower reduced. I don't expect to see this fixed within the next monthly update cycle. I'd just ideally hope it could be fixed before the year's out, I don't want to wipe this phone if I could avoid it, some stuff is backed up but not everything.
It's my belief based on the two videos and my testing that it's specifically the keyboard switch button that's not functioning. It'd be easy to test if it works at all if you tested it on a known working installation, just see if that keyboard button does anything. I know the one at the bottom right of an open keyboard works, but I obviously can't push that one with it broken.
Is there anything I can do to help you find the issue? I'd be willing to mail the phone out temporarily if it helps you find the issue, it's doing me no good having it in this state.
In Safe Mode, wouldn't all third-party keyboards be disabled?
So if the GrapheneOS keyboard is also disabled (as mentioned in the forum post), wouldn't the keyboard-switcher have nothing to switch to?
In Safe Mode, wouldn't all third-party keyboards be disabled?
So if the GrapheneOS keyboard is also disabled (as mentioned in the forum post), wouldn't the keyboard-switcher have nothing to switch to?
The problem is nearly identical with safe mode off. There are two valid keyboards that can be used at boot that are installed and enabled. Regardless, the issue is more that the button is nonfunctional. I've had to use several older phones for now, the corresponding button works on them before unlock.
@de0u FUTO Keyboard Dev (currently selected, broken) and Gboard (not broken, no way to switch to it)
The lead developer for FUTO keyboard looked at what the problem was and managed to reproduce the issue on an up to date pixel running the stock OS, he had this to say:
"I have some logs from adb for you at least, this is what gets logged in safe mode when the keyboard is not appearing[...]"
Error in async IMMS call
java.lang.IllegalArgumentException: Unknown id: org.futo.inputmethod.latin.unstable/.LatinIME
at com.android.server.inputmethod.InputMethodBindingController.bindCurrentMethod(InputMethodBindingController.java:548)
at com.android.server.inputmethod.InputMethodManagerService.startInputUncheckedLocked(InputMethodManagerService.java:2114)
at com.android.server.inputmethod.InputMethodManagerService.startInputOrWindowGainedFocusInternalLocked(InputMethodManagerService.java:3732)
at com.android.server.inputmethod.InputMethodManagerService.startInputOrWindowGainedFocus(InputMethodManagerService.java:3654)
at com.android.server.inputmethod.ZeroJankProxy.lambda$startInputOrWindowGainedFocusAsync$2(ZeroJankProxy.java:191)
at com.android.server.inputmethod.ZeroJankProxy.$r8$lambda$GEYhLJlRSeap_3TyEA3h0ogXJLQ(ZeroJankProxy.java:0)
at com.android.server.inputmethod.ZeroJankProxy$$ExternalSyntheticLambda5.runOrThrow(R8$$SyntheticClass:0)
at com.android.internal.util.FunctionalUtils$ThrowingRunnable.run(FunctionalUtils.java:106)
at com.android.server.inputmethod.ZeroJankProxy.$r8$lambda$WUdtZ2tp1_iIb2R8Q6G3Q0hd1Kg(ZeroJankProxy.java:113)
at com.android.server.inputmethod.ZeroJankProxy$$ExternalSyntheticLambda9.run(R8$$SyntheticClass:0)
at android.os.Handler.handleCallback(Handler.java:1041)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.dispatchMessage(Looper.java:315)
at android.os.Looper.loopOnce(Looper.java:251)
at android.os.Looper.loop(Looper.java:349)
at android.os.HandlerThread.run(HandlerThread.java:100)
at com.android.server.ServiceThread.run(ServiceThread.java:49)
The problem was reproduced on an up to date stock pixel, implying that it's still broken in QPR1, as is the keyboard switch button. They also said the relevant code section is mostly unchanged in GOS, being this part: https://github.com/GrapheneOS/platform_frameworks_base/blob/d697c573a824058f1067fc4b317a560d71ce937c/services/core/java/com/android/server/inputmethod/InputMethodBindingController.java#L543
Hopefully this helps in identifying exactly where something's going wrong and avoid much need to troubleshoot further. They suggested logic to attempt to use another valid IME instead of throwing an exception.
If further testing is needed, please let me know.
I did some testing a while ago on the keyboard and password unlock situation on GrapheneOS.
The active keyboard is stored in Android's secure setting default_input_method, it's value is org.futo.inputmethod.latin/.LatinIME for FUTO keyboard for example.
If the active keyboard can't be loaded because it crashes or doesn't refer to an available keyboard (e.g. when booting into safe mode or after manually setting default_input_method to a bogus value), GrapheneOS doesn't automatically switch to another keyboard. Instead, no keyboard is shown (leading to bug #4662 for example). This seems to be your situation.
It seems in that case the switch keyboard button on the lock screen doesn't work (also mentioned in bug #4662, doesn't matter if the GrapheneOS keyboard is enabled); I guess it depends on a keyboard being loaded.
They suggested logic to attempt to use another valid IME instead of throwing an exception.
This seems to be the solution indeed.
Hmmm... I'm not sure I've actually added anything to this conversation 🤔
That matches what I experienced, yeah. I hope to hear from a maintainer soon as to whether fixing this can or will happen soon, as it'd be better to know sooner rather than later if it'd be sensible to wipe the phone and start over.
@thestinger when will this be fixed? A fix is suggested in https://github.com/GrapheneOS/os-issue-tracker/issues/6373#issuecomment-3449800527 (select different IME when stored one can't be loaded). This has potential to lock users out of device permanently so should be high priority, no?
Is it still an issue in Android 16 QPR1? There's a high chance it will be fixed in Android 16 QPR2. It's very likely not caused by anything GrapheneOS changes.
@thestinger thanks for quick response.
In https://github.com/GrapheneOS/os-issue-tracker/issues/6373#issuecomment-3478740030 it's suggested to be partly a GrapheneOS issue:
If the active keyboard can't be loaded because it crashes or doesn't refer to an available keyboard (e.g. when booting into safe mode or after manually setting default_input_method to a bogus value), GrapheneOS doesn't automatically switch to another keyboard. Instead, no keyboard is shown (leading to bug #4662 for example).
That doesn't indicate it's specific to GrapheneOS rather than an AOSP issue also impacting the stock Pixel OS too.
That doesn't indicate it's specific to GrapheneOS rather than an AOSP issue also impacting the stock Pixel OS too.
Ok, thanks. What's a suggested workaround to not get locked out? Disable 3rd party keyboards? Allow USB connection in BFU?
Don't use an unreliable 3rd party keyboard. We don't have a confirmation of if this is still an issue after Android 16 QPR1 though.
Is it only an issue with 3rd party keyboards? Which keyboard is loaded BFU?
Any keyboard can support being used BFU via Direct Boot but it requires them to specifically add support for it. The built-in keyboard of course supports it.
Any keyboard can support being used BFU via Direct Boot but it requires them to specifically add support for it. The built-in keyboard of course supports it.
So this should only be an issue if a keyboard announces to support BFU use but then fails, and any "non BFU" keyboard should be fine?
Hi all, I have no third-party keyboards installed, but I am having the same issue of being unable to type a password at BFU lock screen because no keyboard shows up. So maybe this is not related to different keyboards, but some other issue?
My screen is basically exactly as @Doc-4's video, except there is no alternative keyboard button (because only AOSP keyboard installed). But, in a similar fashion, tapping the password "line" results in no keyboard being shown.
What I discovered for me is that it seems to have something to do with my SIM card.
I have been able to get the keyboard to appear if I do one of the following:
- if you have a physical SIM card, eject the SIM card completely, and then reboot the phone. The OS will show me the keyboard at the password entry now. This workaround works without fail for me. Of course, this will not work if you have an eSIM. or:
- at the password entry screen without a keyboard (with the SIM card inserted from before boot), press emergency call, and try playing with the dialer. For me, pressing *#06# to get the IMEI code a few times seems to do the trick. Thereafter, the keyboard may appear.
N.B. When I boot, the OS does let me input the SIM lock code (which is just numbers), but thereafter no keyboard appears for me to enter the Owner alphabetic password. Also I am on the latest GrapheneOS version available as of the date of my post (2025112100).
Is it still an issue in Android 16 QPR1? There's a high chance it will be fixed in Android 16 QPR2. It's very likely not caused by anything GrapheneOS changes.
Still broken, as of the latest available update pushed this morning. Behavior seems the same, posted a new video.
https://github.com/user-attachments/assets/b5fcfa99-e942-467d-86eb-1fef1fcef424
Any ETA for when this is planned to be addressed? How far out is QPR2 from us, or will you consider addressing the issue downstream if it's sufficiently far enough?
I've since learned that the software keyboard on GOS is critical software and having a nightly build of a keyboard set to auto update was a bad idea. I thought having other known good BFU compatible keyboards enabled mitigated the issue, and I was partially wrong. It'll save this phone when either the button or automatic keyboard switching upon error are fixed, but it's not currently helpful. I'm currently using a phone that's 3 years to the day out on security patches, hoping every day to be off of it.
Any ETA for when this is planned to be addressed? How far out is QPR2 from us, or will you consider addressing the issue downstream if it's sufficiently far enough?
It will not be worked on without confirmation that it doesn't impact the stock OS. We have a massive workload with extremely high priorities and are not able to work on upstream Android issues unless it's a special case with a serious security impact or it's very negatively impacting a lot of users. This is neither of those things.
I was hoping getting device trees for the Pixel 10 would have helped with that. Unfortunate to hear, hopefully QPR2 will fix it, I can't easily test it as I don't have another compatible device or I'd go test it myself.
Device trees are not used for any devices anymore since AOSP doesn't provide those. Not sure what you mean by that. We're overloaded with a huge amount of work to keep up with porting to new versions, security preview updates and device support along with maintaining our existing features. We have almost no time to work on fixing high priority issues and no time to work on any new features. Most of these upstream issues will likely just be closed without confirmation that it's GrapheneOS specific as we cannot possibly fix every Android bug.
I think I misremembered a headline about something that was previously withheld being published, maybe it was the source for QPR1? I'm wrong, ignore that comment.
You said that you're fairly confident QPR2 will fix the issue, I'm curious as to why you think so? Does AOSP have a similar issue parallel to this one? And sorry last question, if a pull request were submitted to fix this issue without compromising anything, would it be accepted? I'd consider that if it's not fixed by QPR2's porting to GOS.
I said there was a high chance it would be fixed in QPR2 if it's not already fixed in QPR1 because it's almost certainly an upstream bug and they're probably aware of it since users are running into it. I didn't say I was confident it would be fixed in QPR2, that's not what I meant by a high chance. That was also taking into account that QPR1 may have fixed it which you say it hasn't.
Confirming I also ran into this issue and am locked out of a Pixel 9 phone. Attaching video. I was using Gboard as my main keyboard. It got glitchy and was not loading reliably. Tried rebooting expecting it might help resolve the issue and got locked out instead. Everything I've tried has failed to work including 1) booting into safe mode 2) clicking on the password field multiple times while pressing the power button 3) manually adb sideloading OTA updates for the stable, beta and alpha, version 2025120400. They all have this issue. 4) attaching physical keyboard (default seems to be is charge only BFU) 5) booting without a SIM. 5) Putting in a SIM that requires a PIN to unlock.
Until this is resolved, recommend:
- full backups via seedvault
- turning on USB devices BFU in the exploit protection menu so if this also happens to you then you have some recourse.
- making sure the stock keyboard is on
https://github.com/user-attachments/assets/6e356d83-4369-4839-bd73-49cdc9893c7f
