Prompt user to enable keyboard accessibility service on app start#556
Prompt user to enable keyboard accessibility service on app start#556IliyaBrook wants to merge 2 commits into
Conversation
|
This is probably not the right place to report this, maybe it's even worth to open a new issue. I use moonlight the most of the tv (Chromecast) both for playing game with a controller and with a mouse and keyboard, so it's very useful to have the accessibility option turn on to be able to use the windows key, alt tab, etc. The problem is that every time I want to use my controller with moonlight there is a prompt to me to allow it or not in the app, and when the accessibility option is on the arrows and back button don't work on the remote, so I can't tap accept on the prompt, I assume moonlight captures all of those inputs so it doesn't work. The only way I made it work was to use a remote app on my phone that uses adb to click accept. Don't know if there is a possible fix for this. Maybe detect when there is a system pop up and don't capture remote actions? The popup is similar to this. |
Problem
Android intercepts system shortcuts (Alt+Tab, Alt+Esc, Win key, Ctrl+Esc, etc.) at the SystemUI level, so they never reach the host PC during streaming. The repo already ships a
KeyboardAccessibilityServicethat forwards these events when enabled, but nothing in the app tells the user the service exists or how to turn it on. New users with a physical keyboard simply experience broken shortcuts and don't know why. See for example #225 and similar reports across multiple devices — the underlying fix is already in the codebase, it just isn't discoverable.Changes
PcView.onResume(), if a physical keyboard is connected and the service is disabled, show a one-time dialog with three actions: Accessibility settings / App info / Don't show again. Opt-out is persisted in a new prefcheckbox_suppress_keyboard_a11y_prompt.KeyboardAccessibilityServiceconfig:feedbackTypeFEEDBACK_SPOKEN→FEEDBACK_GENERIC(so it no longer appears as a screen reader in the OS list),eventTypesTYPES_ALL_MASK→TYPE_WINDOW_STATE_CHANGED. No behavioural change —FLAG_REQUEST_FILTER_KEY_EVENTSis unaffected.Testing
Tested on Lenovo TB320FC (Lenovo Tab Plus, Android 15, ZUI).
Two notes worth flagging from real-world testing: