Key Character Maps not being applied for simulating key events

[jambl3r]

DEVELOPER TODO

• Think about how to detect when to automatically convert key event actions into text beside the scenes. Check whether the key character map of the trigger device and the Virtual device resolve to different characters?

Have you checked if an issue already exists for this bug?

• Nobody else has reported this bug before

Have you tried restarting your device?

• I have tried restarting my device and that did not help

What happened that you did not expect?

I'm hypothesising Android isn't applying the Key Character Map layout to the duplicated input device behind the scenes. Android is probably a bit confused and is treating the old and duplicated input device as the same one in the user interface, but behind the scenes it isnt treating them the same. With expert mode i may be able to change the key character map of the duplicated device.
A better solution for this problem would be Text action working with Expert mode, but this problem could apply in other situations too.

What did you expect to happen?

No response

What would the developer need to do to reproduce the bug?

No response

App version

4 beta

Android version

16

Device model and manufacturer

?

Extra info

• My device is rooted

[sds100]

So, this is fixable in 3.0 if they specify the device for the key event action and they are using the key mapper input method. I'll change the default behavior to pass through the correct device for the new key events.

This is impossible to fix if they are using an accessibility service trigger, and injecting with Expert mode through Android InputManager service. The system always overwrites the device id you specify to -1 (virtual device), and this always uses the standard US layout.

I still need to investigate how to fix it with expert mode triggers, and injecting the key event at the linux evdev level.

Since the option to automatically switch IME when typing is quite pleasant to use now, keyboard remapping people are probably better off using the IME. Unless they want to move around their modifiers or change function keys.

[sds100]

This makes things very complicated. If a user enables Expert mode then we automatically turn on injecting key events with expert mode, which can then break their key event actions even if they manually specified which device to input them from. It seems like keyboard users are better off the old way (accessibility service -> IME), or (expert mode trigger -> expert mode). The in between option does not work well.

[sds100]

I guess one solution could be detecting whether their text inputted from their key event actions will be affected by the key character map. If yes, then do not inject the key event but figure out which characters they will resolve to, and inject the text. But this is a hard heuristic to determine - i guess one could detect whether they are remapping a keyboard in the trigger?

[jambl3r]

The in between option does not work well.

Forbid it? Do away with the option and all expert mode stuff stays in expert mode world

I guess one solution could be detecting whether their text inputted from their key event actions will be affected by the key character map. If yes, then do not inject the key event but figure out which characters they will resolve to, and inject the text. But this is a hard heuristic to determine - i guess one could detect whether they are remapping a keyboard in the trigger?

This sounds more like what I had imagined as a plan B. You would essentially do the character mapping yourself.

[sds100]

We can't forbid it, its been allowed for years (through shizuku) and majority of people use it without issues like minecraft people. Even most keyboard users won't have any issues. I think Plan B is the only way.

[sds100]

Plan B will take some thinking so I'll push it to another release. The people with this problem should just use the text action, which is easier to set up anyway if you want a specific character.

[sds100]

So the correct key character map is used when inputting a single key event action through evdev. It does not work when inputting Shift + a key.

Example
Evdev trigger = KEYCODE_S
Action = KEYCODE_SHIFT_LEFT, KEYCODE_APOSTROPHE.

The re-injected evdev key codes are being detected by the accessibility service. The KEYCODE_APOSTROPHE is being consumed, and imitated with InputManager, so it is being reset to device id -1, hence why it doesn't work. This consuming does not happen if the action is only KEYCODE_APOSTROPHE.

Evdev event: deviceId=7, deviceName=Logitech USB Keyboard, type=4, code=4, value=458774
15:19:26.874  D  Consumed: false
15:19:26.876  D  Evdev event: deviceId=7, deviceName=Logitech USB Keyboard, type=1, code=31, value=1
15:19:26.882  D  Consumed: true
15:19:26.883  D  Evdev event: deviceId=7, deviceName=Logitech USB Keyboard, type=0, code=0, value=0
15:19:26.884  D  Consumed: false
15:19:26.884  D  Performed action InputKeyEvent(keyCode=59, metaState=0, device=null), input event type: DOWN, key meta state: 65
15:19:26.885  D  Performed action InputKeyEvent(keyCode=75, metaState=0, device=null), input event type: DOWN, key meta state: 65
15:19:26.886  D  Key down KEYCODE_SHIFT_LEFT: keyCode=59, scanCode=42, deviceId=51, metaState=65, source=257
15:19:26.891  D  Consumed: false
15:19:26.892  D  Key down KEYCODE_APOSTROPHE: keyCode=75, scanCode=40, deviceId=51, metaState=65, source=257
15:19:26.907  D  Imitate button press KEYCODE_APOSTROPHE with system bridge, key code: 75, device id: 51, meta state: 65, scan code: 40
15:19:26.908  D  Injecting key event with system bridge KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_APOSTROPHE, scanCode=40, metaState=META_SHIFT_ON|META_SHIFT_LEFT_ON, flags=0x8, repeatCount=0, eventTime=5981616000000, downTime=5981616000000, deviceId=51, source=0x101, displayId=-1 }
15:19:26.908  D  Consumed: true
15:19:26.931  D  Evdev event: deviceId=7, deviceName=Logitech USB Keyboard, type=4, code=4, value=458774
15:19:26.931  D  Consumed: false
15:19:26.932  D  Evdev event: deviceId=7, deviceName=Logitech USB Keyboard, type=1, code=31, value=0
15:19:26.933  D  Consumed: true
15:19:26.933  D  Performed action InputKeyEvent(keyCode=59, metaState=0, device=null), input event type: UP, key meta state: 65
15:19:26.934  D  Performed action InputKeyEvent(keyCode=75, metaState=0, device=null), input event type: UP, key meta state: 65
15:19:26.935  D  Key up KEYCODE_SHIFT_LEFT: keyCode=59, scanCode=42, deviceId=51, metaState=0, source=257
15:19:26.936  D  Consumed: false
15:19:26.936  D  Evdev event: deviceId=7, deviceName=Logitech USB Keyboard, type=0, code=0, value=0
15:19:26.936  D  Key up KEYCODE_APOSTROPHE: keyCode=75, scanCode=40, deviceId=51, metaState=0, source=257
15:19:26.936  D  Consumed: false
15:19:26.937  D  Imitate button press KEYCODE_APOSTROPHE with system bridge, key code: 75, device id: 51, meta state: 0, scan code: 40
15:19:26.938  D  Consumed: true
15:19:26.938  D  Injecting key event with system bridge KeyEvent { action=ACTION_UP, keyCode=KEYCODE_APOSTROPHE, scanCode=40, metaState=0, flags=0x8, repeatCount=0, eventTime=5981646000000, downTime=5981646000000, deviceId=51, source=0x101, displayId=-1 }