Q:

Why does SKIA not use a custom FilterInputStream?

I'm trying to decode a bitmap from an extended FilterInputStream. I have to perform on-the-fly byte manipulation to the image data to provide a decodable image to SKIA, however it seems like SKIA ignores my custom InputStream and initializes one of its own...
When I run my test application, attempting to load in a 2mb large JPEG results in ObfuscatedInputStream.read([]) being called only once from BitmapFactory.decodeStream()
It seems like once the type of file is determined from the first 16kb of data retrieved from my ObfuscatedInputStream it initializes its own native stream and reads from that, effectively rendering all changes I make to how the input stream should work useless...
Here is the buffered read function in my extended FilterInputStream class. The Log.d at the top of the function is only executed once.
@Override
public int read(byte b[], int off, int len) throws IOException 
{
    Log.d(TAG, "called read[] with aval + " + super.available() + " len " + len);
    int numBytesRead = -1;

    if (pos == 0)
    {
        numBytesRead = fill(b);
        if (numBytesRead < len)
        {
            int j;
            numBytesRead += ((j = super.read(b, numBytesRead, len - numBytesRead)) == -1) ? 0 : j ;
        }
    }
    else
        numBytesRead = super.read(b, 0, len);

    if (numBytesRead > -1)
        pos += numBytesRead;
    Log.d(TAG, "actually read " + numBytesRead);
    return numBytesRead;
}

Has anyone ever encountered this issue? It seems like the only way to get my desired behavior is to rewrite portions of the SKIA library... I would really like to know what the point of the InputStream parameter is if the native implementation initializes a stream of its own...

A:

turns out that it wasnt able to detect that it was an actual image from the first 1024 bytes it takes in. If it doesnt detect that the file is an actual image, it will not bother decoding the rest, hence only having read[] called once. 

