[4.0.5.16] Unable to access device with alphanum pw if keyboard is broken

REPRODUCIBILITY: 100%
OS VERSION: 4.5.0.16
HARDWARE: Xperia 10 but probably N/A
UI LANGUAGE: PL
REGRESSION: kind of

DESCRIPTION:

While having alphanum password, user may lost access to device if keyboard will get broken.

PRECONDITIONS:

nothing except the phone itself

STEPS TO REPRODUCE:

  1. setup alphanumeric encryption password
  2. break keyboard in a way that it won’t display/work at all
    example, in console do:
  dconf write /sailfish/text_input/active_layout '"en-missing.qml"'
  dconf write /sailfish/text_input/enabled_layouts '["en-missing.qml"]'
  1. remove fingerprint login
  2. reboot device
  3. during boot enter password using keyboard from top left corner to enter password to unlock
  4. once the phone will fully boot up, click keyboard in top left corner to enter password to unlock

EXPECTED RESULT:

keyboard will be shown

ACTUAL RESULT:

no keyboard

MODIFICATIONS:

nothing

ADDITIONAL INFORMATION:

ok, this is just a hypothetical scenario which came to my mind just now cause my keyboard is broken but I didn’t change encryption pw to alphanum. If i would do that, I’d be locked out of my device.
Somehow on the first unlock screen, the one during boot the keyboard is showing. The second one which is available after the phone boot up fully, is not showing.

Based on this, it seems we still need some additional handling or a backup keyboard so users won’t end up in this situation when the first keyboard during boot is fine and the second after fully but is broken.

Maybe I didn’t got it right but how do you wanna break your keyboard to never show up again?
I imagine you mean some kind of patching that goes wrong. So you should always have the possibility of use the recovery mode.
But where is the difference between this and a purely numeric keyboard?

that’s a good question - dunno. Right now I’m having this problem:

Yesterday we were trying different solutions without any luck, the keyboard is broken. Only placeholder is showing up which I can close, but there’s no keyboard.

Some explanation. When you setup encryption, you need to type password to unlock the phone twice. First during boot and second once the phone is fully started.
Since 4.5.0.16 there’s an option to use alphanumeric password for encryption. To handle this, Jolla made new option on both lock screens. In the top left corner there’s an icon which allows you to show the full keyboard instead the digit one.
Now the problem is that somehow there’s some difference. The first unlock screen, the one during the boot, is properly showing the full keyboard when you click that button in the top left corner. But once the phone is fully booted up and you need to type the password again, clicking that icon in top left corner shows only a placeholder in my case. In others cases there may be no keyboard.
It’s just hipothetical scenario but this is what I’m observing on my phone.

The guy in this thread seems to have solved his problem.
Have you tried reinstalling all stuff related to the keyboard?

Do you have access to the recovery mode?

I have setup the alphanumeric pw one hour ago but just doing reboots very seldom :wink:
But just tried it out: at least for me it’s working fine.

yes but this bug is not related to that.

it’s a scenario that someone may face up.

Once you’re past the boot stage, you could still connect to your phone via USB or WiFi and unlock it that way, or does that only work if you’ve enabled developer mode? Then again, if you’ve managed to break your keyboard, you probably have developer mode enabled anyway.

I agree though, the password entry should use a failsafe keyboard.

That is a pretty tight corner case all right, but then again, it would make sense to have a separate/hardened keyboard for the PIN code purposes altogether, or enforce a layout, or something like that…

1 Like

In my book this is not really a bug. It’s more like result of an unimplemented feature, i.e. separate keyboard for the alphanumeric password. Nevertheless, I’m adding the “tracked” tag and link to our internal bugzilla.

While I agree, maybe a failsafe fallback to an en_US keyboard in case the setting can’t be read/is borked would be feasible.

1 Like