IssueTracker

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Sadly, I can't enter any character I wish, such as of other languages. I think it supports only ascii...

adb is fine:

~$ adb shell echo '1박 2일'
1박 2일
~$ adb shell echo '1박 2일'| xxd
00000000: 31eb b095 2032 ec9d bc0a                 1... 2....
~$ 

but it does look like the 'input' command might have issues:

~$ adb shell input keyboard text '1박 2일'

Exception occurred while executing 'keyboard':
java.lang.NullPointerException: Attempt to get length of null array
	at com.android.server.input.InputShellCommand.sendText(InputShellCommand.java:318)
	at com.android.server.input.InputShellCommand.runText(InputShellCommand.java:290)
	at com.android.server.input.InputShellCommand.onCommand(InputShellCommand.java:231)
	at com.android.modules.utils.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:97)
	at android.os.ShellCommand.exec(ShellCommand.java:38)
	at com.android.server.input.InputManagerService.onShellCommand(InputManagerService.java:3432)
	at android.os.Binder.shellCommand(Binder.java:968)
	at android.os.Binder.onTransact(Binder.java:849)
	at android.hardware.input.IInputManager$Stub.onTransact(IInputManager.java:981)
	at android.os.Binder.execTransactInternal(Binder.java:1205)
	at android.os.Binder.execTransact(Binder.java:1163)
~$ 

what's the code?

        final char[] chars = buff.toString().toCharArray();
        final KeyCharacterMap kcm = KeyCharacterMap.load(KeyCharacterMap.VIRTUAL_KEYBOARD);
        final KeyEvent[] events = kcm.getEvents(chars);
        for (int i = 0; i < events.length; i++) {
            KeyEvent e = events[i];
            if (source != e.getSource()) {
                e.setSource(source);
            }
            e.setDisplayId(displayId);
            injectKeyEvent(e);
        }

okay, so maybe you have to have the right virtual keyboard in use?

nope ... changing to the korean keyboard doesn't fix my korean example above.

over to lzye who seems to have touched this last, and might know whether this is a bug/regression/unfortunate unfixable limitation.

If anyone knows about AccessibilityService, please answer me about this possible workaround of this matter, to dispatch unicode keys through it:

https://stackoverflow.com/q/70160582/878126

They are two different concepts:
The adb shell input text abc : means it would send mulitple key events of a b c within a command,
so it first seperate the input string to each character then generate key events to inject.

And the expectation of this request is to deliver the content text to an edit text or some focused view.
It could ignore the framework process.
For example:
probadly use UiAutomation to find the focused view and call its setText if any.

Hey,

any news on this one, we would also like to be able to send UTF8 characters via adb shell input text ?

Thank you

might know whether this is a bug/regression/unfortunate unfixable limitation.

This a limitation; perhaps not an unfixable one but it does require some design (and some concrete use cases to understand if this is even the right tool for the job). The input command injects hardware keys, not raw text -- this means that we need to map the given text back to hardware keys in order to inject it. This design has several problems when it comes to unicode:

1. Switching the keyboard layout is done per device and there's no way to do so for the virtual keyboard today. If the tool did switch the layout to be able to inject unicode, the virtual keyboard is a global device so the layout would be changed for all clients, which isn't really safe (though unclear to me how much of a problem that is).

2. Even if you can set the layout, our list of languages supported by physical keyboards is relatively small and wouldn't cover a large number of languages. We also don't require devices to support the languages we do have layouts for today, so it wouldn't be guaranteed to work across the ecosystem (unless we added policy to require language support).

3. Even if we supported all languages, you still can't input a huge amount of the unicode range -- not all text can be directly mapped to physical key presses. Some languages require IME interactions to compose / transliterate. Some codepoints are modifiers that need to be combined with other characters. No keys will ever really map to these.

