Question

I have written some code in Java that will decode a SHOUTcast stream and return metadata. This code works as intended, but when I port it to Android the same code does not work. Specifically, I can’t seem to parse the HTTP response header from the SHOUTcast server. Where I can parse it just fine outside Android, I seem to get nothing but garbage back when the request is made via Android.

The relevant code follows.

        URL u = new URL("http://scfire-mtc-aa01.stream.aol.com:80/stream/1074");
        URLConnection uc = u.openConnection();
        uc.addRequestProperty("Icy-MetaData", "1");

        InputStream in       = uc.getInputStream();
        byte[] byteheader    = new byte[512];

        int c = 0;
        int i = 0;
        int metaint = 0;

        while ((c = in.read()) != -1){
            byteheader[i] = (byte)c;
            if (i > 4){
                if (byteheader[i - 3] == '\r' &&
                    byteheader[i - 2] == '\n' &&
                    byteheader[i - 1] == '\r' &&
                    byteheader[i] == '\n')
                    break;   
            }
            i++;
        }

When run in Android, this code overflows the “byteheader” buffer. When run outside Android, it functions properly. To make matters stranger, I have sniffed on the conversation via Wireshark and echoed the header sent by Android to a file. When using netcat to make a request with the same header, I get the appropriate response back. When I look at the logcat output of Android, “byteheader” contains only garbage.

My only idea is that this is something environmental that I’m overlooking. Or, I’m missing something massively obvious.

Any ideas?

As an edit, I’ve further isolated the problem by creating a dummy app and putting only the offending code in it. The problem persists, with Android returning garbage, and my identical external code working as expected. I thought this could be somehow related to character encodings, but it appears both environments are defaulting to UTF8.

Answer 1

I have finally tracked the problem down to URLConnection. Apparently the class operates differently on my local JVM than it does on Android. Outside Android, URLConnection leaves the response header intact. Within Android, the response header is consumed, and the input stream begins at the first byte of data. The header information is available via getHeaderField.

I’m not sure I understand this behavioral difference, and I can chalk it up only to a difference in Java versions.