Q25 Lockscreen pin support

[mionica]

This PR enables PIN input using the keyboard on the lock screen (at least on the Q25, the system does not provide that functionality).
DirectBoot support is implemented; while this does not result in the ability to unlock the device after boot by typing a PIN using the keyboard, it is likely that it will do so for ROMs into which this will be included.
DirectBoot support was adapted from Sri's TypeQ25 - itself a Pastiera derivative work.

[pzauner]

Thanks for working on this. I understand the Q25 problem this is trying to solve, but I’m not comfortable merging this in its current form yet.

If I understand the implementation correctly, this is not primarily making Pastiera act as the lock screen IME. It adds an AccessibilityService that intercepts hardware key events, maps device-specific keys to digits, and then interacts with the SystemUI lock screen UI. For numeric PINs this appears to mean clicking the visible PIN-pad buttons.

That may be useful on the Q25, but it is also a device-/ROM-specific workaround on a sensitive surface, so I think we need a clearer scope before considering it.

Could you please clarify:

• Which lock screen credential types have you tested: numeric PIN, alphanumeric password, pattern, anything else?
• For alphanumeric passwords specifically: what UI does the Q25 show, and does this approach still work there? If yes, how does it interact with that UI?
• Is this intended only for the AFU lock screen after the device has already been unlocked once, or is BFU/direct-boot unlock also expected to work on any ROM?
• What exactly is broken on the Q25 today? Does SystemUI ignore hardware number input entirely, or does it only fail to map the Q25 keyboard’s alternate-number layout to digits?
• Have you tested an external USB/Bluetooth keyboard with dedicated number keys on the Q25 lock screen? This would help distinguish a Q25 keyboard-mapping issue from a broader lock-screen hardware-input issue.
• What happens if a future Zinwa/SystemUI update changes the lock screen UI and this stops working?
• Could you please add a short demo video and link it here? Ideally showing enabling the feature, locking the device, unlocking with the Q25 hardware keyboard, and showing what fallback path remains available.

I’m also not yet convinced this should live directly inside Pastiera. Since this appears to automate the SystemUI lock screen through Accessibility and is specific to Q25/Zinwa behavior, a separate optional helper app/service may be a cleaner boundary.

Separately, if the broader problem is that users cannot conveniently switch IMEs from Pastiera without touching the screen, we could consider adding a dedicated IME-switch action/shortcut in Pastiera itself. That seems like a cleaner general Pastiera feature than bundling this lock screen workaround into the main app.

There are also implementation issues in the current diff:

• PhysicalKeyboardInputMethodService switches to device-protected preferences, while the rest of the app still uses the normal shared preferences path. That looks like the UI and IME can end up reading different settings.
• The new settings switch only handles enabling, not disabling.
• LockscreenPinEntry.onDestroy() appears to keep connected set to true, which seems wrong.
• The SystemUI view-id/text matching is fragile across ROM/SystemUI updates and locales.

I’m not against solving the Q25 lock screen problem, but I think this needs clearer scope, a demo, documented limitations, and a stronger justification for living inside Pastiera before it can be merged.

[mionica]

Upon some reflection, I concur that a separate, dedicated app might make more sense.

Closing, don't merge.

That said, I'm happy to address any of the points you brough up, if you see any value to discussing them despite the PR being withdrawn.

[mionica]

Btw, thanks for the review; leaving connected set at onDestroy, and the broken code around disabling are absolute actual bugs (though the later isn't particularly relevant, since if you have a Q25, you'll never want to disable it :) )

Is there a slack, discord or smth where I could talk to the devs?

[pzauner]

That said, I'm happy to address any of the points you brough up, if you see any value to discussing them despite the PR being withdrawn.

That's exactly the reason why I brought them up. I didn't want to close the PR and neither wanted you to do so.

I also see that an additional App/Helper/IME is more friction, so I am not against merging this into Pastiera.

But it needs to be tested and done architecturally sound. Also since I don't have access to the Q25: Please show me a video of your current implementation running, even if more PoC than anything else. No need for studio quality or anything, just a quick demo as I don't want to believe solely into my imagination.

Also I recall some discussion somewhere that one asked this for the Titan 2 as well and I simply recommended to switch to an alphanumeric password even when not containing anything else than digits

[pzauner]

Is there a slack, discord or smth where I could talk to the devs?

I am the dev ;)
And while the first comment was refined and assisted with AI it was no automated response.

If you want to we can set up a quick (video) call this afternoon at CEST or schedule one for some time next week

[mionica]

Okay then,

Which lock screen credential types have you tested: numeric PIN, alphanumeric password, pattern, anything else?

This is meant purely for the numeric PINs. It doesn't interfere in any way with the other lock screens.

For alphanumeric passwords specifically: what UI does the Q25 show, and does this approach still work there? If yes, how does it interact with that UI?

