Tencent/tinker · error · IllegalArgumentException
Extra data too long: ${data.length}
Error message
Extra data too long: ${data.length} What it means
The zip format stores the extra field length in an unsigned 16-bit field, so TinkerZipEntry.setExtra rejects any byte array longer than 65535 bytes with IllegalArgumentException('Extra data too long'). null is allowed and clears the field. Unlike the name check (error 40) this is an exact length check on the raw byte array, not an encoding estimate.
Source
Thrown at third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/TinkerZipEntry.java:287
/**
* Gets the extra information for this {@code ZipEntry}.
*
* @return a byte array containing the extra information, or {@code null} if
* there is none.
*/
public byte[] getExtra() {
return extra;
}
/**
* Sets the extra information for this {@code ZipEntry}.
*
* @throws IllegalArgumentException if the data length >= 64 KiB.
*/
public void setExtra(byte[] data) {
if (data != null && data.length > 0xffff) {
throw new IllegalArgumentException("Extra data too long: " + data.length);
}
extra = data;
}
/**
* Gets the compression method for this {@code ZipEntry}.
*
* @return the compression method, either {@code DEFLATED}, {@code STORED}
* or -1 if the compression method has not been set.
*/
public int getMethod() {
return compressionMethod;
}
/**
* Sets the compression method for this entry to either {@code DEFLATED} or {@code STORED}.
* The default is {@code DEFLATED}, which will cause the size, compressed size, and CRC to be
* set automatically, and the entry's data to be compressed. If you switch to {@code STORED}View on GitHub (pinned to 1b7ea02c23)
Solutions
- Trim or drop non-essential extra records so the total is <= 65535 bytes.
- If you are accumulating multiple extra records, keep a running length budget and discard the oldest/largest record when it overflows.
- Move oversized metadata out of the extra field (sidecar file, manifest entry) — the format cannot represent it here.
Example fix
// before
entry.setExtra(allExtraRecords); // may exceed 64 KiB
// after
if (allExtraRecords != null && allExtraRecords.length > 0xffff) {
allExtraRecords = trimExtraRecords(allExtraRecords, 0xffff);
}
entry.setExtra(allExtraRecords); Defensive patterns
Strategy: validation
Validate before calling
static final int MAX_EXTRA = 0xffff;
boolean extraFits(byte[] extra) {
return extra == null || extra.length <= MAX_EXTRA;
}
// before writing:
if (!extraFits(entry.getExtra())) {
entry.setExtra(trimExtraRecords(entry.getExtra(), MAX_EXTRA));
} Prevention
- Budget the extra field: sum (4 + size) per record and stop adding records at 65535 bytes.
- Never append alignment/signature blobs to extra without re-checking total length.
- Store large metadata outside the extra field.
When it happens
Trigger: Calling setExtra(data) with data.length > 0xffff — e.g. embedding a large alignment/ID/size extra record (zipalign-style), a zip64 extra, or a signature block into the entry's extra field.
Common situations: Storing APK signing or alignment metadata in the extra field and exceeding the 64 KiB cap; concatenating multiple extra records (ID+size pairs) without checking the accumulated size; copying extra fields from a zip64 archive into this library's entries.
Related errors
- ${argument} too long: ${bytes.length}
- Bad CRC32: ${value}
- Bad method: ${value}
- Bad size: ${value}
- Bad mode: ${mode}
AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14).
Data as JSON: /api/errors/e1d73acc5a7db12a.
Report an issue: GitHub.