iBotPeaches/Apktool · error · IOException

Jump failed: skipped %s bytes (expected: %s)

Error message

Jump failed: skipped %s bytes (expected: %s)

What it means

BinaryDataInputStream.jumpTo(pos) asked the underlying stream to skip forward, but skip() returned fewer bytes than requested — the stream ended first. This indicates a truncated file: the target offset lies past the end of the data actually available.

Source

Thrown at brut.j.util/src/main/java/brut/util/BinaryDataInputStream.java:90

    public long position() {
        return mPosition;
    }

    public long remaining() {
        return mLimit - mPosition;
    }

    public long jumpTo(long pos) throws IOException {
        long expected = pos - mPosition;
        if (expected == 0) {
            return 0;
        }
        if (expected < 0) {
            throw new IOException(String.format("Illegal backwards jump from %s to %s", mPosition, pos));
        }
        long skipped = skip(expected);
        if (skipped != expected) {
            throw new IOException(String.format("Jump failed: skipped %s bytes (expected: %s)", skipped, expected));
        }
        return skipped;
    }

    public void skipByte() throws IOException {
        //noinspection ResultOfMethodCallIgnored
        readByte();
    }

    public void skipShort() throws IOException {
        //noinspection ResultOfMethodCallIgnored
        readShort();
    }

    public void skipInt() throws IOException {
        //noinspection ResultOfMethodCallIgnored
        readInt();
    }

View on GitHub (pinned to 79b63384d7)

Solutions

  1. Confirm archive integrity: `unzip -t app.apk` must pass with no CRC errors
  2. Re-obtain the APK from a trusted source and compare size/hash
  3. Update apktool in case newer releases tolerate/handle the table layout in question
  4. If the file is intentionally malformed (protector), you cannot decode it as-is; get the unprotected original

Example fix

# before
apktool d truncated.apk   # Jump failed: skipped 120 bytes (expected: 4096)

# after
unzip -t truncated.apk      # shows CRC/bad zipfile errors
# re-download / re-pull the APK, then
apktool d intact.apk
Defensive patterns

Strategy: validation

Validate before calling

// Bound-check target offsets against the stream's known length
long remaining = in.remaining();
if (pos - in.position() > remaining) {
    throw new EOFException("Offset " + pos + " beyond end of data (" + remaining + " bytes left)");
}
in.jumpTo(pos);

Try / catch

try {
    in.jumpTo(pos);
} catch (IOException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("Jump failed")) {
        // truncated input: no retry can help; fail with the file identity for upstream reporting
        throw new IllegalStateException("Truncated resource data in " + sourceFile, e);
    }
    throw e;
}

Prevention

When it happens

Trigger: A resources.arsc or binary XML whose chunk offsets extend beyond the file/entry length — cut-off downloads, entries truncated by repacking tools, or length fields lying about the real data size.

Common situations: APKs truncated in transit, ZIP entries damaged by bad repack pipelines, protected apps whose resource tables are deliberately mangled.

Related errors


AI-assisted analysis of iBotPeaches/Apktool@79b63384d7 (2026-08-14). Data as JSON: /api/errors/cc230781920c3b46. Report an issue: GitHub.