Alphanumeric passwords work, but they're so inconvenient on boot, you really don't want to use them (for instance, as soon as a key press is registered, it immediately pops up a list of related variations, and it takes >1s for any char to be input, and about as much for closing the variations popup). Something must be really eating up CPU time until you unlock.

Is this intended only for the AFU lock screen after the device has already been unlocked once, or is BFU/direct-boot unlock also expected to work on any ROM?

The Q25 firmware will prevent BFU altogether. However, it is expected that baking the apk into a ROM's priv-app would make that problem go away (hence the separate DirectBoot commit), and that - getting BFU, for PINs only - was the plan (now changed to, make a tiny app just for this purpose, and bake it in).

What exactly is broken on the Q25 today? Does SystemUI ignore hardware number input entirely, or does it only fail to map the Q25 keyboard’s alternate-number layout to digits?

Have you tested an external USB/Bluetooth keyboard with dedicated number keys on the Q25 lock screen?

It seems to ignore - in PIN mode only - keyboard input altogether from the internal keyboard only; neither the number keys, nor alt-number keys, work.

This is completely unlike the Titan2, where alt-numbers work for PIN entry, even on boot.

The USB keyboard's a very interesting thing. Once unlocked, it works reliably; for first unlock though, you have a weird problem - you press a key, you get 3-4 repeats (at least for PIN; didn't try it with alphanumeric). Definitely a ROM bug (kernel? 100% busy userland? IDK), but I wouldn't know how to investigate further. Or why :)

What happens if a future Zinwa/SystemUI update changes the lock screen UI and this stops working?

Nothing. We don't expect any future updates from Zinwa; the Q25 is now an officially supported device for LineageOS, we got one decent mod of the official ROM (modded, not built) which everybody who's not on LOS is on, and Zinwa's busy working on his own full-phone Q20 spin-off (the Q27) and on the Passport restomod (the P26). It's not unlike Titan Pocket / Titan Slim time.

Could you please add a short demo video and link it here? Ideally showing enabling the feature, locking the device, unlocking with the Q25 hardware keyboard, and showing what fallback path remains available.

I've no idea how to screenrecord the lockscreen (if that's possible at all). Maybe if I ask somebody to film me operating it? I'd need both hands to operate the Q25, and I don't own a camera or camera mounting mechanism :) Don't hold your breath though.

Summarizing:

• at boot, the only convenient screen locks are swipe and PIN entry; pattern's a bit hit-or-miss, particularly if hidden (again, the suspected very high-cpu-usage-before-unlock problem), PIN doesn't work with the keyboard, and alphanumeric's borderline unuseable.
• after first unlock, all methods work, including alphanumeric, but PIN seems the preferred option across the user community, and for good reason; but PIN input doesn't work with the hw keyboard at all
• the net result is that most people use a closed-source, non-free keyboard that has an accessibility service that does exactly what this PR would've done (except it seems a bit unreliable? if you misstype the pin once, you'll have to use the screen - a problem which isn't manifest on this PR); actually, I used it myself - keeping it disabled as a keyboard :) - purely for lockscreen PIN entry, before I cooked up this PR; also, being paid, we obiosuly won't put it in a free ROM

Conclusion: most people owning a Q25 will use a combination of PIN and face unlock, and the PIN will be typed on the keyboard, courtesy of some implementation of an accessibility service, presumably similar to what I've done here.
That said, there is indeed no reason to have that baked into Pastiera when it could be done standalone (which is exactly why I withdrew the PR).

[mionica]

Also,

PhysicalKeyboardInputMethodService switches to device-protected preferences, while the rest of the app still uses the normal shared preferences path. That looks like the UI and IME can end up reading different settings.

Another bug I'm happy to confirm (introduced it when cleaning up the patch, I managed to somehow "clean up" the change to SettingsManager's getPreferences(), which used the correct path).

This was harder to spot, since I had to actually look at the code in the commit, not at the code in my head :) My bad.

[pzauner]

got the mail; you can edit the comment but I recommend delete and reposting without paragraph since edit history will be visible

[mionica]

A bit of context here. I'm a single-minded guy; when I realized how I could solve the PIN input problem for every Q25 user out there, I got to work and didn't leave it until I got it sorted. I didn't think of the broader context - I was busy :)

My gut reaction to your

Since this appears to automate the SystemUI lock screen through Accessibility and is specific to Q25/Zinwa behavior, a separate optional helper app/service may be a cleaner boundary.

wasn't "what a mean guy!", it was "why the hell didn't I think of this?!" I mean, it's so obviously correct an observation, that my only reason for not seeing it is that I was too busy coding :)

There's no reason not to have a single-purpose, <200kb apk, solving this exact problem, and baking it into both BenOS (that mod which everybody dailying the Q25 is using) and LOS (for those whom use the Q25 as a second phone). Once you do that, you've covered 95% of the Q25 users, and the remaining few can bloody well just install the apk.