Automatically change the input method for an action instead of forcing the user to use Key Mapper keyboard all the time

[petiteoffense]

Developer TODO (don't remove)

• update documentation

This app is great, but it seems like the developers had a derp moment with regard to all the complicatioms surrounding keyboards.

Currently, the app and documentation insists on several inconvenient, arcane, or potentially insecure (?) options for mapping keyboard keys to a given button. Maybe I'm missing something, but this seems to me entirely unnecessary.

In the Actions tab, you can set up the following sequence:

1. switch keyboard to Keyboard Mapper's keyboard
2. key code for the key you wanted to map to the button
3. switch keyboard back to user's preferred keyboard

This works perfectly fine for me on first use of the button, and I can in fact get a second use sometimes. But then it breaks. Seemingly only because the app auto-detects that the Key Mapper KB is no longer being used, at which point it completely disables the mapping until the user taps to fix. If the developers just allowed users to turn off this auto-detect-and-disable behavior for any given mapping, I suspect this pattern would function perfectly fine indefinitely.

Is it a bit of a power user hack potentially confusing to some? I suppose so, but not nearly so much so as the Shizuku mess. And not nearly so absurd a requirement as asking users to persistently change their preferred keyboard. It seems like the obvious, easy workaround to me, and you could even set up the UI to make it as smooth as possible by doing the switching in the background after asking the user once to select their default keyboard for typing.

[sds100]

Hi, I understand your confusion about why it's such a weird solution 😅. I think your solution does work for some users but doesn't satisfy everyone.
The reason why I haven't done what you're doing is that it's only fairly recently that Android introduced an API for accessibility services to change the input method. Before this required ADB to grant a permission.

Also, some people are expecting low latency and changing the keyboard before and after each action isn't instant, can you see how low it is by turning on extra logging in the settings?

Another potential solution is to use a brand new API to actually input key events or text from an accessibility service. I tried this but it only works if the keyboard is showing (but not always, or after some delay), and this inconsistency may confuse users and make the UI even more complicated than it is. Also, it takes years for these APIs to propagate to a majority of users.

About your concerns of it being potentially insecure, yes, the old way it was implemented with broadcast receivers had the potential that any app could spam the Key Mapper Keyboard with key events but it wasn't possible to do key logging because I only ever directed the events to a single package name. I implemented a new method in 2.6.2 using AIDL that only communicates if it is a Key Mapper package name Regardless, if an nefarious app wanted to do key logging they easily could and just create their own accessibility service, or somehow a user could install Key Mapper from an unofficial source and it potentially be injected with malware but that's true for all apps, even closed source ones.

[sds100]

To satisfy your use case I will rephrase this issue as asking to not disable the key map if you're turning the input method on and off. Over time if older Android versions become obsolete then I'll work on making a UI for this.

[sds100]

The action you are using was introduced in Android 11 in 2020. About 87% of users can now use it. Until recently development has almost completely be on pause, now its just a trickle of development so I guess coming up with a UI to do what you're doing is potentially an option.