I kind of think this most people just care about the text and not the physical key input, so maybe this should just go through the IMF framework instead. This would, unfortunately, break anyone using the input command to test hardware key interactions however. The other option would be to introduce some way on Android to inject arbitrary unicode code points (e.g. AltGr+codepoint) and then inject those keys, which is a bit roundabout. If people actually want to test physical keyboard input though, then we need to think about how to actually configure the device (e.g. do we need clients to tell us the layout? do we need to require OEMs ship support for all layouts in AOSP? etc).

Anyways. I do think we need some concrete use cases here so we can design the right thing and give it the right priority.

+1 for a mechanism to inject arbitrary code points. Ideally, not just through ADB, but also programmatically. Device mirroring in Studio would greatly benefit from this. See, for example, b/269961652.

All major platforms support Unicode insertion via keyboard shortcuts, so to me it looks like a good feature to add. That said, I never liked the AltGr+code Windows Unicode entry (or Mac's equivalent) for a couple of reasons: it's decimal, and it actually collides with legitimate mappings. Instead, I believe the Linux shortcut (Ctrl+Shift+U+hex code) does not have any shortcoming.

After Android has this mechanism, it would be quite straightforward to modify KeyCharacterMap#getEvents to generate events that fall back to the unicode entry when the built-in keyboard KCM doesn't define the target character. Because this mechanism is not in place today, the text entry using this method is not reliable, which is why the documentation suggests an alternative (ACTION_MULTIPLE) that became deprecated some years ago.

While this solution would add Unicode support to adb shell input text, no modification would be needed on InputShellCommand.

It's actually pretty straightforward to support it in Gboard. We can implement a hidden feature in Gboard to intercept key event sequences with a special format, e.g. ctrl+shift+u+hex code, and output the corresponding Unicode text to the app.

Then no change needs to be done in Android system, and we can support it on all Android versions as long as it has the latest Gboard as the default IME.

WDYT?

Ctrl and Shift are modifier keys; using them as a shortcut would break any other usage; for instance Ctrl+Shift+Arrows modifies the text selection.

What I was proposing is the same feature as Linux: Ctrl+Shift+U enters Unicode compose; releasing Ctrl or Shift ends it. This would require holding Ctrl+Shift with one hand and typing the code with the other, which seems like adequate UX to me.

Android already had the ability to pass strings over KeyEvent (ACTION_MULTIPLE), but seems like it didn't work out and was deprecated about 5 years ago. I don't know the reasons why, but probably deserved it, and the APi is more elegant without it IMHO.

I don't think this should be done at Gboard level; I'll add a technician proposal later today about what I believe to be the best way to implement it.

Support for older versions of Android could be done via Gboard indeed; however, I don't think it possible to retrofit the adb shell input text command to support the conversion from Unicode text to events that generate it; instead, we would need to generate the key events that would produce that output. Producing multiple key combinations is possible with the current input shell command.

Android does not have at the moment a way to write Unicode manually, which is why I'm proposing the "Unicode compose mode". Yes, this would be a change in Android itself, and it would take a while toac

@su...@google.com I think the best course of action here would be to implement this on Gboard, and then just disable it if we decide to implement it at framework level. What do you think? Should I assigned this request to you?

*Android does not have at the moment a way to write Unicode manually, which is why I'm proposing the "Unicode compose mode". Yes, this would be a change in Android itself, and it would take a while to actually become available to devices.

From API level 35 we could implement the Unicode compose mode in core/java/android/text/method/QwertyKeyListener; we even have an inactive path there from a previous implementation: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/text/method/QwertyKeyListener.java;l=141

The same is true for any of the current mechanism we have at the moment, like accent composition; even if this feature would not initially work on some IMEs, it currently does not work in any, so it's a improvement.

API 34 is already finalised, so it's not possible to add more changes.

I'm afraid I have no information on that, but I'm talking about the API, not the build.

Just filed b/292019312 for the workaround in Gboard.

Let's leave this bug for the ideal implementation in Android framework.

lblb636 it'd be very helpful if you could provide some actual use cases for this feature request.

See b/269961652 for a Studio use case.