Tencent/tinker · error · DexException
bogus element_width: {}
Error message
bogus element_width: {} What it means
InstructionPromoter rewrites 16-bit dex instructions into their wide-index (jumbo/promoted) forms while recomputing the promoted instruction address. Each instruction's code-unit width is derived from the backing array type (short[] = 1 unit per element, int[] = 2, long[] = 4); the switch's default branch fires when elementWidth is none of the handled values, i.e. an instruction format this promoter version does not know. The message is an internal invariant violation, not a normal data error.
Source
Thrown at third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dx/instruction/InstructionPromoter.java:520
case 1: {
int length = ((byte[]) data).length;
this.currentPromotedAddress += (length >> 1) + (length & 1);
break;
}
case 2: {
this.currentPromotedAddress += ((short[]) data).length * 1;
break;
}
case 4: {
this.currentPromotedAddress += ((int[]) data).length * 2;
break;
}
case 8: {
this.currentPromotedAddress += ((long[]) data).length * 4;
break;
}
default: {
throw new DexException("bogus element_width: " + Hex.u2(elementWidth));
}
}
}
}
View on GitHub (pinned to 1b7ea02c23)
Solutions
- Upgrade the tinker dependency (which vendors aosp-dexutils) to a release whose dx instruction tables cover the dex format you are processing.
- Reproduce with a minimal dex and capture the opcode/format at the failure point (log elementWidth and the instruction) to confirm it is an unknown-format gap rather than corrupt input.
- If the input dex may simply be corrupt, validate it first with dexdump; a corrupt instruction stream can also yield an unhandled width.
- If the gap is confirmed, file an issue with the tinker project including the failing dex so the promoter's width table is extended.
Defensive patterns
Strategy: validation
Validate before calling
// Smoke-test the dex with dexdump before promoting instructions
boolean dexParsesCleanly(java.io.File dexFile) {
try {
Process p = new ProcessBuilder("dexdump", dexFile.getAbsolutePath()).start();
return p.waitFor() == 0;
} catch (Exception e) {
return false;
}
} Try / catch
try {
promoter.visit(instruction);
} catch (com.tencent.tinker.android.dex.DexException e) {
if (e.getMessage() != null && e.getMessage().startsWith("bogus element_width")) {
// unsupported instruction format: report dex + toolchain versions, abort this build
throw new UnsupportedOperationException("unsupported dex instruction format; upgrade tinker/aosp-dexutils", e);
}
throw e;
} Prevention
- Pin consistent versions between the dex-producing toolchain and tinker's vendored aosp-dexutils.
- Validate new dex formats with dexdump before feeding them to the promoter.
- Log the opcode/format at promotion time so unknown-format gaps are diagnosable from the first failure.
When it happens
Trigger: Promoting instructions (used when tinker rebuilds a dex with a promoter attached, typically to upgrade const-string to const-string/jumbo) and encountering an instruction whose element width is not 2, 4, or 8 — e.g. an opcode/format introduced by a newer dex spec or emitted by an exotic compiler.
Common situations: Parsing dex files produced by new AGP/d8 versions after an old aosp-dexutils was pinned; custom bytecode injected by an agent/framework using an instruction format the vendored dx code predates; version skew between the tool that built the dex and the vendored third-party/aosp-dexutils.
Related errors
- file is null.
- Expected ${DEX_IN_JAR_NAME} in ${file}
- unknown output extension: ${file}
- Unexpected type: ${type}
- invalid LEB128 sequence
AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14).
Data as JSON: /api/errors/7ae4e938f75902cd.
Report an issue: GitHub.