Encoding issues using ADB to dispatch messages

Question

I've implemented a service that listens to commands issued through ADB. An example of a command sent through ADB could look like this:

adb shell am startservice -a com.testandroid.SEND_SMS -e number 123123123 -e message "åäö"

Now, the problem here is that the encoding of the string "åäö" seems to mess up. If I take that string extras and immediately output it to the log, I get a square "[]", unknown character. If I send this message I get chinese characters in the messages app. As long as I stick to non-umlaut characters (ASCII I guess), everything works fine.

I'm using Windows 7 and the command line for this. I have not touched the encoding of the command line and I've tried to process the extras string by getting the byte characters, passing in UTF-8 as an encoding argument, then creating a new String passing in UTF-8 as an encoding argument there as well. No dice, though.

The values of the bytes, when using getBytes() are å: -27, ä: -92, ö: -74

How do I get this to play nice so I can make use of at least the umlauts?

All of this works perfectly fine in Linux.

Answer 1

i ran into the same issue, but finally i got it work!

if you use for example C#, you have to do it like the following example:

02.12.2019

According to the protocol.txt, the ADB-Protocol supports "smart-sockets". Those sockets can be used to do all the stuff, the ADB-Client inside the adb.exe does. For example if you want upload an file, you have to request such an "smart-socket". After that, you have to follow the protocol assigned to the service (for an service overview see SERVICE.txt) as described, for example, in the SYNC.txt.

13.10.2014

public static List<string> ExecuteBG(string exe, string args, int timeOut = -1)
{
    if (File.Exists(exe) || exe == "cmd.exe")
    {
        ProcessStartInfo StartInfo = new ProcessStartInfo();
        StartInfo.FileName = exe;
        StartInfo.Arguments = Encoding.Default.GetString(Encoding.UTF8.GetBytes(args));
        StartInfo.CreateNoWindow = true;
        StartInfo.UseShellExecute = false;
        StartInfo.RedirectStandardError = true;
        StartInfo.RedirectStandardOutput = true;
        StartInfo.StandardErrorEncoding = Encoding.UTF8;
        StartInfo.StandardOutputEncoding = Encoding.UTF8;
        AutoResetEvent errorWaitHandle = new AutoResetEvent(false);
        AutoResetEvent outputWaitHandle = new AutoResetEvent(false);
        List<string> response = new List<string>();

        Process proc = new Process();
        proc.StartInfo = StartInfo;
        proc.ErrorDataReceived += (s, e) =>
        {
            if (String.IsNullOrEmpty(e.Data))
            {
                errorWaitHandle.Set();
            }
            else
            {
                response.Add(e.Data);
            }
        };
        proc.OutputDataReceived += (s, e) =>
        {
            if (String.IsNullOrEmpty(e.Data))
            {
                outputWaitHandle.Set();
            }
            else
            {
                response.Add(e.Data);
            }
        };
        proc.Start();
        proc.BeginErrorReadLine();
        proc.BeginOutputReadLine();
        proc.WaitForExit(timeOut);
        errorWaitHandle.WaitOne(timeOut);
        outputWaitHandle.WaitOne(timeOut);
        return response;
    }
    return new List<string>();
}

Really important is this part "StartInfo.Arguments = Encoding.Default.GetString(Encoding.UTF8.GetBytes(args));", here we convert the UTF8 string into the Windows "default" charset which is known by cmd. So we send a "destroyed" "default" encoded string to cmd and the Android shell will convert it back to UTF8. So we have the "umlauts" like "üöäÜÖÄàè etc.".

Hope this helps someone.

PS: If u need a working "Framework" which supports UTF8 push/pull for files/folders also have a look at my AndroidCtrl.dll it's C# .NET4 written.

Regards, Sebastian

Answer 2

Concluding, either the problem is situated in cmd.exe or adb.exe. Until either one or both are updated to be more compliant with eachother I will sadly not be able to make use of this for the time being.