MuntashirAkon/AppManager · error · java.io.IOException
Unknown token with type
Error message
Unknown token ${token} with type ${type} What it means
consumeToken() switches over the XmlPullParser token constants (START_DOCUMENT, START_TAG, TEXT, END_TAG, END_DOCUMENT). A token value outside the protocol's known set means the stream is desynchronized or corrupt, so it throws IOException "Unknown token <token> with type <type>".
Solutions
- Restart parsing from a fresh stream positioned at the document start instead of continuing after a failure.
- Verify the file's integrity and that it was produced by a compatible version of the binary XML writer.
- Confirm the magic header was consumed exactly once (setInput does this); do not skip or re-read the header manually.
- Log the offending token/type values to diagnose the misalignment.
Example fix
// before parser.next(); // after an earlier IOException, stream is misaligned parser.next(); // Unknown token ... // after parser = newBinaryXmlPullParser(); // fresh parser parser.setInput(freshInputStream, null);
Defensive patterns
Strategy: try-catch
Validate before calling
// Ensure a clean start for every parse attempt:
InputStream fresh = new FileInputStream(file);
byte[] magic = new byte[4];
if (fresh.read(magic) != 4 || !Arrays.equals(magic, PROTOCOL_MAGIC_VERSION_0)) {
throw new IOException("Not binary XML");
} Try / catch
try {
parser.setInput(is, null);
// parse
} catch (IOException e) {
// stream is desynchronized or corrupt: re-create parser + stream, do not resume
} Prevention
- Always restart from a fresh parser and stream after any parse exception.
- Do not manually skip or re-read the magic header; setInput handles it.
- Validate file integrity (regenerate from source) before parsing.
When it happens
Trigger: Reading a token byte that maps to no known token — corrupted file, wrong stream offset, a stream produced by an incompatible writer/version, or byte misalignment after a prior parse failure.
Common situations: Continuing to parse after an earlier exception left the stream mid-token; passing non-binary-XML data that slipped past other checks; truncated files where data bytes are interpreted as tokens; protocol version mismatch.
Related errors
AI-assisted analysis of MuntashirAkon/AppManager@0152f468fc (2026-09-12).
Data as JSON: /api/errors/707b8ae73ca4fe85.
Report an issue: GitHub.
Appendix: source
Thrown at libcore/compat/src/main/java/io/github/muntashirakon/compat/xml/BinaryXmlPullParser.java:292
case XmlPullParser.TEXT:
case XmlPullParser.CDSECT:
case XmlPullParser.PROCESSING_INSTRUCTION:
case XmlPullParser.COMMENT:
case XmlPullParser.DOCDECL:
case XmlPullParser.IGNORABLE_WHITESPACE: {
mCurrentName = null;
mCurrentText = mIn.readUTF();
if (mAttributeCount > 0) resetAttributes();
break;
}
case XmlPullParser.ENTITY_REF: {
mCurrentName = mIn.readUTF();
mCurrentText = resolveEntity(mCurrentName);
if (mAttributeCount > 0) resetAttributes();
break;
}
default: {
throw new IOException("Unknown token " + token + " with type " + type);
}
}
}
/**
* When the current tag is {@link #TEXT}, consume all subsequent "text"
* events, as described by {@link #next}. When finished, the current event
* will still be {@link #TEXT}.
*/
private void consumeAdditionalText() throws IOException, XmlPullParserException {
String combinedText = mCurrentText;
while (true) {
final int token = peekNextExternalToken();
switch (token) {
case COMMENT:
case PROCESSING_INSTRUCTION:
// Quietly consumed
consumeToken();View on GitHub (pinned to 0152f468fc)